>> 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?
I agree. Senders would only do this if recipients demanded it, and recipients aren't going to demand it. So we can forget it. Your note about milter is a good one. If performance were an issue, MTA vendors could rewrite their own code to stream DKIM verification and potentially dispose of unwanted messages more quickly. If it's not worth doing that for the mail stream they have now, it's surely not worth trying to change SMTP. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
