Re: [Exim] Stopping out-of-office auto-reply mail loops

On Sat, 2004-01-24 at 14:46 -0500, Greg A. Woods wrote:
> It doesn't matter where this functionality is implemented -- it remains
> a fact that it's a mail agent acting on behalf of the owner of a mailbox.
>
> Such programs _should_ behave exactly as a user using a proper _MUA_
> would behave. Consider these programs to be your "administrative
> assistants", and just like a human assistant they send replies to the
> _originator_ of a message to indicate your disposition.

If it's just like a human assistant then I agree -- since a human
assistant won't repeatedly reply to the same or similar
(helpdesk-ticket-03412-bounce@...) addresses over and over again all day
and all night without smelling a rat.

Assuming, of course, that your human assistant has sufficient wit to
tell list messages apart from personal ones with 100% reliability. Using
the $sender_address renders it relatively harmless to accidentally
respond to some list traffic, since your reply goes only to the list
software. Using other random headers (especially Reply-To) is more
dangerous.

But in practice it'll never be 'just like a human assistant', especially
a clueful one. So I don't believe that it should be treated as one.

> This is described in RFC 2822 §3.6.2:

< snip text relevant only for user replies >

> (note that the "Sender:" field is _NOT_ the envelope sender!!!!)

Obviously. That's why I pointed out that they just _happened_ to be the
same in my example, as that is in fact the case in most situations.

> > An MUA gets to use those dangerous addresses
>
> "dangerous"!?!?!?!? You are very confused.

Not at all. It's dangerous to use these addresses because they may be
one-off addresses which will _also_ autoreply (the helpdesk- example is
one I've actually seen), because they may actually be set by some
misguided people in an attempt to trick the recipient's MUA into
replying to a mailing list when asked to create a personal reply, etc.

> The SMTP envelope sender address is the one that's _DANGEROUS_. It
> cannot, and must not, be trusted. It must be used _ONLY_ for
> non-delivery notifications by the MTA.

Why dangerous? What failure mode is there which leads to mail loops or
other 'dangerous' behaviour?

> > It's also used for notices of _delays_ in receipt.
>
> Yeah, well hopefully mailers generating such annoying and useless and
> spam-like notifications are on a quick and final decline.

I hope not. Such notices are often very useful to me.

If you don't like being told that a given user hasn't yet received the
email you sent, presumably you also find vacation messages to be
annoying, useless and spam-like? Or do you distinguish between 'unread
due to absence' and 'unread due to mail routing problems' for some
reason?

> > Consider the example from page 42 (§A.1.1) of RFC2822:
>
> You are confusing the layers, again, and you are not reading the full
> context of the RFC.

I remain unconfused. As I said, the Sender: header in the example will
_happen_ to match the SMTP reverse-path. Call it coincidence if you
will; I prefer to observe that there is a correlation.

> Also, remember, the "Sender:" field is _NOT_ the envelope sender!!!!

You said that already. It wasn't clear why you said it the first time
either.

> SMTP-based MTAs typically store a copy of the envelope sender field in
> the message body as the value of the "Return-Path:" field:

No mention was made here of fishing the SMTP reverse-path from the
Return-Path: header, since the messages were being generated by the MTA.
What you imagine seems to be a akin to a situation where mail is
delivered into mailboxes, then an IMAP client runs as a daemon, scanning
for \Recent messages and responding to them. Very few people do this;
it's almost always done at the MTA or MDA.

By responding to the reverse-path, you direct your disposition
notification to the same address as bounces, delay warnings, and other
notifications as discussed in RFC1891 are sent.

You automatically avoid responding to bounces, you eliminate the
possibility of replying to list-posters or worse to the list itself if
your list-filter lets some list messages slip through as if they were
personal.

You seem to advocate replying to other addresses as described in RFC2822
§3.6.2; a behaviour which, in the absence of other heuristics, leads to
mail loops such as the one which started this thread, to replies both to
mailing lists and to posters to those lists, and other problems.

This is not explicitly defined in any RFC; it's clearly a matter of
opinion. I don't think much will be achieved if we continue to repeat
and paraphrase our opinions at each other.

I believe that it is most similar to a delivery status notification, and
that the behaviour obtained by treating it that way is optimal.

You appear to believe that it should be handled as a real reply from the
user in question.

I am not not able to rightly apprehend the kind of confusion of ideas
that could provoke such an opinion.

--
dwmw2