Re: 2822upd-04 definition of terms needed

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.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102