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