On Mon, 2004-12-20 at 06:06, David Woodhouse wrote:
On Fri, 2004-12-17 at 04:07 +0000, John Levine wrote:
MAIL FROM:
prvs=testlist-owner+M2=jlevine=world.std.com/0769c31f78(_at_)lists(_dot_)gurus(_dot_)com
From: johnl(_at_)iecc(_dot_)com
Sender: testlist-owner(_at_)lists(_dot_)gurus(_dot_)com
In this case, Sender: is the list to which the person subscribed, and
From: is an actual live person. For reasons debated elsewhere I think
that Sender: is the correct address to use here, since from the
recipient's point of view the mail was sent by the list.
The Sender: address isn't actually the same as the list address. It
does, however, contain 'testlist' and '@lists.gurus.com', just as the
reverse-path does. The reverse-path is indeed more obfuscated though.
So now we have at least _some_ argument for using RFC2822 addresses --
the fact that they're easier to recognise.
So talk me through what happens when I resend your interesting mail to
someone else for them to read:
MAIL FROM:<dwmw2(_at_)infradead(_dot_)org>
Resent-From: dwmw2(_at_)infradead(_dot_)org
From: johnl(_at_)iecc(_dot_)com
Sender: testlist-owner(_at_)lists(_dot_)gurus(_dot_)com
PS: When making arguments about 2821 addresses, don't forget to
explain what the plan is when the 2821 address is <>.
Was the explanation in
<1102376600(_dot_)5122(_dot_)64(_dot_)camel(_at_)localhost(_dot_)localdomain>
insufficient?
Although Jim Fenton has suggested currently these signature structures
are independent of any existing header, this would seem to make it
difficult for the signing domain to be visible anytime soon, however.
If I remember some of the solutions for visibility, one was to add a
comment within the From pretty-name indicating the domain used to sign
the message. (Placed there during the validation process.)
I suggested another method would be to flip how Resent-Sender and Sender
are handled in the case of user forwarding. Normally the intent is to
leave the message appear as if there are no changes to its content.
Obviously, applying a new signature would remove an assurance nothing
has changed. One could view the use of Sender the best header for
referencing a signature, but what happens when this message is forwarded
by the User. They typically want to preserve the From.
Flipping the use of Resent-Sender and Sender would have the
Resent-Sender indicate the "prior" Sender before the signature was
applied. Perhaps a standard comment of (Sender-Swap) to notate the
flipping of prior and current senders in the Resent-Sender header. In
the case where there was no Sender, it would be the From that is then
placed in the Resent-Sender header and a new Sender header is then
added. The Submitter signing the message would then always add the
Sender header where the Sender mailbox-domain then references the
information needed to validate the signature. This flipping of use
would ensure a greater likelihood of the signature surviving handling by
a legacy Submitter where no changes to message content were actually
made.
Using your example:
MAIL FROM:<dwmw2(_at_)infradead(_dot_)org>
Resent-From: dwmw2(_at_)infradead(_dot_)org
From: johnl(_at_)iecc(_dot_)com
Sender: testlist-owner(_at_)lists(_dot_)gurus(_dot_)com
would change to:
MAIL FROM:<dwmw2(_at_)infradead(_dot_)org>
Resent-Sender: testlist-owner(_at_)lists(_dot_)gurus(_dot_)com
(Sender-Swap)
Resent-From: dwmw2(_at_)infradead(_dot_)org
From: johnl(_at_)iecc(_dot_)com
Sender: postmaster(_at_)infradead(_dot_)org
If there was no Sender initially, then it would be:
MAIL FROM:<dwmw2(_at_)infradead(_dot_)org>
Resent-Sender: johnl(_at_)iecc(_dot_)com (Sender-Swap)
Resent-From: dwmw2(_at_)infradead(_dot_)org
From: johnl(_at_)iecc(_dot_)com
Sender: postmaster(_at_)infradead(_dot_)org
Unless the way Sender is handled for signatures is modified, there would
seem to be a binding required, if the signature is to reference off of a
header. One method would be to repeat the relevant Sender information,
but this is made difficult by differences between 822 and 2822 as to how
these headers are located. It would seem to be a weaker system to
suggest this must match with some Sender or Resent-Sender header made
vague by these differences.
-Doug