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 |
