Dave CROCKER wrote:
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...
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:
250-DKIM REQUIRED
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.
http://www.isdg.net/public/ietf/drafts/draft-santos-smtphead-00.html
Example:
S: serverdomain.com, welcome ESMTP v2.0
C: EHLO mail.clientdomain.com
S: 250-HEAD
S: 250-HELP
C: MAIL FROM:<jqpublic(_at_)emaildomain(_dot_)com>
S: 250 User Ok
C: RCPT TO:<localuser(_at_)serverdomain(_dot_)com>
S: 250 User Ok
C: HEAD
S: 354 Start Header input; end with <CRLF>.<CRLF>
[header block]
.
S: 250 Header Accepted. Please Continue with DATA
C: DATA
S: 354 Start Body input; end with <CRLF>.<CRLF>
[message body]
.
S: 250 Message Accepted for Delivery
C: Quit
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
the
body.
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
that
there was interest in SMTP-time benefit, I think they just needed to think
about
this more.
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
DKIM policy:
http://www.imc.org/ietf-smtp/mail-archive/msg05781.html
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.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html