Milter-greylist

Chris Hoogendyk wrote:
> 
> manu@... wrote:
>> Andrew Wilkinson <ajwilk74@...> wrote:
>>
>>   
>>> I've got a number of users who wish to be exempt from
>>> grey-listing.  I need to know what M-G does with
>>> messages that have multiple recipients, and one of the
>>> recipients has been made exempt from grey-listing in
>>> greylist.conf.  Will the milter honor the exempt
>>> status of the one user and deliver the message to the
>>> one exempt person, while delaying delivery for the
>>> remaining recipients?
>>>     
>> Yes, it should work that way.
>>   
> 
> Please excuse my being annoying and ignorant, but how does it do that?

The same way any other multiple-recipient message is handled when one or more 
users is undeliverable, but others are.

An example dialog between mailservers:

HELO <some server>
250 ...
MAIL FROM: <some address>
250 ...
RCPT TO: <some valid address>
250 ...
RCPT TO: <some invalid address>
550 ...
RCPT TO: <some greylisted address>
451 ...
RCPT TO: <some address where an LDAP lookup timed out>
451 ...
DATA
<some message>
.
250 ...


The sender server would realize the message was:

- Delivered to the valid address
- Needs to be retried later for the greylisted and ldap timeout addresses
- Cannot be delivered to the invalid address, and a DSN (bounce) should be 
generated.

This is all inherent in how SMTP works, and these kinds of things crop up all 
the time even in the absence of greylisting.


> 
> Can it actually tell the sending mta that it is accepting some of the 
> recipients and greylisting others? 


Yes, SMTP error codes can be issued on a per-recipient basis, as above.

Of course, this assumes you're using milter-greylist racls, which occur at the 
end of each SMTP RCPT command, not dacls which occur at the end of the DATA phase.

racl's are inherently limited to greylisting based on the IP of the relay, the 
envelope from address, and recipient address, but that's kind of the "normal" 
way to do greylisting. Earlier versions of milter-greylist only supported one 
kind of acl, and that was the same thing as what's now called a racl.

dacl's let you do things like greylist based on headers, body content or message 
size, but IMHO using them for greylisting is potentially troublesome and should 
be considered carefully before being used.

When a dacl runs, it's at the end of the DATA phase, and the data has already 
been transfered. If you greylist here with a 450, the sending server is going to 
have to re-transfer it to your server again later. This could happen thousands 
of times before the greylist duration expires, wasting a lot of bandwidth if the 
message is large.

dacl's, unlike racls, are also an "all or nothing" proposition. If you generate 
a failure at the end of the data phase, it's applied to all the recipients that 
were accepted at the SMTP phase.

  For those reasons, you're probably better off using racl's for greylisting, 
and leave dacls for blacklisting only (or just not using them at all). If you do 
use them for greylisting, that's fine, but be sure you understand the two 
caveats above before doing so.

> Otherwise, it would seem that when 
> the message was resent, it would end up allowing duplicate deliveries to 
> those who had received it already, unless it is tracking a lot more 
> information than I was aware of, which would seem to be wasteful.

You're generally missing a lot of how SMTP works, but the above should explain 
things.