[[ I'll leave all but mention of the reply-to issues/non-issues out of
this reply to the list! ;-) ]]
[ On Sunday, August 13, 2000 at 01:19:54 (+0300), Vadim Vygonets wrote: ]
> Subject: Re: [Exim] Should vacation messages go to reply_address or return_path?
>
> > The difference between vacation replies and bounces is in intent. RFC
> > 822 very explicitly allows for the sender to be different than the reply
> > address(es) and where that is intended the proper recipient of a vaction
> > notice is the reply address(es) (except of course for mailing lists).
> > Your opinion does not allow for this very necessary feature to be
> > implemented! :-)
>
> It depends what address should receive vacation messages.
If you take a look at RFC-822, and compare any "vacation" program with a
real-live personal assistant who would send out-of-office replies to
important messages, I think you'll see clearly that the reply should not
go to the $sender_address, but rather to the $reply_addresses. Note
also that the SMTP envelope sender address is not a concept that RFC-822
really knows anything about either (nor should it -- e-mail is transport
independent!).
That's all that's important here -- mailing lists are not (normally)
sources of important messages so whether or not people use "Reply-To" in
mailing list messages or not is totally irrelevant to "vacation" (if
properly designed and implemented it'll be ignoring such messages before
it even gets a chance to find out, or at least conceptually it will).
> > *BSD vacation has always depended on the fact that vacation messages
> > will have a "Precedence:" header which will prevent it from replying to
> > its own messages, and more importantly those of other vacation instances
> > too!
>
> If the other vacation instances support the header.
As I tried to show with my discussion of LISTSERV, most do, even those
not derrived from *BSD's version -- the proof is in the results and
arbitrary discussion about it won't change anything.
Besides, in the world of RFC-822 e-mail, I think *BSD vacation is the
basis for the whole idea in the first place. Other than the fact that
its author didn't read RFC-822 (at least none of the details! ;-) it has
all the basic concepts for a good design.
> MAILER-DAEMON is meaningless. The real standard is empty sender,
> and any autoresponder should look at the sender address to see if
> it's empty, and avoid responding if it's empty.
Excuse me? Unless you're talking strictly about SMTP (which would be
irrelevant to this thread), you're wrong. If I'm not mistaken Exim does
as Smail and Sendmail before it do -- they all translate the empty SMTP
return path ("<>") into the mailbox name "MAILER-DAEMON", and usually
append the helo name to qualify it, IIRC. In the case of Smail at least
the "From:" header is generated this way in the first place (using the
normal qualification mechanisms) so the reciving mailer need not create
and then qualify it.
I've never, ever, not once, seen '<>' appear in an automatically
generated RFC-822 header, especially not in a bounce, and I can't find
any evidence of it either in my RFC collection, nor in of my megabytes
of archived real e-mail.
My rewrite of *BSD vacation does indeed avoid replying to any
MAILER-DAEMON mailbox.
> The advantages in such schemes are that:
>
> 1. I don't receive any bounces from undeliverable vacation
> messages. I simply don't care about them. This is the whole
> idea of empty envelope sender.
>
> 2. I don't receive any autoresponses, from vacation programs or
> otherwise.
You might not want autoresponses from your vacation replies. Other
people might want certain types (eg. uneliverable notices). I certainly
do because if I go away on vacation I would like to know if my own reply
is going to bounce before I send it so that I can make a more timely
response by other means.
I.e. this is not something you can standardise without making people
angry at the standard and it authors! ;-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
