[Top] [All Lists]

Re: 2822upd-04 definition of terms needed

2008-01-27 23:19:04

On 1/27/08 at 3:24 PM -0500, Bruce Lilly wrote:

On Sunday 27 January 2008 13:04:52 Pete Resnick wrote:

As I've said before to others, people can purposely misread any specification we right, so I'm not inclined to try to complicate things to try plug some perceived hole unless it's actually going to stop someone who really wants to do the right thing from doing something silly.

I don't pretend to know whether or not any given person wants to do the right thing. I do know that a significant number of systems are doing something quite silly, and I suspect that that silliness is due in large measure to ambiguities in 2822 and/or conflicts with other relevant specifications, and I further suspect that the amount of such silliness will increase in the absence of clarification.

Again, you're going to have to a *real* example of an implementation that intended to do the right thing but was unable to due to this so-called ambiguity to convince me that much of this needs clarification.

...B, a rather silly system, sends an automatic ***receipt*** message. Contrary to years of established practice and good sense, not to mention a documented strong recommendation against doing so in RFC 3834, B sends that automated reply to the mailbox(es) in the From field of A's original message, completely ignoring the null return path. Why does B do such a silly thing? Because RFC 2822 tells him to do so...
[My emphasis added]

First of all, B not only does the wrong thing, but B thinks (for some reason as yet unclear to me) that a receipt message is a reply. I'm not sure how B made that leap (you'd think the author of B might have wondered, "Gee, I wonder whether there's a document defining receipts, as 2822 only talks about replies, which seem like a different thing."), but even so, I have to wonder what implementation this is: I would be flabbergasted if such an implementor even found section 3.6.2 and would love to hear of such an example.

Either way, I am completely unconvinced that saying *anything* in 3.6.2 about what a reply is would convince any implementor to do something different in the scenario above.

Note that neither text distinguishes between "automatic" (as used in RFC 3834) replies vs. manually-initiated replies.

You will note that neither 2822 nor 3834 ever use the term "automatic replies". 2822 talks (in a non-normative note) about applications with "automatic reply commands", whereas 3834 only ever uses the word "automatic" in the phrase "automatic responses".

What can A do to avoid these annoying automated replies?

He can point the sender to 3834, which talks about sending automatic responses.

section 3.6.2:

   In all cases, the "From:" field SHOULD NOT contain any mailbox that
   does not belong to the author(s) of the message.

so A is discouraged from setting the from field to something like <go(_dot_)away(_dot_)kid(_at_)you(_dot_)bother(_dot_)me(_dot_)example>

And if A, being someone who reads RFCs, does not understand what the term SHOULD NOT means, there's not a whole lot we can do about it. Again, additional text won't help.

and while the earlier requirement for at least one destination field (e.g. an empty Bcc field) has been dropped without explanation, viz.:

   8.   Requirement for destinations removed.

Please let's stick to one discussion at a time. But FYI: It was discussed and noted that there existed implementations that created messages without destinations for perfectly valid reasons and consensus was reached that the requirement was neither necessary nor reflected current practice.

there is no provision for not providing an originator field (in order to preclude the aforementioned silly replies, not to mention support for anonymity (e.g. for whistleblowers)).

Again, there are valid reasons to put a mailbox that does not belong to the author into the "From:" field, and that's why it is a SHOULD NOT. As was pointed out elsewhere, <anonymous(_at_)[127(_dot_)0(_dot_)0(_dot_)1]> is a syntactically valid mailbox. (BTW: Any whistle blower who thinks changing the "From:" field of a message for anonymity purposes has different problems.)

Are you saying that you intended the meaning to be the same as in RFC 3834?

No, I'm saying the English word "automatic" is being used in two completely different contexts in the two documents.

N.B. the draft text "SHOULD by default [...] be sent to [...] the 'From:' field" vs. RFC 3834 "the From field SHOULD NOT be used [...] for automatic responses".

Since the draft talks about "replies" and 3834 talks about "automatic responses", (two very different terms), I am not surprised that they say to do two different things with those. To wit: Section 3.1.2 of 3834 says that replies should go to the From address.

I have specific reasons for asking about each of the terms for which I requested definitions.

Which you have yet to give. What is the reason that these terms need better defining in this document? If you can demonstrate some real potential for confusion (and examples of where this confusion has occurred would help), I'm sure the bunch of us would be happy to come up with some text.

Pete Resnick <>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102