ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM on envelope level

2009-10-31 15:03:00
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.

See the CHUNKING extension defined in RFCs 1830 and 3030.

CHUNKING can in theory be used to send the headers and body separately. But
it doesn't have to be - the chunk boundaries are aribtary and there's no way
for a server to say "send me the headers and body in separate chunks please".

Of course it would be possible to devise an extension to do this - it would
actually be a pretty simple thing to define - but I'm quite skeptical as to
it's potential for deployment. Remember, for this to work the clients have to
change, but the benefits accrus to the server. So why would I as a client
implementor do something that complicates my code and error handling while
providing me essentially no benefit?

It was defined 14 years ago but I don't know anyone who uses it.

Well, FWIW, we implement CHUNKING and have done so for quite a while. A quick
check of my home logs shows that out of the 5071 messages received today,
48 were transferred with BDAT. So about 1% - not a lot, but some.

I'm afraid I can't tell you how many chunks were used in those CHUNKING
transaction - it's not something we bother to log - but my guess would be one
per. Of course our implementation supports reception of multiple chunks, but we
always send the entire message with a single BDAT. Aain, when you know the
length, why bother with multiple commands?

An even more interesting question would be to what extent do server
implementations that support chunking have the ability to report an error based
on early analysis of partial message data. We do perform such analysis once the
header is available, but this is isn't currently tied back to  BDAT so the
result won't show up until the BDAT n LAST comes in. We could change this
fairly easily, but absent not only more use of BDAT in general and multiple
BDATs in particular, what would be the point of making such a change?

Another issue that would have to be addressed before this would work for DKIM
stuff would be how DKIM-MILTER operates. Given that sendmail apparently doesn't
send the message to the milter as it comes in, I wouldn't expect milter-based
implementations to care about early header processing, initiating DNS lookups,
and so on.

                                Ned
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html