Re: [Exim] Administrivia - Christmas is coming, the autorepl…

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Exim Users Mailing List
Data:  
Para: Exim Users Mailing List
Asunto: Re: [Exim] Administrivia - Christmas is coming, the autoreplies are getting fat
[ On Friday, December 14, 2001 at 21:17:26 (-0800), Marc MERLIN wrote: ]
> Subject: Re: [Exim] Administrivia - Christmas is coming, the autoreplies are getting fat
>
> Err, my understanding has always that an unattended reply is always supposed
> to go the envelope sender


Nope, sorry, you've understood wrong. The envelope sender is only for
the MTA to use, not any MUA. The SMTP envelope sender address is only
where an SMTP-based MTA "MUST" send delivery status notifications
(i.e. bounces, etc.). It is not for use by the MUA. There may not even
always be an envelope sender address if the MTA isn't using SMTP, for
example.

> among other things to prevent loops when too
> autoresponders are talking to one another in unexpected situations like a
> stupid autoresponder that would eat an X-Loop header I insert and not insert
> any precedence headers.


I think you've somewhat confused the protocol levels here.....

> That's why any good autoresponder also sets the envelope to null


A program acting on behalf of the user, i.e. as a user agent, may not
always be permitted to set an empty sender address. Indeed not all mail
systems even have a way of controlling the desired sender address from
the user's level.

Perhaps you should go back and read the relevant RFCs, in detail. Try
very hard not to confuse SMTP with MAIL though -- they are at two very
different levels in the protocol stack.

In any case this is irrelevant for any properly designed and configured
autoresponder since they cannot get into dangerous mail loops in the
first place. (one pair of messages cycling per day does not constitute
a "dangerous mail loop"! ;-)

> With SMTP callback enabled, you very have good chances that the envelope
> sender is going to reach someone, the user who sent the mail, or the admin
> address that was often substituted for the exact purpose of catching bounces
> and autoreponders.


That may be so, but that is irrelevant to this issue. We're not talking
about SMTP MTA issues here.

Besides only a very few very lame idiots are implementing SMTP callbacks
unilaterally to verify the SMTP envelope sender address. That's a gross
violation of good sense, and as you of all people should know by now it
leads to increased amounts of interoperability problems, lost e-mail,
and all kinds of other gross RFC violations. I dislike failed bounces
as much as anyone else, but there are lines one must not cross, lines
which if crossed do far more harm than good.

> Regardless of what you say, many people have used the envelope sender and
> pointed it elsewhere with the understanding that all bounces and automated
> replies will go there.


Who cares what people have set their SMTP envelope sender address to!?!?!?

Once the message is being delivered to a Mail USER Agent it is no longer
an SMTP message. The SMTP envelope sender address no longer has any
importance and is never to be used for reply by a conforming Mail USER
Agent. If you send me a message and expect me to reply to it then it
makes no difference whether I reply to it with my interactive MUA, or I
reply to it with my automated MUA called 'vacation', you'd better have
set the proper RFC-2822 reply headers so that I've got a good enough
chance of sending my reply to you. When you send me a message you MUST
NOT care whether my MUA is interactive or automated if you have any hope
of expecting any reply.

> If you are on vacation, and your vacation program is broken and can't tell
> that the message came from a list, it should absolutely not reply to the
> poster of the message, it should go, again, to the envelope sender where the
> MLM can deal with it.


Sorry, but you're quite wrong about that. First off the MLM normally
won't receive mail sent to the SMTP envelope address used with mailing
lists -- the list owner will (unless perhaps its misconfigured). You
definitely do not ever want bounces going to the -request mailbox!!!
Secondly, as I've said before, any list owner in their right mind
doesn't ever want to see another autoresponder reply ever again, come
hell or high water.

Now where this could get a bit messy is when a MLM sets the reply-to
header, but doesn't add a proper "Precedence: list" header (only Lsoft's
LISTSERV is so lame as far as I know), and when the 'vacation' user
hasn't preloaded the recent recipients database with the mailing list's
reply-to address. Normally the adding of a reply-to by the MLM (where
one doesn't already exist) is a "good thing", but that's really only
because most people who post to mailing lists forget to do so themselves
(or fail to use MUAs that are intelligent enough to do that for them).
Unfortunately IFF the MLM doesn't also insert a "Precedence: list"
header then the result will be a vacation reply to the list injection
address. It's not a very likely scenario, and I really can't feel all
that much sympathy for anyone still using LISTSERV.... :-)

> So, yes, I completely agree with Miguel, and all the people who are already
> relying on this behavior: autoresponders should go to the envelope sender,
> like any other automated answer (and the envelope set to null in the
> process to avoid loops for good)


You can agree with whomever you want, but you and everyone you are
agreeing with are clearly wrong w.r.t. the RFCs. Re-read RFC-2822, and
read it again. Try to understand that RFC-2822 is not for SMTP alone.
There may not even be an equivalent of an envelope sender address!
Remember that 'vacation' programs and the like are Mail USER Agents!
They are conceptually no different from a human secretary who could be
asked to do the very same thing.

Now if more MUAs used the RFC-2822 "Sender:" header correctly, and if
all MTAs would lay their grubby hands off of it, then maybe an
'out-of-office' reply should be sent there instead of to the normal
reply address(es). The RFC isn't as clear on this issue, and I've not
yet thought through all the ramifications.

--
                                Greg A. Woods


+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>