Milter-greylist

Ogogon !!! wrote:
> Matt Kettler wrote:
> 
>>At the time of greylisting, the Message-ID is not known.
>>You'll only know the message-id after the end of the SMTP DATA phase when the
>>message has already been transfered.
>>
>>The only data available at the time of greylisting is:
>>
>>Remote IP
>>Remote RDNS (if any)
>>Remote HELO/EHLO string
>>envelope from (ie: the MAIL FROM command)
>>envelope recipient (ie: the RCPT TO command).
>>
>>That's all the information that has been provided by the remote server at the
>>time milter-greylist decides to greylist or not. You don't know the contents of
>>any message headers, or the body.
>>  
> 
> Absolutely with it it agree, but RFC-821 does not forbid to me to read 
> through the letter up to Message-ID and after that to submit a code " 
> 4.7.1" and to close connection, having cleared the buffer.

That is true, you CAN do that. But that's not where milter-greylist ties in.
Milter-greylist has made the deliberate choice of greylisting before the STMP
DATA phase in order to save bandwidth.

If you greylist after the DATA phase, a legitimate sender that retries will
waste your bandwidth and theirs by having to send the whole message several
times before you accept it.

And to what gain? Very little. Now you know the message-id and can differentiate
between a retry and a resend.

In the process you've managed to piss off a lot of other network admins, many of
whom may choose to null-route mail sent to your network because you're
intentionally wasting substantial quantities of network bandwidth.