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:<[email protected]>
S: 250 User Ok
C: RCPT TO:<[email protected]>
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
