From: Anthony Howe
Date: 2004-11-06 03:13:00 -0500
Subject: Re: milter-sender greylisting
More information..: http://www.milter.info/#Support
Alexander Dalloz wrote:
> Am Fr, den 05.11.2004 schrieb Ricardo Kirkner um 14:49:
>>Hi. I just have a doubt... Milter-sender's greylisting works like the
>>original greylisting technique, right? (this means, it checks the triple
>>mail_from,rcpt_to,relay_ip for existance in order to determine if it
>>should greylist the entry or not)
> milter-sender is no primary greylisting tool. So greylisting is only
> used in special cases.
>>I ask this, because I am detecting some mails that pass on right through
>>the milter, although they should be greylisted, since they are the first
>>mails that are sent from a specific relay.
> No, see above and read the docs.
> --> MxAcceptsAllAction
These two options do explain when and how the greylisting is used.
These articles also briefly explained it:
But I'll reiterate it here in this thread, as the subject better
reflects the discussion for future reference.
milter-sender's primary modus operanda is the "call-back". Essentially
check with the MX of the sender's domain to see if they will accept mail
to the sender. The sender's address might be rejected because the
address doesn't exist, the mailbox is full, the server doesn't accept
the null address required for DSN and MDN notices, etc.
In order to avoid too many false-negatives, instances when an MX blindly
accepts anything only to reject much later (such as secondary MXes and
gateways), the SMTP dialogue first tests for an intentionally false
address (a permutation of the sender's address) looking for a 550
response. It then tests the sender's address looking for 250 response.
Now if both RCPTS tests returned 250, then the MX blindly accepts RCPTs
and only rejects after the final dot to DATA (Yahoo) or much later (a
gateway). Originally in older versions I would then proceed to do a
full-callback (MxAcceptsAllAction=7) to see if the message would bounce
on the final dot to DATA, but this ment that some victims of a joe-job,
would get a probe message and this just confused and more often annoyed
people. It also resulted in SpamCop listing milter-sender servers doing
full callbacks, because they saw it as a form of C/R that impacted the
So I implemented grey-listing as a secondary technique to be used in
place of sending a full callback probe message. MxAcceptsAllAction
option allows for four variations of the grey-listing key.
There can be instances were the call-back succeeds and so grey-listing
is ignored. Consider a "one-eye-open" MX like aol.com. They reject RCPT
addresses that don't conform to their address naming conventions. So the
intentionally false address test might generate a 550 response for
syntatic reasons instead of semantic reasons (if that makes sense).
Essentially if the intentional false address generates 550 for the wrong
reason, ie. did you really look up the address and confirm it does not
exist or you just didn't like the way it looked (mixed case, digits,
phase of the moon, etc), then the second test using the sender's address
as a RCPT will succeed, because the MX is a half-blind gateway; it
checks some things about an address, but does not answer the essential
question "is this one of yours?".
In such cases milter-sender will let the message through. Without a
better means of detecting blind and half-blind MX severs, the
grey-listing technique will be under utilised.
You could consider installing milter-gris in front of milter-sender, but
that can result in cases of double (or even indefinite if the cache TTLs
are too short) grey-listing and delaying the mail far too long.
Alternatively, I could probably add an enhancement to milter-sender to
always grey-list a domain or host that are tagged in the access
database. But this mean semi-regular updates of the database, which
grows tiresome over time.
Anthony C Howe +33 6 11 89 73 78
7116561 AIM: Sir Wumpus
"Once...we were here." - Last of The Mohicans
Copyright 2009, 2012 by SnertSoft. All rights reserved.