[Mimedefang] early experiences with grey listing

Gary Funck gary at intrepid.com
Wed Jan 12 17:40:13 EST 2005



With help from the MDf list members, and a few trips through the MIMEDefang
archives, I was able to implement a form of grey listing.
Mainly, I used the implementation here:

http://www.bl.org/~jpk/md-greylist/

There are different ways to configure this implementation.
I went with the default
where it keeps a (sender address, relay class C ip, recipient address)
triple and stalls the sender whenever the triple hasn't been seen
before or is still in the initial blackout period.  I bumped the
blackout period to 1 hour with the thought it would allow some time
for the spammers' URL's to make it into the various SURBL databases.

I found that I get a little nervous when mail comes in from a client,
and I know we're going to stall it for an hour.  I just hope
the senders' MTA will try again in a timely fashion. So far so good.
However, if I'm waiting for a website to send me my password info.,
I really would like the reply sooner rather than later.

I'm thinking that for our set up, the more appropriate thing to
do might be to try and verify that the sender's domain reverse
maps to the class C sending IP address.  If it does then let it
through without delay.  After all, SA is still available
to scan the message, and most spam uses zombies and/or address spoofs.
The current implementation already resets the
greylist info. for relay ip/sender's who send mail that is calculated
to be spam.  Thus, the logic should check first to see if the sender
is registered as being in the blackout period, then check to see if
the sender's domain maps to the sending relay ip.

I'm also thinking it would be worthwhile whitelisting any
recipients of mail originated from the local/trusted network. Thus,
if a user initiates a contact, there is some assurance that he'll
see the reply without delay.

The other thing that I've noticed is a lot of spam sends to local
mail addresses that don't exist.  With greylisting enabled, these
errant messages are first tempfail'ed, and only if/when they come
back after the black out period, is the recipient id checked,
and the sender is then bounced with "unkown user".  Not necessarily
good, if a sender mistypes a local email address, and would like to
know about it soonder rather than later.  I don't know this authentication
can be implemented in the MIMEDefang filter or not, with some reasonable
level of effort, but it seems like it might be a good thing to do.








More information about the MIMEDefang mailing list