On Thu, 13 Jul 2006, Sandy Wills wrote:
(I lurk for an education, and occasionally ask questions to help learn)
Tony Hansen wrote:
Person A sends the message to Person B. A's server AS does not sign the
message. Person B decides to resend the message to Person C, and B's
server BS duly adds a Resent-From: header and does signing.
As far as BS is concerned, the Resent-From: header is the one that
*should* be signed, not the From: header.
Assume that this "new system" you are creating is to be used by people
with current MUAs. Every MUA I am familiar with (the MS series and the
Netscape/Mozilla series) does the same thing when your "Person B decides to
resend": they create a new message, allowing B to put whatever he/she/it
wants to put in it, and appends the original message (optionally allowing B
to add, subtract, fold, spindle, and mutilate the original content).
This is not a transparent retransmittal of the original message from A as
an MTA would do. Anyone who views this message from B has no way of
determining what, if any, modifications B has made to the original content.
Resent- are special form of MUA message forwarding (which you might not be
familiar with if you use only Windows MUAs). In that case new message is
indeed transmitted as you describe but this new message includes in its
entirety the original message with no modifications. New message's subject,
To, From, Date are not encoded as normal message header fields but instead
added to the top (assuming RFC2822 compliance here) as Resent-From,
Resent-To, Resent-Subject, Resent-Date and Resent-Message-ID.
Compliant software is generally expected to treat this as new message and
use new "Resent-" fields in place where it would normally have looked at
From, To, Message-ID. Of course not every mail software is fully compliant
with this (to say the least...).
Now the problem for automated signatures as I see it is that original
message may have come without one but was by a user forwarded (with
Resent- semantics) and this time an MTA on the side of user who did
forwarding ads a signature with domain equivalent to the one added
into Resent-From. If you consider Resent-From to be equivalent to
From then the verifying side should just say that it is a valid
signature for the user who created the message in its last iteration.
However this opens up a whole where a 3rd party can get away with
becoming a 1st party by just adding Resent fields for new message
(but not for forwarding message and instead for newly created message).
Another scenario is for email message that has both From and Resent-From
but has no signature at all. Sine last party that sent the messge is
the one listed in Resent-From, the SSP check would have to be done
against that if you consider Resent-From to be equivalent to From
as Eric Allman basicly was implying (btw - another issue to consider
is that both From and Resent-From can have multiple addresses).
You need to decide how to deal with these situations and use of
Resent- fields in general and be careful to try to avoid breaking
existing functionality. And either way you go I suspect Resent- case
will have to be specifically mentioned in the documents you produce.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html