ietf-dkim
[Top] [All Lists]

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

2005-08-16 18:39:42
On August 16, 2005 at 16:45, domainkeys-feedbackbase02(_at_)yahoo(_dot_)com 
wrote:

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.  BTW, are we talking about recipient addresses or
sender addresses? or both?

It is worth noting that RFC-2821 discourages revealing envelope
information in message header fields (Sec 7.2).

second, multiple recipient mail - as an SMTP optimizati
on
goes away; three
BCC: mail would need to include a BCC: header.

RFC-2821 suggests that for BCC-aware agents, to create a separate
copies of messages since implementations may violate the semantics
of bcc.

Also, the SMTP "optimization" is not necessarily a problem.
Eventually, a separate copy is made (when there are multiple
recipients) for each recipient.  It is just a matter of when it
is made.  If the initial submission MTA gets a list of recipients
for different domains, the MTA must send a copy of the message for
each address.  The only time the number of copies are reduced is
if a group recipient addresses are served by the same mail exchange
(which minimizes bandwidth).  Yes, the copies can be transient
since they are done during the DATA portion of each transmission.

So, does requiring the copying earlier on increase costs unacceptably?

If DKIM signing is to be done (and envelope information is to be
part of it), the signing must be done on the transient copies that
will be transmitted versus siging on the inital submitted message
before copying.

Note, here is where having the separate body hash can be valuable.
If each envelope-aware signature will have different header data
(to capture envelope information), the body hash does not have
to be recomputed for each signature created.

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