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.
Why?
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: http://www.cs.man.ac.uk/~chl
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
http://mipassoc.org/dkim/ietf-list-rules.html