ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-16 19:05:09
There are three issues with this: First the assumption that the first RCPT
TO
is derived from 2822;

Depends on how you implement things and the binding semantics.  Nothing
prohibits allowing the envelope address be different from the header
address.

Sure. But if there is no linkage to the content you cannot prove that the
message hasn't been re-injected at some random point in the network - aka
replay.

BTW, are we talking about recipient addresses or
sender addresses? or both?

The address that changes as a mail traverses the mail infrastructure.
Generally, RCPT TO is really the only interesting one. We originally called
them audit signatures, btw.

Also, the SMTP "optimization" is not necessarily a problem.
...
So, does requiring the copying earlier on increase costs unacceptably?

If you haven't seen the discussions in other forums, from experience this is
one of those religious ones that generates much heat. Especially in the "my MTA
is better than your MTA" battlegrounds. I'm merely raising the flag.

Note, here is where having the separate body hash can be valuable.

Right. All an audit signature has to protect is the new audit information plus
the previous signature header.


Mark.

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