-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Thursday, October 29, 2009 9:42 AM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM on envelope level
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.
Do you mean the server's side of the connection will have buffer data in it?
That would mean the client sent DATA<CR><LF> followed by header/body
information, possibly even in the same packet, without waiting for the reply
from DATA. The server could drop the connection outright in that case for
violating SMTP rules, even with support for PIPELINING which as I recall
requires a synchronization point at DATA. This wouldn't reduce pipe bandwidth
consumption (if that's the goal) but it could reduce resource consumption at
MTAs.
It seems to me the idea proposed might tie envelope authentication to a single
domain name (either the HELO/EHLO parameter or the domain name in the MAIL FROM
parameter, if any. An ADSP variant could answer the "should be signed"
question for that name as well), but then you would still need domain
reputation to assert a value or meaning of that name for a filtering decision
to be possible.
The other obvious consideration: Spammers are already signing their mail with
DKIM, so they could just apply this method as well. Without widespread
deployment of domain reputation, they would still get a "green light" from the
DKIM module and maybe even the ADSP one.
As for the data volume, we're still seeing spam campaigns at 200k or more per
message. Compared to general Internet traffic (e.g. streaming video) that's
probably kind of small, but it might make a difference to people on the end of
smaller links.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html