[Mimedefang] Justifying greylisting to management

[Kevin A. McGrail]

Jeff:

In my testing, I found that greylisting had too many false-positives causing 
important and even critical mail to be unacceptably delayed. Therefore, I 
agree with the "PHBs at your work" and that greylisting should be a last 
resort if other methods fail because you're only argument IMO is "you have 
to give me more hardware or let me turn on greylisting". The surprising part 
in my experience is that I've gotten budget increases for hardware rather 
than risk delaying email.

I specifically found that large companies and universities were not able to 
handle queued mail and/or even instituted mail retry periods as high as 24 
hours.  This translates to email delayed by greylisting (or a simple outage 
for that matter) would be delayed 24 hours!  While I don't agree with a 24 
hour retry (we use 5 minutes for the first hour and 4 hours or 8 hours 
thereafter for 10 days), I can't change every mail server and some of these 
companies and universities are just handling more email than the systems are 
able so queue times will grow larger in time if they aren't just set 
arbitrarily large.

Also you might say email from bob at xyz.edu is acceptable to be delayed, but 
it generated lots of complaints especially for people emailing 
family/sons/daughters at school.  I also seem to remember that the SMTP 
servers for Allegiance Telecom did this as well so companies that have DSL 
and relay through AT's servers were all delayed 24 hours as well.

Finally, greylisting can count negatively towards your mail server for 
companies like AOL that may reject for a sub-90% success rate on bounces.


However, I've also been surprised somewhat that spammers haven't reacted to 
greylisting still.  I thought the technique would be invalid by now because 
the minute ratware/malware starts properly following the 4xx rules, the 
technique is from my understanding, null and avoid.

BTW, to end this email, let me relate that I am once again amazed by the duo 
of Sendmail + MIMEDefang!  I had a friend using JournyX's timesheet's 
program that was putting out improper headers with a bad date and a from 
without a real name.

They had two choices: upgrade to a new version with much labor and software 
licensing issues OR route the emails through their existing MD gateway where 
we modified the headers midstream.

   #Journyx Issues
    if ($Sender =~ /^<?acctng\@removed.com>?$/i) {
      action_change_header('From', '"Accounting" <acctng at removed.com>');
      &change_header_immediately(header=>'From: "Accounting" 
<acctng at removed.com>');
      my $date = `/bin/date -R`;
      chomp $date;
      action_change_header('Date', $date);
      &change_header_immediately(header=>"Date: $date");
    }

NOTE: The change_header_immediately function modifies INPUTMSG so that the 
spamassassin tests from MD reflect the header changes.

Anyway, such an idea seems simple if you have used MD but without it, I 
wouldn't even know where to start except to write a C milter from scratch.

Regards,
KAM


> But, I absolutely can't get the PHBs at my work to approve of a full
> install there (currently I just greylist anything addressed to me)
> because "critical e-mail might be delayed".  After much thought, I
> realize there is no way I can fight this particular issue, because no
> matter how much whitelisting you do, it could happen.  For the same
> reason, even an "opt in" approach isn't likely to happen, since the
> PHBs feel that individual employees aren't smart enough to be able to
> judge if they might need to receive a "critical" e-mail.
>
> Still, if I had some real-world examples of largish *businesses* that
> use greylisting, I could use that to convince them that other
> successful businesses see it as something that they can afford to do.
> Universities and other places where e-mail is a privilege (in a sense)
> wouldn't do a lot to sway them, but ISPs (who could lose customers
> because they don't want e-mail delays) would probably help.