ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Re: signature construct

2005-10-17 16:15:51
 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Earl Hood
apart from
the obvious diagnostic benefit (which we could get other ways), it 
wasn't a compelling-enough optimization to be worth the 
trouble.  Once 
you're into the DATA stage of the message transmission, you 
don't have 
another opportunity to send feedback to the sending MTA 
until you have 
received the entire message body, and in any case I didn't 
expect IIM 
to be used to reject messages out of hand.

Even though you still have to wait until after DATA, if you 
know the sig will fail (and your rules dictate the message 
should be rejected), you can stop any extra processing (which 
may include non-DKIM stuff) on the DATA; you just send bytes 
to /dev/null.

Even if out-right rejection is warrented, any further DKIM 
processing can be stopped.

I do not think that the design errors in legacy SMTP should be the way
to decide a tie. "It has to be this way because of this constraint" is a
legitimate argument in my view, "This constraint means that there is no
advantage to doing it the other way" is a bad argument.

DKIM is an RFC 822 protocol, not an RFC 821 protocol.It is important to
keep the laye separation right.

Current SMTP is only one of the protocols to consider here. We should
not make decisions in DKIM that assume SMTP will never be changed.
RFC822 messages are transported over a wide range of protocols, POP3 and
IMAP being two rather important examples.

From the design point of view it is much better if the header is
entirely self contained. That way I can take the header out of the
message and forward it to a specialist processor, possibly on another
machine for verification. This can be done in parallel with the receipt
of the message. I can check the digest separately after the results are
in.

This is particularly advantageous if we ever build out some sort of DCC
style message revocation by digest scheme or if I have a very large
highly pipelined mail reception engine. Or if I was going to offer
verification of the message header as a service.


                Phill

_______________________________________________
ietf-dkim mailing list
http://dkim.org

<Prev in Thread] Current Thread [Next in Thread>