ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Optional sender

2008-02-04 22:01:11
Coming out of my lurking in the background...

So, as some folks are fond of saying, "I have no dog in this hunt." I'm really not entirely sure what bearing the existence or non-existence of the "Sender:" field has on the DKIM/SSP discussion (though I've been reading and trying to figure this out). But for purposes of clarifying:

On 2/4/08 at 3:15 AM -0500, Hector Santos wrote:

RFC 822 and RFC 2822 say:

   If the originator of the message can be indicated by a single
   mailbox and the author and transmitter are identical, the
   "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
   appear.

And the above is a two decade plus practice, you nor Pete is not going to change this.

Not only did my statement *not* change the above, I have no desire to change it. I wrote those words almost 7 years ago (as per the consensus of the DRUMS working group), and I still believe they reflect the consensus of the community.

In IETF protocols, requirements are not binary values like REQUIRED and NOT-REQUIRED. They are tri-valued: MUST, SHOULD, MAY (or, as 2119 also calls the values: REQUIRED, RECOMMENDED, and OPTIONAL). And they are *not* about conformance; they are about interoperability and reflect actual practice, not some imagined desired goal. In the case of 2822, the DRUMS WG was specifically evaluating e-mail practice and what was required of folks implementing those protocols.

Under ANY condition, for it to be REQUIRED, it must say MUST. It does not say MUST.

Those statements are all correct.

It says SHOULD, That is not a MUST, and even though 2119 says you should have a good reason to not follow the recommendation...

That's not all it says. In particular, something that one SHOULD do (in requirements-speak) may be "required for interoperation" and not doing so may be "behavior which has potential for causing harm", but it is recognized that "there may exist valid reasons in particular circumstances" not to do it. In particular, IETF protocols are written to distinguish things which one MUST and SHOULD do from things that are truly OPTIONAL. That is the conclusion regarding the "Sender:" field (and certain circumstances for its use) that those of us who worked on 2822 came to.

it implication is such that it is and was always OPTIONAL

Nope. No implication. We were perfectly explicit when we wrote 2822, and we believed at the time (and I certain still believe) that this was the consensus of the community.

To not be OPTIONAL, is must be a MUST and that is not what we have here.

That's simply false. This is why we have RFC 2119: We actually meant what is said in there, and that's why we used those words.

You can throw all the docs you want at me, it isn't going to change the reality.

And that is not what we judged the reality to be in 2001, and it is apparently not what the community believes the reality to be now. You may disagree with that, but that would put you in the "rough" part of the "consensus".

What you are implying, and this is where docs people might ought to try not always be wearing designer hats as well, that SMTP receivers has this a mandate to alter the message for the purpose of adding a "Required" Sender: header by analyzing the 2822 headers during submission and automatically add the missing sender field if the x821 return path does not equal x822 From header.

That is *not* what this document says at all. The "Sender:" field is an MUA field, not an MTA field, and SMTP receivers are not supposed to be inserting their data into fields (other than "Received:" and "Return-Path:"). Now, a Submission server, with other knowledge, may modify those fields, but only because it straddles MUA and MTA. But even so, it's supposed to insert the "agent responsible for the actual transmission of the message", not the return path, and only if it differs from the mailbox in the "From:" field.

Lots of (maybe most?) MUAs do the right thing here: If you send a message on behalf of someone else where the someone else is the author and you use their address in the "From:" field, your address goes into the "Sender:" field.

Look, Sender, if used, is typically added when its not the real author sending the original message.

Let's be careful with our words here: There is *always* a "sender" of a message. ALWAYS. There is sometimes (i.e., not always) a "Sender:" field in a message. When a message does not have a "Sender:" field, the sender of the message is the thing in the "From:" field (i.e., the author).

So, if the DKIM/SSP world want to use the *value* of the sender of the message for some purpose, that's always there. Sometimes it appears in the "From:" field (if there is no "Sender:" field) and sometimes it appears in the "Sender:" field. If DKIM/SSP wants to require (or REQUIRE) the "Sender:" field, that would be a bad thing. But I haven't seen anything to that effect in what I've been reading.

I'll go back to lurking now, and the rest of you can go back to your regularly scheduled love-fest.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html