I'm missing something like a "clear structure" in that draft.
When reading the draft I always had to maintain kinda groups in my
brain and add each of the unnumberd list topics to a group or case
study. Maybe it's just me, but it would be nice to have a somewhat
clearer "clustering". Some information that belongs together is also
splitted across several sections.
Different types of people organize things in their heads differently,
so what is unclear to one person may be clear to another.
This document is basically orgnaized as follows:
- when to send automatic responses
- format of responses
- where to send responses
for all kinds of responses. An alternate organization would be
- rules for personal responders
- rules for group responders
- rules for service responders
but this would lead to a lot of either duplication, or
cross-referencing. The current structure seems cleaner to me.
- I can't see the main goal of this draft. Is it a BCP "how to write
a correct autoresponder"
The former, except that BCP is not the best label. It's intended as
a standards-track document. Nothing in RFC 2026 requires that all
protocol standards be specified down to the last bit.
or is it mainly a proposal for a new
2822 header field to standardise autoresponder communication. Or is
it both (IMHO a good idea)
Right now it's both, though I can certainly entertain arguments that
auto-submitted should be in a separate document.
Some of the following topics depend on that goal.
- Section 5 (Auto-Submitted) should be Section 2, as in sections 2,3,4
it is referenced but not yet defined.
Either way can be confusing, depending on how you represent information
in your head. I don't think it's worth changing the structure of the
document for this reason. And I really see auto-submitted as being
ancillary to this document.
- I'd like to see a clearer structure. There are three responders
defined (good). If I want to write a responder X what are the
pitfalls. In which cases should I not send an answer. In which cases
am I allowed to send a response and where should I send it to?
Return-Path? From? Resent-From?
Right now I don't see a way to specify to any significant level of
completeness when a responder should or should not send an answer.
Each responder is different. Maybe section 2 should say that
explicitly.
As for where the response should be sent, this is clearly specified
in section 4.
Resent-From isn't handled at all. But it is important IMHO for
vacation programs not to answer to the From but Resent-From if
present.
As I see it, resent-* is kind of an oddball half-forward mechanism -
it essentially says to the resent recipient "treat this as if it had
been sent to you directly". To me, that means having responses go
to the same place as they would have gone had the original recipient
responded. IF the resender had wanted responses to go somewhere else,
he would have forwarded the message.
Indeed, about the only time I personally use resent is to forward a
message to a responder - either because the original message was
misdirected or because I want to respond with a form letter. Having the
responder respond to Resent-From would make resent entirely useless,
IMHO.
OTOH, I can see that there might be exceptions to this for certain kinds
of responders.
Maybe I should add a discussion of resent-from in section 4, just
for the sake of completeness.
Also I disagree that responders should always send to the
Return-Path field if possible. Both (and Sender, Reply-To,
Resent-From also) serve different purposes. Szenario: a secretary
sends a message on behalf of her boss who is in the airplane. This
leads to (RFC2822 3.6.2. Originator fields)
Return-Path: secretary
Sender: secretary
From: boss
IMHO a personal responder (vacation) should send the message to the
From field.
Well, you're simply wrong about that :)
To me, it makes little sense for the secretary to get DSNs and MDNs but
for the boss to get vacation notices. If the boss really wants to see
all of those responses, he can tell his secretary to configure the
secretary's MUA to use the boss's address in MAIL FROM.
There are probably cases where From or even Resent-From is a better
choice than Return-Path, but Return-Path is only a SHOULD. Individual
responders are free to respond to From if there's a good reason to do
so.
In some sense, the intent of this document is to encourage greater
uniformity among mail responders without trying to force them all into
the same mold.
Even though the draft only says SHOULD NOT, IMHO responses should
*never* be sent to Sender. Sender is essentially a trace field, like
Received.
The arguments in (4) that From/Reply-To don't hold reliable
information also hold true for the Return-Path field, sometimes
even more, as I see a lot of hosts that are (speaking of the MTA)
misconfigured to the bones and use ENV senders like
"joe(_at_)localhost(_dot_)localdomain" but the address in the From field is
set
by the user to a correct and working address.
The appropriate fix for such situations should be obvious.
Look, we can either tell MUAs and responders to guess which address they
should respond to (based on the phase of the moon, a random number
derived from a camera on a crystal ball, or whatever) or we can specify
a _protocol_ (wow!) that lets the sender tell the recipient where to
send certain kinds of mail. We've chosen to do the latter: MAIL FROM/
Return-path for bounces and automatic responses, From for the author(s),
Reply-To for wherever the author(s) think the likely response should
go, and To/Cc if the responder wants to include the original recipients
of the message (at least, those who were visible to the responder). And
while it's true that this set of categories is occasionally
insufficient, there is ample experience to indicate that lumping all of
the sender/author addresses onto From is much, much worse.
Besides I think you missed the point of the argument in section 4.
It's not that From/Reply-to are likely to contain incorrect information,
it's that they exist for very different purposes than to specify the
destination of automatic responses.
- Backward compatibility
Currently most responders (if they do) use blacklists based on
addresses. That is mentioned in the draft, but a list of
addresses/address fragments would help like (perl regex):
if ($address =~
m/^$|daemon|request|bounce|mailer|postm|owner|lists|majordo|\
-(return|error)/i) { dontanswer; }
I specifically want to avoid including a complete list of such
addresses. (a) it would take too long. (b) even if I could make up a
complete list today, it wouldn't be complete a year from now.
Also current responders look (and set) the Precedence field.
Messages with a precedence of (bulk|list|junk)/i) should not be
answered. This is mentioned, but only for "list".
Precedence is just used as an example of a reason why a responder might
refuse to respond to a message. Perhaps you missed this part?
(Because Precedence is not a standard
header field, and its use and interpretation vary widely in the
wild, no particular responder behavior in the presence of
Precedence is recommended by this specification.)
Also the draft mentions header List-* fields. There are a lot of
others that should probably listed liked:
mailing-list, x-mailing-list, x-listname, x-listmember, x-loop
Some are not standard (x-) but widely used. If any of this is
present reponders that are not special purpose for exactly that
should not answer to messages with those header fields.
Again, for the reasons listed above, I'm not going to try to make a
complete list of reasons why a responder might choose to not respond to
a message.
- Subject lines
I think it is important that the original content of the Subject
line stays intact with a message from an responder and therefor a
MUST is inserted. Also the "portion" should be worded that it is
only allowed to truncate the subject line because of rfc2822
limitations (line length).
There are other reasons than that, e.g. to thwart buffer overflow
attacks. But I agree that in general it's undesirable to truncate
Subject lines that aren't excessively long. If I end up revising this
document for other reasons, (or if IESG insists) I'll consider
explaining more about when it's acceptable to truncate a Subject line.
About the "Auto:" I don't
like the allowance for translation.
I should have said this translation was for display purposes only.
I agree that mail processing software shouldn't translate this.
- VERPs (Variable Envelope Return Paths)
http://cr.yp.to/proto/verp.txt
IMHO good behaving responders should use these and code the
destination address.
IMHO good behaving responders should use <>. Most responders don't
need to process bounces.
- Section 5.2
Extension keywords [ ... ] other than "no" MAY assume that the
message was not manually submitted by a human.
"Auto-Submitted: no" means it is submitted by a human. If there is a
extension keyword (RFC released or experimental) that the responder
doesn't know about it IMHO *MUST* (not MAY) assume a not human
generated message and MUST NOT reply to it.
- As the most important and widely used responder is probably the
"vacation" type it would be nice to have a section with a strict
ruleset how a vacation program is to be written (timeout sender
addresses at least n days, dont answer if ..., send repsonse to,
...)
I agree that this would be useful. I'll consider putting this in an
Appendix, but probably as an example rather than as a normative part
of the specification.
- It would be nice to include a paragraph that requests anti virus
vendors to have their software stop sending out virus warnings
for viri faking sender addresses. They do analysis and they know
that the virus fakes the senders so they could stop sending out
false warnings to faked senders. Maybe it's more pressure for them
if a RFC requests it.
Seems like something that would be better suited for a separate RFC.
I doubt it would be controversial, and it would have more impact that
way than if it were embedded in a document about responders.
If it's not too late I'd definitely would vote for a third keyword
in "5.1 Syntax" and have "antivirus-generated" added. This would be
a huge benefit if antivirus vendors would add that (and probably in
the comment area the name of the virus).
This doesn't really seem consistent with the purpose of auto-submitted.
- Another member of IRTF ASRG BCP mentioned:
> I'm a little concerned about the top of section 2
> "An automatic responder MUST NOT send a response for every
> message ..." while this is in a sense the whole thrust of the
> draft, I'd imagine that it sits badly with some applications -
> like forms of RPC over SMTP. Perhaps this is one to ask someone
> who knows SOAP etc?
So maybe a wording like
"An automatic responder MUST NOT _blindly_ send a response for
every message received."
can make that statement more clearer.
I understand your concern, but I guess I don't think your suggested text
is any clearer.
Keith