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 [EMAIL PROTECTED] 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 =~ /^<[EMAIL PROTECTED]>?$/i) {
action_change_header('From', '"Accounting" <[EMAIL PROTECTED]>');
&change_header_immediately(header=>'From: "Accounting"
<[EMAIL PROTECTED]>');
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.
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
