Markus Stumpf writes:
- I can't see the main goal of this draft. Is it a BCP "how to write
a correct autoresponder" or is it mainly a proposal for a new
2822 header field to standardise autoresponder communication. Or is
it both (IMHO a good idea)
Shall we say it started out as a BCP, which then grew small prescriptive
leanings in the form of the "auto" prefix and auto-submitted?
I'll comment most of the points since noone else has, then I'll go eat.
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.
Alternatively, one might say it's justified first, and then defined afterwards.
IMHO a personal responder (vacation) should send the message to the
From field.
Do that, and the document die as irate mailing-list posters complain
about having received vacation messages whenever they post to a list.
The document may not be a pure BCP, but it has to stay close to best
current practice if it is to have any moral authority.
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.
Yep, but at least if things are vaguely close to correct, return-path
does no damage. Sending to reply-to means spewing vacation notices to a
lot of lists, for example. Hardly best current practice.
- 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; }
Do that, and watch the flames over what should/should not be included.
The same applies to x- fields.
Some people apparently think that mentioning the jungle of fields such as
mailing-list, x-mailing-list, x-listname, x-listmember, x-loop
in an RFC will only cause the jungle to grow worse. Mention only RFC
2369, and people will move to RFC 2369 syntax. There is a point to
that.
- VERPs (Variable Envelope Return Paths)
http://cr.yp.to/proto/verp.txt IMHO good behaving responders should
use these and code the destination address. If they receive a
bounce for that address they may put all messages in the responder
queue for that destination on hold or stop acting on messages from
that sender. So this should be recommended more explicitely.
That's nowhere close to BCP, and IMO far too controversial.
I kind of wish djb weren't so polarizing.
- 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,
...)
Achieve agreement on what the rules should be?
If it's not too late I'd definitely would vote for a third keyword
in "5.1 Syntax" and have "antivirus-generated" added. ...
Inappropriate, IMO. Too much of a special case, and besides, you don't
want to ignore a whole category just like that.
Lobby Sophos to add "auto-generated" and tweak your incident system to
add a call only when you receive an auto-generated message with
previously unseen body text. That way, you deal with each virus once,
which sounds about right.
- Another member of IRTF ASRG BCP mentioned:
> I'm a little concerned about the top of section 2
So maybe a wording like
"An automatic responder MUST NOT _blindly_ send a response for
every message received."
can make that statement more clearer.
Agreed.
--Arnt (sitting maybe 15m from Markus)