On Oct 29, 2009, at 9:11 AM, Dave CROCKER wrote: > First blank line after DATA. > > Whether that affords sufficient value-add is an open question to me > and probably > others.
DKIM already lets you verify the headers before you've seen the body, if I recall the algorithm correctly. There's no need for anything to change there. Any rejection of a message that's dominated by reputation, rather than body content, can be performed after you've seen the headers and before seeing the body. In this brave new world of multi-megabyte MIME attachments the resources consumed by the body (bandwidth, temporary storage, CPU and concurrency) far outweigh the resources consumed by the headers. But if you've made a decision by the time you've seen the headers, what do you do then? There's not any clean, in-band way to respond to just the headers (leading to all sorts of ugly workarounds like dropping the connection and then rejecting anything that looks kinda like the same message before DATA when it's retried). It would be very, very nice to have an ESMTP extension that allowed sending just the headers of an email, waiting for a 2xx or 5xx response, then sending the body. And that's the general solution to this sort of problem, though a little broader in scope than is really appropriate for the DKIM forum alone. Cheers, Steve > > d/ > > Ian Eiloart wrote: >> >> >> --On 29 October 2009 09:45:31 -0400 Dave CROCKER <[email protected]> >> wrote: >> >>> >>> >>> Rolf E. Sonneveld wrote: >>>>> ... if they can do so, you accept the entire email. >>>>> >>>>> In either case you accept the entire email, >>>> >>>> Not necessarily. .... >> >> .... >>> I was just at a session at an industry trade association where the >>> question of doing DKIM during SMTP came up. There were >>> operations folk >>> who very much liked the idea of being able to obtain some DKIM >>> benefit >>> during the SMTP session, before the dot... >>> >>> No one suggested modifying SMTP or DKIM specifications. >>> >>> What /was/ discussed was the possibility of doing a signature that >>> would >>> validate before DATA. This merely requires a signature that does >>> not >>> cover the body. >>> >>> I can't say that anyone sounded hugely enthusiastic about this, >>> but given >>> that there was interest in SMTP-time benefit, I think they just >>> needed >>> to think about this more. >> >>> Having two signatures, with one covering the body and relevant >>> parts of >>> the message header, and the other only covering the header, >>> strike me as >>> a plausible use of DKIM, worth considering. I've no idea whether >>> it >>> would provide any or enough value-add. However it is only a >>> stylized >>> use of the existing standard, and so the cost of experimenting >>> with it >>> is reasonable. >> >> So, how do you get the headers without the body? >> >>> >>> d/ >> >> >> > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
