Keith Moore wrote:
draft-moore-auto-email-response-00.txt
First blush is that this is a *lot* broader in scope than what we have
been discussing. That's fine, but it's an important distinction. Nowhere
did your outline mention anything about mailing list subscription messages
or file robots, for example, and we didn't talk about those. The necessary
behaviors for those are a *lot* different than auto-responses from
vacation and virus programs.
I think the scope of the document is about right - one of the things
I've constantly seen every time the subject has come up in the past
10 years or so is that arguments about how one kind of responder should
work keep getting applied to other kinds of responders, whether
it makes sense or not. the point of having the scope as broad as it
is is to make it clear that different kinds of responders should have
different behavior. and if those different behaviors aren't adequately
distinguished in the current document, well it's just a -00 version.
The result is that a lot of the stuff that's defined doesn't really apply
to some of the message types. I see no need to define how mailing list
managers should format subscription confirmation messages, for example.
In general I think it's reasonable to say something on the order of
messages intended for humans should be simple and easily read, try not
to be annoying, etc., and potentially harmful attachments shouldn't
be included, etc. I won't argue that I have every detail right.
Hey, I wrote this thing in a day, and I suppose it shows.
What kind of interoperability challenges are being encountered from
subscription confirmation messages?
Another example:
| Response messages SHOULD NOT include significant content from the
| subject message.
Automatic transfers of group edits on a shared document depend on
"significant content" from the original message.
again, the goal here is to avoid being used to transmit spam or viruses.
I once got called in as a consultant for a bank that was using a piece
of software, whose auto-responder would respond with only a brief
annotation, and include the entire subject message in the response.
(it also copied everyone in the to and cc fields) spammers were using it
as an open relay. it's bad enough that the bank's facilities were being
used, what was even worse is that the porn spam was sent out with a
From address from the bank's domain...
I don't wish to exclude 'automatic transfers of group edits on a shared
document' from being able to use email as a transfer mechanism. however
I do think that automatic responders have responsibilities similar
to SMTP relays in that they need to take effective measures to avoid being
used as amplifiers or launderers of messages from unauthorized parties.
And so forth. I guess I am saying that I would be more comfortable if this
were scaled down to "human responder agents." We could probably be more
syntactically precise with a tighter scope. It's fine to go broader but
there will probably need to be a lot less rules (and even suggestions).
Again, I think the scope is about right. Maybe the solution is not to
have fewer rules but to rephrase the rules in terms of the problems
that they're meant to address. (e.g. 'responders SHOULD (or MUST)
ensure that they cannot be used to relay significant content from
unauthorized parties to destinations chosen by the message originator',
rather than 'SHOULD NOT include significant content...')
Keith