> -----Original Message----- > From: [email protected] [mailto:ietf-dkim- > [email protected]] On Behalf Of Mark Delany > Sent: Thursday, October 29, 2009 9:42 AM > To: [email protected] > 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
