[Top] [All Lists]

Re: [ietf-dkim] Re: "I sign everything" yes/no

2006-11-24 04:37:09
On Thu, 23 Nov 2006 19:00:28 -0000, Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:

Charles Lindsey wrote:

That is what we need to stop trying to impose.  What is consistent in
all systems is a 2822.FROM and that is what DKIM/SSP is based on.

Then DKIM/SSP is WRONG, because it can't work like that.

 >> Its the 2822.FROM: that is "My" mail.   That is the constant,
 >> consistent frame work in every mail system, including gateways.
 >> The 2822.FROM is the "connector' between what is WRITTEN and what
 >> is SHOWN.
 > On the contrary, it is the Sender header if present that should
 > be the decider,

Who says?

RFC 2822, which makes it clear that the Sender, if present, indicates where the email _really_ came from.

 > and only the From if Sender is absent.


RFC 2822 again.

 > People keep ignoring the fact that there can be several addresses
 > in a From header (in which case Sender is obligatory).

No one ignored it. It is part of the specs.

Quite. So it a From shows that the mail came from five people at five different domains, some of which "sign all mail" and some do not, then which domain gets to sign the message and which domain's SSP is a verifier supposed to consult?

 > BTW, the bit in the base document that says the "From" MUST
 > always be signed is wrong. It should have been the Sender, and
 > maybe any Resent-From too.

No, SENDER nor Resent-* anything is guaranteed.  2822.From is.

It is indeed guaranteed to be present, but not guaranteed to contain the information you need.

 > And that MUST is going to haunt us again when EAI happens,
 > because both From and Sender may well get changed in transit.

A retransmission.  Doesn't apply.

No, it is NOT a retransmissiom. Read the EAI drafts.

 >> Others, and they could be modern too, will process the mail after
 >> it is received.  At this point, the technology can not be
 >> dependent on any 2821 information being available to them.

 > On the contrary, the MAIL FROM should now be in the Return-Path,
 > and then it is a 2822 header and the verifier is allowed to look
 > at it. So why shouldn't it look at it before then?

Nope. A in-transient system will store the Return-Path, but there is no guarantee it will passed on to the next process. In fact, many systems will STRIP it once it reaches its final destination.

Then how come RFC 2821 says "..., exactly one return path SHOULD be present when the message is delivered"? If that information is present when the message is handed off by SMTP, and the local delivery system then throws it away before doing its filtering based on what the verifier found, then that is its own stupid fault.

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131     Web:
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
NOTE WELL: This list operates according to

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