On 10/29/2009 09:42 AM, Mark Delany wrote:
On Oct 29, 2009, at 9:11 AM, Dave CROCKER wrote:
I'm guessing the incentive for all of this is to reduce bandwidth,
otherwise why not just issue the 4XX/5XX after the DATA/. sequence
rather than invent a new mechanism to issue the same response at the
envelope end of the transaction?
First blank line after DATA.
If the proposal is an attempt to reduce SMTP bandwidth, which is
becoming a vanishingly small part of Internet traffic for most sites
anyway, then stopping after DATA doesn't help as your OS will have
likely received a socket buffer full of data, even if the application
doesn't read it. So it might make you feel good, but it doesn't reduce
the bytes coming down the line consequentially.
My suspicion is that Mark is exactly right. Besides, DKIM alone is
generally better at determining who's "good" rather than who's "bad".
So you're going to need the whole body for filtering in all normal
cases anyway.
Mike, bad guys aren't going give you a short
header saying they're bad after all. That's
the job of RFC3514
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html