Hi David, Many thanks for your comments. Since I'm using these macros in production as well, I'm keen to investigate the issues that you've raised.
On Sun, 27 Apr 2008, David Woodhouse wrote: > On Sat, 2008-04-26 at 21:58 -0400, Grant Peel wrote: > > Comments, concerns, criticisms and praise all welcome. > > You don't seem to be bypassing the greylist for hosts which are known to > resend mail. So you're delaying a lot of mail for no benefit. Once a > given host is observed to queue and retry, you know that there's no > point in greylisting mail from that host again. That's the point of the GREYLIST_TEST, does it not work? There should be an entry in the database for each host which passed greylisting (i.e. retried the message more that 10 minutes after first contact) which lasts for 28 days. Also, I think there can be a point in delaying some mail from a public IP which has been seen to pass greylisting, if the source domain is different, as the machine may suddenly start to relay spam or another internal server with the same public IP may suddenly become a spam source. The former gives me a small window for DNSBLs to detect that the machine is spamming and list them (after which its subsequent retry attempts will be rejected), while the in the latter case the infected bot will probably never retry the same domain to me. > You seem to defer the message in the case where MySQL goes AWOL, rather > than accepting it. That's an interesting decision, since it will quite > possibly lead to messages being deferred for ever. OK, I'll fix that, thanks. (It hasn't caused a problem for me yet, but better safe than sorry). > You also seem to be greylisting mail even when it isn't at all > suspicious. Some prefer only to greylist mail which looks dodgy, rather > than just a blanket delay on _everything_. Obviously, you do it in the > DATA ACL for that, so you can actually see the message. At the moment I don't have any system-wide spam filter that I could run in the data ACL. And spammers have a habit of changing their messages to get around such filters. In my case, the number of new domains and hosts seen sending mail is quite small, so it works for me (on a small domain). > (Also, rejecting for SPF fail is particularly 'brave'. I'd recommend > googling for 'sender address forgery' and reading the first link that > Google shows up.) Surely I can't be the only person rejecting messages where the sender has explicitly put "-all" in their SPF record, and the SPF check fails? At least it's useful for allowing people to say that certain domains never send mail, or that their users don't use mailing lists or forwarders? (if nothing else) Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \ _/_/_/_//_/___/ | We are GNU : free your mind & your software | -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
