[milters] Archive

Lists Index Date Thread Search

Article: 534
From: Anthony Howe
Date: 2005-05-03 03:16:35 -0400
Subject: Re: new feature request

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support

Michael Elliott wrote:
>>However, auto white listing just the RCPT as a future sender of a reply 
>>would certainly be a worth while enhancement, but in the case of 
>>call-backs its problematic. You would have to auto white list the IPs of 
>>all the MXes of each RCPT domain in the off chance that they perform a 
>>Now consider the following example:
>>	MAIL FROM:<localuser@localmx.com>
>>	RCPT TO:<user@aol.com>
> Here is an easier method.  Double lookup.  When -k = MAIL:RCPT:IP.
> Greylist entries in the database are checked first as MAIL:RCPT:IP tuple, and
> then as MAIL:RCPT.  Any entry added to the database from a local user would 
> add the MAIL:RCPT:IP, and RCPT:MAIL as the auto whitelisting.

First this doesn't help. The local dial-up sender is already white 
listed by IP to send through the machine, so there is no need to grey 
list. But if you are white listing the reply containing an IP address, 
then (as I discussed already) you have to white list every MX of the 
reply, which is average of 2 IP addresses per domain, but could be as 
extreme as 18 IP address for a domain like aol.com. Plus you have do 
that per recipient. So if -k is MAIL:RCPT:IP and send:

	MAIL FROM:<localuser@localmx.com>
	RCPT TO:<user1@aol.com>
	RCPT TO:<user2@aol.com>
	RCPT TO:<user3@aol.com>

You'd have to white list 3x 18 entries. AND in the context of the 
original issue concerning call-backs, you'd have you white list the 
possible call-back for a total of 4x 18 entries generated from one 
outbound message.

If I implement auto white listing, then I'd used a special tag to 
distinguish it from a grey list entry. For example AUTO:MAIL:RCPT, would 

This avoids the problems of multiple and multihomed MX machines, but is 
slightly weaker and could be abused by a virus or spammer.

However this does not help with call-backs (a la milter-sender) from the 
remote side.

> A more complicated version would be one that upgrades the RCPT:LOCAL to

Now that is more interesting idea for auto white listing, on the first 
reply, match AUTO:MAIL:RCPT and then upgrade to a regular IP:MAIL:RCPT 
(assuming -k ip,mail,rcpt).

Still doesn't help with call-backs.

> I personally had to turn down the database -k to only MAIL:RCPT months ago 
> because too many servers like gmail round robin their connections.

Yes. A known problem with grey-listing. You just lookup their MXes and 
white list all the gmail.com machines and carry on with a stronger key. 
Have you experimented with -k HELO,MAIL,RCPT. Hmmm. That just gave me an 

To address the call-back issue of the original question, instead of auto 
white listing the IP address, use a special variant -k HELO,MAIL only if 
the MAIL FROM:<>. Consider:

	MAIL FROM:<localuser@localmx.com>
	RCPT TO:<user1@aol.com>

Then add two white list entries without worrying about IP addresses 
AUTO:REPLY:LOCAL and AUTO:HELO-special:LOCAL. Then when a reply comes 
back, treat it in some fashion as discussed above, BUT if a call-back, 
DSN, or MDN comes in from MAIL FROM:<>, then using the HELO argument 
(this assumes you make HELO required in sendmail BTW with 
define(`confPRIVACY_FLAGS',`goaway')) do lookups for:


That could work very nicely. This assumes of course that the sending 
host is well behaved and uses a FQDN for their HELO argument as required 
by the RFCs, but its a better solution than none at all. It could still 
be abused by spammers or a mass-mailing worm, but it would require some 
clever guessing.


Anthony C Howe                                 +33 6 11 89 73 78
http://www.snert.com/       ICQ:
7116561         AIM: Sir Wumpus

in the mist of night / by the silent sea / a siren calls - Anthony

Lists Index Date Thread Search