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