[Top] [All Lists]

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

2006-11-23 12:04:06
Charles Lindsey wrote:

> If writers of verifiers find it useful to use knowledge of the
> envelope addresses, then they will do so, whatever we say. Those
> fighting spam cannot do so with one hand tied behind their backs.

So you have a generalize rule everyone should follow?

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.

>> 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?

> and only the From if Sender is absent.


> 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.

> On top of that, the message might also be Resent, as
> Frank has pointed out.

Irrelevant because its a retransmission. News/Email gateways don't apply as well.

> Hopefully, the resender will have preserved the Signature put
> there on behalf of the original Sender. If the Resender also
> "signs everything", then an extra signature should be picked up there.

Exactly, so it doesn't apply.

> 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.

> 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.

>> 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. That that means is that a MFA (Mail Filtering Agent) that is outside the SMTP reception boundary DOES NOT have a guarantee the Return-Path will be part the headers.

Anyway, I still say this process has been made more difficult than it already is and we need to stop talking about 2821 considerations unless you want to rewrite the entire email framework where there is only a set of processing rules that applies across the board and for everyone to use. Needless to say, that isn't going to happen.

DKIM/SSP needs to fit the current framework - not the other way around.

The first basis for DKIM/SSP is to resolve and address the FIRST PARTY conditions. We have that.

We already know about the remaining key two issues for over 2 years

   - 3rd party
   - Mailing List

which are inter-related with each other and has not really changed since.

But the first party condition is the most important one to be resolved and DKIM/SSP does that.


NOTE WELL: This list operates according to

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