ietf-822
[Top] [All Lists]

Re: I-D Recommendations for Automatic Responses to Electronic Mail

2002-06-06 10:28:20

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 behavior is so different for every potential application that you
rapidly run into the exception-for-every-rule problem, especially in the
context of universal auto-responder rules. All rules need to be prefaced
with "unless the app needs X, don't do X"

not when you're talking about security.  poorly-designed applications 
(or poorly-written implementations) can be threats to the network.
the fact that an app "needs" to do X is no excuse for doing X if that
creates a security threat.

now I'd agree that the rules need to be carefully written, but saying
"unless the app needs X, don't do X" is giving too much rope.

of course, nothing forces apps to comply with this document - the
penalty for failure to meet at MUST or failure to meet a SHOULD without
a good reason is that your app doesn't comply with the spec.
but the spec is only useful if it specifies what is needed for 
responders to behave well.  letting insecure responders off the
hook doesn't serve anybody's interest.
 
I would also think that a universal spec needs to be targetted towards
BCP, with no mandatory rules, no new on-the-wire formats (eg, new header
fields or mime types), and very generic recommendations such as "use
Return-Path when possible" and "avoid exposing unnecessary information".

You might think that, but frankly I'd call such thinking naive.  Part of 
the problem is that any address can be forged, and there's nothing to
stop someone from putting a victim's address in the return-path field
of a message that's sent to a robot.  

I wouldn't have put in auto-submitted except that some uniform means
of marking automatic responses is necessary to prevent loops.  There
are heuristics that could be used instead, but they don't work as well.

Keith

<Prev in Thread] Current Thread [Next in Thread>