ietf-dkim
[Top] [All Lists]

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

2006-11-24 05:33:23

----- Original Message ----- From: "Charles Lindsey" <chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk>

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.

But it is not the original domain owner. 2822.FROM: is the author which on planet earth typically is the ower of the message. So who is the decider? The sender or the author/owner?

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?

The first one. But I admit the proposed algorithm to handle this is not one I personally prefer. However, I am not too worry about it because we are talking about a very rare situation and I still hold the position that any one that is going to invest in DKIM is not going to sabotage itself - not intentionally :-)

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.

It is not guranteed to be present. I wouldn't bet a design to be dependent on it simply because it isn't guaranteed to be followed and by far, it isn't.

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.

Huh? You said above "Changed in Transit" That is by definition a retransmission. Some middle ware/router is doing the "changed in transit" right?

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.

Neat. But no. This is where some design experience to understand it better helps. Stupid or not, that is the reality. You can't depend on it being available at the moment a MFA is triggered and you don't know when that MFA could be triggered Just consider Doug' MUA plans. It ain't going to work a good portion of the time simply because the Return-Path will not be in the headers.

Thats the facts.

---
HLS


_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

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