On Sunday 27 January 2008 13:04:52 Pete Resnick wrote:
On 1/26/08 at 11:30 PM -0500, Bruce Lilly wrote:
2822upd-04 uses several terms in ways which may or may not conflict
with related specifications and documents;
Overall comment: For most of these, you're going to have to show me a
specific example of a conflict to convince me that any change needs
to be made.
First I need to know how you're using the terms to determine whether
or not there IS a conflict.
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.
One example of the sort of suspected conflict, and the reason for the
request for definitions, is illustrated by the following example of
silliness:
Party A sends a message (e.g. an error report of some sort) to party
B. Because A, a good net citizen, wishes to avoid mail loops, he
sets the envelope address to a null path in accordance with the
provisions established for that purpose by RFC 821 and affirmed by
RFC 1123 (though curiously not permitted by 2821, but that's not
an issue for the draft under discussion). A does not want any
delivery reports or disposition notifications or message tracking
reports (or any response at all), so consequently does not include
SMTP commands and/or message fields which would trigger those (RFCs
3461-3464, 3798, 3888). A specifically states (in the message body)
that he does not want any response. Upon receipt of the message from
A (with null return path), 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 (as does the current draft text, from which the following are
quoted):
section 3.6.2, omitting pagination text and whitespace for brevity):
In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in the
"From:" field unless otherwise specified by the person composing the
reply.
and section 3.6.3:
When a message is a reply to another message, the mailboxes of the
authors of the original message (the mailboxes in the "From:" field)
or mailboxes specified in the "Reply-To:" field (if it exists) MAY
appear in the "To:" field of the reply since these would normally be
the primary recipients of the reply.
Note that neither text distinguishes between "automatic" (as used in
RFC 3834) replies vs. manually-initiated replies. It appears (lacking
a real definition) that the use of "automatic" and variants in 2822upd-04
differs markedly from the meaning in RFC 3834; but (lacking a real
definition of how they are intended to be interpreted in 2822upd-04)
that's just a hunch.
What can A do to avoid these annoying automated replies? Not much
(at least if he "really wants to do the right thing") according to
2822upd-04:
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
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.
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)).
[...]
automatic (and related terms) as used in sections 3.6.3 and 3.6.6.
Common use. I see no issue here.
Are you saying that you intended the meaning to be the same as in RFC
3834? If so, the text of the draft directly conflicts with provisions
of RFC 3834 (which has been extensively discussed on this list) which
are specifically designed to prevent such silly and undesired responses.
[specifically, RFC 3834 section 4 (titled "Where to send automatic
responses (and where not to send them)"), which states in part]:
Use of the From field as the destination for automatic responses has
some of the same problems as use of Reply-To. In particular, the
From field may list multiple addresses, while automatic responses
should only be sent to a single address. In general, the From and
Reply-To addresses are used in a variety of ways according to
differing circumstances, and for this reason Personal or Group
Responders cannot reliably assume that an address in the From or
Reply-To field is an appropriate destination for the response. For
these reasons the From field SHOULD NOT be used as a destination for
automatic responses.
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". I.e. one apparently says "do", the other clearly says
"don't". The one that says "don't" gives good definitions and rationale for
that recommendation. To date I see no definitions or rationale for the
apparently contrary recommendation in the draft under discussion. I
hope that the discrepancy is caused by different usage of "reply"/"response"
and/or "automatic", but I seem as yet unable to elicit a serious response
to my request for definitions corresponding to that usage.
See also RFC 3834 section 1 for an explanation of this issue.
See also RFC 3834 section 4 in its entirety, the last paragraph of which
provides a specific well-reasoned recommendation for where to send such
responses, one that is not mentioned at all in the draft currently under
discussion.
Given the specific text ("SHOULD [...] be sent to [...] From") in the
draft under discussion combined with the lack of mention of the use of the
Return-Path field for automated responses, the lack of concrete
definitions for "automated" and "reply" in the draft, as well as the lack
of even mere mention of RFC 3834 and/or Dave Crocker's mail architecture
draft, I cannot see how a reader of the document under discussion who is
not already intimately familiar with the latter unmentioned documents would
NOT be misled by the draft under discussion as it now stands into generating
silly unwanted automated responses as described above and in RFC 3834
section 1.
[...]
reply (and related terms) as used in sections 3.6.2, 3.6.3, and 3.6.6.
[...]
Flip answer: If you don't understand how these terms are being used,
you shouldn't be reading this document.
Flip (tongue-in-cheek) counterpoint: If you don't understand what you
mean by the terms, to the point where you cannot define how they are used
and/or how they relate to well-defined usage of the same or similar
terms in related specifications...[you can figure out the rest] :-)
More serious answer: Definition of such things belongs in a serious
applicability statement on e-mail. I think it will only add possible
confusion points, not remove them.
I disagree. I have specific reasons for asking about each of the terms
for which I requested definitions. It may well be the case that some
of the issues cannot be resolved definitively (in which case it should
at least be possible to include some non-normative text explaining the
issues), but I suspect that at the end of discussion, it will be possible
to resolve most conflicts between the draft text and other specifications.