> -----Original Message----- > From: Mark Delany [mailto:[email protected]] > Sent: Thursday, October 29, 2009 5:31 PM > To: Murray S. Kucherawy > Cc: [email protected]; IETF DKIM WG > Subject: Re: [ietf-dkim] DKIM on envelope level > > > 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 > > I haven't been watching lately, but at some point a popular bot > technique was to send the whole transaction without looking at the > responses. After all, what do they care? > > It was popular enough to generate the "greet_pause" feature in > sendmail - as you must know. I don't know whether "greet_pause"-type > detection is so wide-spread now that spammers have moved away from > doing it, but I'll bet a lot still don't care and just blast away.
I agree that they're probably doing that, but you can save yourself a lot of server-side stuff like temporary storage of a (possibly large) message body, creation of a thread, etc. if you observe at DATA that there's more information pending before you've sent back the 354. Sure, the bits have already come down the wire and into a kernel socket buffer, but the client can abort early (freeing resources, maybe even shutting down the session) which conserves some user-level server resources. The same might be true if at DATA the client has failed some kind of envelope signature test like what's been proposed. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
