Hi,
I am a member of the IRTF ASRG BCP-subgroup and we were asked for
comments on the above mention draft.
I became aware of the existance of the draft at this time.
Please note, with all my critics I find it *very* important to have a
RFC defining the behavior of responders of all sorts and I am aware
that I am jumping in this discussion/the draft process at a very late point.
We tried to produce a summary of comments but I was nearly the only one
commenting, so we decided I should simply send my comments directly
and Keith asked to send them to this list.
Here we go ;-)
------------------------------------------------------------------------
General:
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.
- 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)
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.
- 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?
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. That kind of things are handled but on different places
(2)(4) which makes it hard to track.
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.
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.
- 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; }
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".
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.
- 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).
A lot of incident systems add incident tags to help them group the
messages to incidents and they do not send out receipt notifications
for an already existing indcident. Mangling/truncating the subject line
means loosing valuable information and may result in ping pongs.
About the "Auto:" I don't like the allowance for translation. What
will happen is that some braindead software translators translate
it and we will end up with scenarios that we have already with
"normal" email where we have:
Subject: Antw: RE: Re: AW: Re: RE: Re: original subject
because the software is too braindead. I'd force them to exactly
include "Auto: " at the beginning of the Subject line unless there
is already an (case insensitive match) "Auto: " present.
- 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.
- 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, ...)
- 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.
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 would result in a standard format that could be used by filters
and one could apply rules for
Auto-Submitted: antivirus-generated; W32/Sobig-F
and get rid of the 500 false alerts a day that hit the info@ addresses
and flooded our incident system.
IMHO the number of "warnings" floating around with each new fast spreading'
virus warrant this.
Adding this should be a 30 minute expense for AV vendors. I'd try to
lobby our vendor (Sophos) to add it and as soon as one has it the
others will follow.
- 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 hope this is helpful.
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"