[ On Sunday, January 25, 2004 at 10:32:50 (+0000), David Woodhouse wrote: ]
> Subject: Re: [Exim] Stopping out-of-office auto-reply mail loops
>
> Assuming, of course, that your human assistant has sufficient wit to
> tell list messages apart from personal ones with 100% reliability.
Well of course -- as does my vacation program. :-)
> Using
> the $sender_address renders it relatively harmless to accidentally
> respond to some list traffic, since your reply goes only to the list
> software.
That's about as lame an excuse for using $sender_address as I've ever
heard of.
> Using other random headers (especially Reply-To) is more
> dangerous.
Clearly you have a strange and twisted and broken idea about what the
word "dangerous" means in this context.
It is indeed annoying when some broken robot sends a vacation notice to
a whole mailing list, but it's hardly dangerous.
Assuming the robot is not so broken as to send multiple notices to every
mailing list posting, including its own, then it's hardly "dangerous"
for it to fail to identify a mailing list posting.
To be "dangerous" a robot in this context would have to break almost
_all_ of the rules of thumb I outlined. This is one of the reasons
there are so many rules of thumb.
> 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.
Your beliefs are your own, but that's the very definition of a "Non
sequitur" if I've ever seen one.
> 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.
That's completely lame argument too. You're responsible for your own
broken software and you use it at your own peril. If it doesn't do what
you want it to do then learn how to make it conform, and if it can't
then either fix it or find a replacement that can do what you want it to
do! We're talking about very common software here, not laws of physics!
> > 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?
Are you completely disconnected from the the real world to the extent
that you've even missed examples of this problem in this very forum?
> 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.
It's either a co-incidence, or broken software. RTFRFC again.
> 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.
In this case what you call an MTA is merely a program that can act as
both an MTA and as a MUA, and in this case it is clearly acting as an
MUA since it is working on behalf of the user. Please don't be confused
by the fact that all of this happens under the guise of one program --
that's simply an implementation optimisation (a flawed one, IMNSHO).
> You automatically avoid responding to bounces
Where you respond to has absolutely nothing to do with whether or not
you avoid responding to bounces.
If you have paid full attention to what I said initially you'll remember
that my rules of thumb also avoid responding to bounces, 100% guaranteed.
> You seem to advocate replying to other addresses as described in RFC2822
> §3.6.2;
Well of course! That is what an MUA is supposed to do.
> a behaviour which, in the absence of other heuristics,
Which of course is why other heuristics are necessary. The common sense
of a human assitant can, in this case, easily be programmed into an MUA
robot, and I've outlined all of the rules of thumb that can be used to
implement these heuristics.
> This is not explicitly defined in any RFC; it's clearly a matter of
> opinion.
Well, that's in part because RFCs don't always specify everything --
they're not ITU or ISO standards, and don't try to be such. As soon as
you try to stomp out opinion and interpretation when discussing RFCs
then you've automatically forfeited.
Having worked with e-mail software, RFCs, and a great deal of other
electronic communications tools and standards over the past two decades
or so, I think you can be sure my opinion on this matter is based on
solid experience and a very deep understanding of these issues.
I wish I could say I've discussed this very issue with Jon Postel
himself, but sadly I never did. However I am sure that he did at least
once read my view on these matters on a public forum (I've been fighting
against the sendmail implementation of "vacation" since the day I first
saw it) and given that he never responded to correct me (as he did on
other matters, sometimes even just to fill in details I wasn't aware of)
I can only assume that he agreed with what I said.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
