Dave CROCKER wrote:
I was just at a session at an industry trade association where the question
doing DKIM during SMTP came up. There were operations folk who very much
the idea of being able to obtain some DKIM benefit during the SMTP session,
before the dot...
One proposal (via list mail) was suggested via an SMTP extension that
allows the SMTP server to RAISE the BAR on SMTP clients. For example:
But that has a problem with legacy transactions.
Another proposal with a few participants here worked with me called
"HEAD" described where the header can be pushed first minimizing the
payload and also helping with 2822/5322 level technologies.
S: serverdomain.com, welcome ESMTP v2.0
C: EHLO mail.clientdomain.com
C: MAIL FROM:<jqpublic(_at_)emaildomain(_dot_)com>
S: 250 User Ok
C: RCPT TO:<localuser(_at_)serverdomain(_dot_)com>
S: 250 User Ok
S: 354 Start Header input; end with <CRLF>.<CRLF>
S: 250 Header Accepted. Please Continue with DATA
S: 354 Start Body input; end with <CRLF>.<CRLF>
S: 250 Message Accepted for Delivery
S: 250 Goodbye
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
HEAD can be updated to support suggest an idea.
The beauty of HEAD is that it would help other payload technologies
and not just DKIM. But also Sender-id.
I can't say that anyone sounded hugely enthusiastic about this, but given
there was interest in SMTP-time benefit, I think they just needed to think
I think most people are simply interested in rejecting mail they don't
have to accept. But under the current framework that requires a
transfer of the payload overhead just to get the header+body. Just
like David MacQuigg wanted to do with just checking the header for
This is the direction with many SMTP implementators - accepting mail
without "thinking" has its consequences. In today worlds, it decreases
confidence in mail reliability leaving us with "DISCARD" ideas that
only perpetuate non-notification transactions.
That is why HEAD was put together.
NOTE WELL: This list operates according to