Dan,
thanks for your comments. I agree with most of them.
In 1.1, the description of Group Responders should include an
example of a service address (support(_at_)example(_dot_)com), which you
mentioned in some email threads but isn't described directly
here in the I-D itself. The virus scanner is one example,
but the autoresponder for service addresses is a better (and
more common) example.
I'm not sure what you mean here. How is an autoresponder for
service addresses an example of a Group Responder, unless
it answers on behalf of several different recipients in a
way over which those recipients don't have control?
(or do I need to tweak my definition of Group Repsonder?
IMHO, recipient control over the response is the primary
thing that distinguishes Group from Personal responses)
Section 2.2 mentions multipart/alternative for multi-language
response, but also says multiple charsets?
multiple language often requires multiple charsets, at least until
the whole world adopts UTF-8 (I'm not holding my breath.)
OTOH, if you can put text in several languages in a single body part,
multipart/alternative might be overkill. current UAs don't seem to be
good at handling language differences in mp/alternative anyway.
But I can try to clarify the text.
By the way, I have noticed some autoresponders don't decode
RFC2047-encoded subject lines correctly when they include
the Subject of the "subject message" in the body of the
response.
hmmm.
Subject: Auto-Re: =?encoded-word?=
is perfectly valid (as long as there's a space after "Auto-Re:")
Section 3 says:
An automatic responder MUST NOT send a response
for every message received.
This requirement will break all mailing list software
(majordomo, LISTSERV, etc.), as they're supposed to
send a response for every message received.
are they really supposed to send a response to spam or viruses?
that's why I say that in practice every responder needs some
filtering to make sure the input is valid.
Later, it says:
Responders SHOULD check the destination
address for validity before generating the
response, to avoid cluttering up the local
mail queues with messages that cannot be
delivered or are unlikely to be useful.
I don't quite think this responsibility falls directly
on the responder, but rather on the local mail system
to validate RCPT TO addresses for syntactic validity
before accepting the message from an application such
as mail or an autoresponder.
the point is to avoid burdening the mail system with things
it shouldn't have to deal with. early detection wins.
the downside, I suppose, is that by giving this burden
to the responder then the risk is greater that at least
one component will impose inappropriate restrictions - like
those web sites that won't let me type in moore+frob(_at_)cs(_dot_)utk(_dot_)edu
as an email address because they think it's invalid.
I'll think about this some more.
In section 4, where you're describing Reply-To, it's
unclear in the I-D how
Sending automatic responses to Reply-To
addresses can thus result in a large number
of people receiving a useless or unwanted
message; it can also contribute to mail loops.
could occur. It's obvious to me where the person
accidentally (or on purpose) puts a mailing list name
in the Reply-To, but it may not be obvious to the
readers of the I-D how a "large number of people" could
receive the autoresponders message.
I can certainly elaborate on how this can happen.
As pointed out on
the mailing list, many group responders currently use
Reply-To because in many UAs, From isn't rewritable
(and MAIL FROM is even more unlikely to be rewritable),
and users might have legitimate reasons to specify
a different Reply-To, and users like that group
autoresponders use that specific Reply-To. I know
back in days that BITNET hosts had filestores, I
liked the ability to use Reply-To to direct file
requests to another mailbox for example.
I understand that such UAs exist (though I don't think
they're nearly so common anymore). I'm not sure how
much we should do to try to accomodate them. A UA that
can't set From but can set Reply-To just seems fundamentally
broken to me, though I'll grant that RFC 822 never said
"UAs MUST allow users to set the From field".
It's clearly wrong for a Personal or Group responder to
use Reply-To. It *might* be reasonable for a Service
repsonder to use Reply-To, because presumably the
sender expects an automatic response from a Service
responder and has set Reply-To. I tried to leave more
wiggle room for Service responders than Personal or
Group responders in this regard.
Section 5 defines new protocol elements, and as such
should be a separate standards-track document.
It could be split out if the ADs think that's the way to go,
and that's why it's in a separate section. But I'd like to
keep it in the current document as long as it's feasable to
do that. Maintaining two documents would require more work :)
Section 5.2 says:
Such a field MAY be supplied for a manually
sent message that is intended to test the
response of other mail system components to
the presence of an Auto-Submitted field in a
message.
During debugging and testing, there are lots of things that
users, developers, postmasters, and system administrators
will do, some of which purposefully violate MUSTs. I think
you can safely strike the sentence above.
actually in rereading the document I had decided to move it
elsewhere. the main purpose here is to discourage UAs from
preventing humans from setting auto-submitted, but that could
be made clearer.
Is your I-D intended to be a BCP document?
either that or standards-track. whatever the ADs want.
Keith