[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments: draft-moore-auto-email-response-04.txt


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@xxxxxxxxxxxxxxxxxxxxx" 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)