Re: [Exim] Should vacation messages go to reply_address or r…

Top Page
Delete this message
Reply to this message
Author: Vadim Vygonets
Date:  
To: exim-users
Subject: Re: [Exim] Should vacation messages go to reply_address or return_path?
Quoth Greg A. Woods on Sat, Aug 12, 2000:
> [ On Saturday, August 12, 2000 at 17:42:18 (+0300), Vadim Vygonets wrote: ]
> > Subject: Re: [Exim] Should vacation messages go to reply_address or return_path?
> > In this case, they can never receive bounce messages. And if
> > they cannot receive bounces, they've got a bigger problem than
> > inability to receive vacation messages. In my opinion, vacation
> > messages may be treated as bounce messages, and a sender should
> > be equally willing to know about his mail not reaching the
> > recipient and the recipient not being able to read his mail.
>
> On the contrary, the *sender* will receive a bounce (unless the
> originating site is really screwed up!), just as is intended.


As it should.

> I think you're view of RFC 822 has been too narrow -- you should re-read
> it again with this in mind. There are many many possible ways in which
> the reply address(es) will be different than the sender address.


I know, of course. Mailing list, for one.

> 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.

> > And vacation messages should be sent from empty address <>,


> *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.

> Vacation programs probably shouldn't respond to any other kind of
> autoresponder either. However with the exception of a mail transport,
> all such avoidance must be through the de facto standard (contrary to
> what the *informational* RFC 2076 claims!) "Precedence:" header, or
> through the fact that the message is not directly addressed to the
> mailbox being responded to (i.e. in a "to" or "cc" header).


Vacation messages are addressed to their recipients in the To:
header. Precedence: header is non-standard, and you may not rely
on any other system to support it.

> Mail
> transport responses (aka bounces) are of course avoided by not
> responding to messages from "MAILER-DAEMON" (also just a de facto
> standard used to represent the null return path).


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.

> The only advantage to sending vacation reponses as if they are bounces
> (i.e. with an empty envelope sender address) would be to avoid having
> them bounce back to you. However since this is already handled properly
> by detecting the "Precedence:" header, and since it's hopefully rare,
> it's not really necessary to do so.


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.

> > Which is a clearly bad thing to do. If I want to reply to you
> > personally to a message you sent to a list, I don't want my reply
> > to be sent to the list.
>
> No, on the contrary it's a very good thing to do on a discussion list! ;-)


Not really. There is a differnence between "list reply" and
"personal reply". Let me give you an example.

Foo sends message to the list asking how to fix a problem. Bar,
who works in the same company, replies personally to Foo saying
that he fixed the problem, and discussing very graphically the
idiot Baz who created the problem in question. Now, if Foo sets
his Reply-To: header to the address of the public mailing list,
and Bar replies to this address thinking that he replies to Foo
directly, Baz will see it, become very unhappy about it, and make
Bar even more unhappy about what he wrote.

> I normally want you to send to the list because I'm participating in a
> "public" discussion. If you want to go off topic and don't want to
> reply to the list when you're replying to a message from the list,
> especialy when the originator wants you to reply to the list, then
> you're doing something special and you need to realise it so that you
> can adjust the addresses as necessary before you hit the send key.


In short, Reply-To: is for personal replies. If I want personal
replies to the message to be sent to my collegue who is more
interested in the issue then I am, I set a Reply-To: header.
List replies are different. List-Id: header is the way to go,
but it's not supported by all mail readers yet. Mutt lets the
users configure mailing list addresses, so 'r' replies to reply
address, 'L' replies to list, and 'g' is for "group" replies
(everyone).

Vadik.

--
The ill-formed Orange
Fails to satisfy the eye:
Segmentation fault.