Stopping out-of-office auto-reply mail loops

[Andrew Lewis]

Hello,

Currently I am experiencing problems where-in one user will set their
out-of-office auto-reply on, and then mail another user who's auto-reply
is on, causing an infinite mail-loop.

I believe I can rate-limit these messages, which could be good, but I
didn't get working when I set everything up. What I would really like to
do is *check* if the sending address has auto-reply on and send no reply
back if they do. How to implement this as a condition in my
router/transport?

I have:

MYSQL_VACATIONEMAIL = SELECT email from vacation WHERE
email='${quote_mysql:$local_part_prefix$local_part$local_part_suffix@$domain}' AND onvacation='yes'
MYSQL_VACATIONSUBJECT = SELECT subject from vacation WHERE
email='${quote_mysql:$local_part_prefix$local_part$local_part_suffix@$domain}'
MYSQL_VACATIONMESSAGE = SELECT message from vacation WHERE
email='${quote_mysql:$local_part_prefix$local_part$local_part_suffix@$domain}'

vacation:
driver = manualroute
route_data = ${lookup mysql{MYSQL_VACATIONEMAIL}}
unseen
no_expn
no_verify
transport = vacation_user

vacation_user:
driver = autoreply
from = ${local_part_prefix}${local_part}${local_part_suffix}@${domain}
subject = "Re: $h_Subject"
text = ${lookup mysql {MYSQL_VACATIONMESSAGE} {$value} fail }
to = $reply_address
log =
/var/spool/exim/vacation/${local_part_prefix}${local_part}${local_part_suffix}@${domain}.log
user = mail

If I wanted to now have a condition like:

MYSQL_SENDERONVACATION = SELECT email from vacation WHERE
email='${quote_mysql:$reply_address}' AND onvacation='yes';

How could I integrate that?

If some-one can show me a working example of rate-limitting replies that
would be cool too.

Please CC me on your reply.

Best Regards,
AL.


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Konrad Michels]

My config for vacation messages, for what its worth, looks as follows
and only ever sends one reply to any specific sender address:

In routers I have:

vacation:
driver = accept
check_local_user
require_files = $home/.vacation
no_verify
# do not send reply to errors or lists
senders = "! ^.*-***@.*:\
! ^owner-.*@.*:\
! ^***@.*:\
! ^***@.*:\
! ^***@.*:\
! ^mailer-***@.*"
# do not reply to errors and bounces or lists
condition = "${if or {{match {$h_precedence:}
{(?i)junk|bulk|list}} \
{eq {$sender_address} {}}} {no} {yes}}"
transport = vacation_reply
unseen

In transports I have:

vacation_reply:
driver = autoreply
file = $home/.vacation
file_expand
log = $home/vacation.log
once = $home/vacation.db
from = $***@surfkitchen.com
to = $sender_address
subject = "Re: $h_subject"
text = "Dear $h_from\n\n\
This is an automatic reply. Please feel free to send
additional\n\
mail to me, as only this one notice will be generated. The
following\n\
is a pre-recorded message, sent on behalf of\n\
${local_part}@surfkitchen.com:\n\
================================================\n\n"

Post by Andrew Lewis
Hello,
Currently I am experiencing problems where-in one user will set their
out-of-office auto-reply on, and then mail another user who's auto-reply
is on, causing an infinite mail-loop.
I believe I can rate-limit these messages, which could be good, but I
didn't get working when I set everything up. What I would really like to
do is *check* if the sending address has auto-reply on and send no reply
back if they do. How to implement this as a condition in my
router/transport?
MYSQL_VACATIONEMAIL = SELECT email from vacation WHERE
MYSQL_VACATIONSUBJECT = SELECT subject from vacation WHERE
MYSQL_VACATIONMESSAGE = SELECT message from vacation WHERE
driver = manualroute
route_data = ${lookup mysql{MYSQL_VACATIONEMAIL}}
unseen
no_expn
no_verify
transport = vacation_user
driver = autoreply
subject = "Re: $h_Subject"
text = ${lookup mysql {MYSQL_VACATIONMESSAGE} {$value} fail }
to = $reply_address
log =
user = mail
MYSQL_SENDERONVACATION = SELECT email from vacation WHERE
email='${quote_mysql:$reply_address}' AND onvacation='yes';
How could I integrate that?
If some-one can show me a working example of rate-limitting replies that
would be cool too.
Please CC me on your reply.
Best Regards,
AL.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

--
***********************************************************
* Konrad Michels
* IT Manager
* Surfkitchen Limited
* [phone]
***********************************************************

The information contained in this message is confidential. It is
intended solely for the use of the individual or entity to whom it is
addressed and other authorised to receive it. If the reader of this
message is not the intended recipient, you are hereby notified that any
use, copying, dissemination or disclosure of this information is
strictly prohibited. If you are not the intended recipient, please
delete it immediately and contact the sender by e-mail or telephone.
Internet e-mails are not necessarily secure. SurfKitchen accepts no
responsibility either for breaches of confidence that may arise through
the use of this medium or for changes to any e-mail which occur after
the e-mail has been sent.


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by Konrad Michels
My config for vacation messages, for what its worth, looks as follows

More importantly though, it seems to correctly reply to the
$sender_address rather than picking addresses from elsewhere, and it
refrains from replying to bounces.

--
dwmw2



--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Konrad Michels]

Glad to have helped!

Thankyou both very much Dave & Konrad for your help. :)
Using bits of Konrad's config, I believe I have successfully solved all
problems discussed. :)

--
***********************************************************
* Konrad Michels
* IT Manager
* Surfkitchen Limited
* [phone]
***********************************************************

The information contained in this message is confidential. It is
intended solely for the use of the individual or entity to whom it is
addressed and other authorised to receive it. If the reader of this
message is not the intended recipient, you are hereby notified that any
use, copying, dissemination or disclosure of this information is
strictly prohibited. If you are not the intended recipient, please
delete it immediately and contact the sender by e-mail or telephone.
Internet e-mails are not necessarily secure. SurfKitchen accepts no
responsibility either for breaches of confidence that may arise through
the use of this medium or for changes to any e-mail which occur after
the e-mail has been sent.


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Andrew Lewis]

Thankyou both very much Dave & Konrad for your help. :)

Using bits of Konrad's config, I believe I have successfully solved all
problems discussed. :)


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by Andrew Lewis
Hello,
Currently I am experiencing problems where-in one user will set their
out-of-office auto-reply on, and then mail another user who's auto-reply
is on, causing an infinite mail-loop.

Autoreplies should only ever be sent to the SMTP reverse-path; the
address to which bounces go -- never to any address found in the mail
itself, even the From: header.

Likewise, autoreplies should always be sent with an empty reverse-path,
just like bounces -- so that they don't trigger further bounces.

It looks like you're violating the first of these -- you're picking
random addresses from the headers to reply to, and that means you're
replying even to bounce messages.

To fix this, I think you need to change 'to = $reply_address' into
'to = $sender_address' in your vacation_user transport, and possibly
also make the vacation router happen only for non-null senders -- would
that be 'senders = ! :' ?

--
dwmw2



--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Greg A. Woods]

[ On Friday, January 23, 2004 at 10:03:14 (+0000), David Woodhouse wrote: ]

Subject: Re: [Exim] Stopping out-of-office auto-reply mail loops
Autoreplies should only ever be sent to the SMTP reverse-path;

That is very _VERY_ wrong.

A proper out-of-office/vacation autoresponder is what's called a "mail
agent". Such programs _should_ behave exactly as a user using a proper
MUA would behave. I.e. they _should_ follow all of the rules for
finding a reply address in the RFC [2]822 headers of the message being
replied to.

The most important thing any mail agent _should_ be doing is restricting
the frequency at which it sends a reply to any given destination
address. For "vacation" autoresonders the most appropriate delay
between responses is at least 7 days. All of the other rules I posted
are merely for reducing the annoyances that can be caused by such mail
agents.

The sender address is an unauthenticated (and unauthenticatable) address
that _should_ only ever be used by an MTA as the destination for notices
about the non-delivery of a message that MTA had taken responsibility
for delivering.

--
Greg A. Woods

[phone] VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by Greg A. Woods
[ On Friday, January 23, 2004 at 10:03:14 (+0000), David Woodhouse wrote: ]

Subject: Re: [Exim] Stopping out-of-office auto-reply mail loops
Autoreplies should only ever be sent to the SMTP reverse-path;

That is very _VERY_ wrong.
A proper out-of-office/vacation autoresponder is what's called a "mail
agent". Such programs _should_ behave exactly as a user using a proper
MUA would behave.

No.

What we were looking at was clearly an example of implementing this in
the MTA, with no user present. An MUA gets to use those dangerous
addresses because, by definition, it has a _user_. The user isn't going
to _voluntarily_ participate in a mail loop.

Vacation messages aren't generated by an MUA, unless the user configures
it extremely strangely and leaves it running in her absence. They're
delivered by the MTA or more correctly I suppose the MDA. The whole
point is that the user is _absent_.

Post by Greg A. Woods
The sender address is an unauthenticated (and unauthenticatable) address
that _should_ only ever be used by an MTA as the destination for notices
about the non-delivery of a message that MTA had taken responsibility
for delivering.

It's also used for notices of _delays_ in receipt. The sender address is
not for replies, that's true -- it's for notification to the _sender_
(as distinct from the From address) about what has happened to the
message.

What is a vacation message if not a form of delivery status notification
-- a notification that the message has not been received by its intended
recipient yet, just like the messages which inform the sender that it's
still on the queue after three days? Just like those and DSN (cf.
RFC1891) it should go only to the SMTP reverse-path; nowhere else.

Consider the example from page 42 (§A.1.1) of RFC2822:

If John's secretary Michael actually sent the message, though John
was the author and replies to this message should go back to him, the
sender field would be used:

----
From: John Doe <***@machine.example>
Sender: Michael Jones <***@machine.example>
To: Mary Smith <***@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <***@local.machine.example>

This is a message just to say hello.
So, "Hello".
----

In this case, the SMTP reverse-path is (as usual) going to match the
Sender: header. Delivery failure reports go correctly to Michael the
secretary, as do reports of the mail being delayed and still on a queue
somewhere. Reports of the mail being delayed because Mary is on vacation
should _also_ be going to Michael -- not to John.

--
dwmw2



--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[James P. Roberts]

----- Original Message -----

Post by David Woodhouse
In this case, the SMTP reverse-path is (as usual) going to match the
Sender: header. Delivery failure reports go correctly to Michael the
secretary, as do reports of the mail being delayed and still on a queue
somewhere. Reports of the mail being delayed because Mary is on vacation
should _also_ be going to Michael -- not to John.
--
dwmw2

I respectfully submit that a vacation auto-reply is different from a delayed
or undelivered email notification. In the former case, the mail has actually
been delivered to the end-user's mailbox (i.e. the MTA's job w.r.t. this
message is complete). In the latter case, it has *not* been delivered. These
are very different things.

I do not have a position on who an auto-responder should reply to. I am
simply pointing out that these two types of messages are different; and
therefore, it is not necessarily logical to claim they should be handled the
same way. (It doesn't mean they shouldn't be treated the same, either! It
just doesn't follow that they must, that's all.)

Jim Roberts


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by James P. Roberts
I respectfully submit that a vacation auto-reply is different from a delayed
or undelivered email notification. In the former case, the mail has actually
been delivered to the end-user's mailbox (i.e. the MTA's job w.r.t. this
message is complete). In the latter case, it has *not* been delivered. These
are very different things.

Just as a delay notification is different from a bounce, indeed. But to
the recipient they are all extremely similar, because they all signify
that the intended recipient hasn't yet read the email in question.

They're all information which is appropriate for the sender of the
email, rather than for the address listed in From: or Reply-To: headers.

Especially in a world where Reply-To: headers sometimes get munged to
point at mailing lists, and where the $sender_address is often pointed
at list manager software etc.

--
dwmw2



--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Greg A. Woods]

[ On Sunday, January 25, 2004 at 09:38:03 (+0000), David Woodhouse wrote: ]

Subject: Re: [Exim] Stopping out-of-office auto-reply mail loops
Especially in a world where Reply-To: headers sometimes get munged to
point at mailing lists, and where the $sender_address is often pointed
at list manager software etc.

Well since you're not supposed to be sending vacation replies to any
message received from a mailing list in the first place (and there are
usually a multitude of ways to detect and avoid doing so), then it's
irrelevant whether or not the MLM software may have munged the reply-to:
header or not.

--
Greg A. Woods

[phone] VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by Greg A. Woods
Well since you're not supposed to be sending vacation replies to any
message received from a mailing list in the first place (and there are
usually a multitude of ways to detect and avoid doing so),

Hence the phrase 'failure mode'.

Post by Greg A. Woods
then it's irrelevant whether or not the MLM software may have munged
the reply-to: header or not.

That's an interesting opinion. Personally I like to consider the
potential failure modes, especially when we're talking just about
failures of ad-hoc heuristics such as list detection.

I accept that this is, however, merely my idiosyncrasy.

--
dwmw2


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Greg A. Woods]

[ On Saturday, January 24, 2004 at 11:34:59 (+0000), David Woodhouse wrote: ]

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

Post by Greg A. Woods
[ On Friday, January 23, 2004 at 10:03:14 (+0000), David Woodhouse wrote: ]

Subject: Re: [Exim] Stopping out-of-office auto-reply mail loops
Autoreplies should only ever be sent to the SMTP reverse-path;

That is very _VERY_ wrong.
A proper out-of-office/vacation autoresponder is what's called a "mail
agent". Such programs _should_ behave exactly as a user using a proper
MUA would behave.

No.
What we were looking at was clearly an example of implementing this in
the MTA, with no user present.

NO. :-)

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. This is
described in RFC 2822 §3.6.2:

The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a
comma-separated list of one or more mailbox specifications. If the
from field contains more than one mailbox specification in the
mailbox-list, then the sender field, containing the field name
"Sender" and a single mailbox specification, MUST appear in the
message. In either case, an optional reply-to field MAY also be
included, which contains the field name "Reply-To" and a
comma-separated list of one or more addresses.

The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.

The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the mailbox(es) to which the author of the message suggests
that replies be sent. In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in the
"From:" field unless otherwise specified by the person composing the
reply.

In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message. See also section
3.6.3 for more information on forming the destination addresses for a
reply.


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

An MUA gets to use those dangerous
addresses

"dangerous"!?!?!?!? You are very confused.

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.

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.
You are confusing the layers, again, and you are not reading the full
context of the RFC. RFC 2822 knows and says nothing whatsoever about
the SMTP envelope sender address execept the folloing, quoted further
from RFC 2822 §1.1 (Scope):

In the context of electronic mail, messages are viewed as having an
envelope and contents. The envelope contains whatever information is
needed to accomplish transmission and delivery. (See [RFC2821] for a
discussion of the envelope.) The contents comprise the object to be
delivered to the recipient. This standard applies only to the format
and some of the semantics of message contents. It contains no
specification of the information in the envelope.

However, some message systems may use information from the contents
to create the envelope. It is intended that this standard facilitate
the acquisition of such information by programs.

This specification is intended as a definition of what message
content format is to be passed between systems. Though some message
systems locally store messages in this format (which eliminates the
need for translation between formats) and others use formats that
differ from the one specified in this standard, local storage is
outside of the scope of this standard.


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

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

3.6.7. Trace fields

The trace fields are a group of header fields consisting of an
optional "Return-Path:" field, and one or more "Received:" fields.
The "Return-Path:" header field contains a pair of angle brackets
that enclose an optional addr-spec. The "Received:" field contains a
(possibly empty) list of name/value pairs followed by a semicolon and
a date-time specification. The first item of the name/value pair is
defined by item-name, and the second item is either an addr-spec, an
atom, a domain, or a msg-id. Further restrictions may be applied to
the syntax of the trace fields by standards that provide for their
use, such as [RFC2821].

Note that anyone even dreaming about using the return-path field to
route a reply is seriously mis-interpreting the purpose of that field:

A full discussion of the Internet mail use of trace fields is
contained in [RFC2821]. For the purposes of this standard, the trace
fields are strictly informational, and any formal interpretation of
them is outside of the scope of this document.

--
Greg A. Woods

[phone] VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by Greg A. Woods
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-***@...) 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.
< snip text relevant only for user replies >

Post by Greg A. Woods
(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.

Post by Greg A. Woods

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.

Post by Greg A. Woods
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?

Post by Greg A. Woods

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?

Post by Greg A. Woods
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.

Post by Greg A. Woods
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.

Post by Greg A. Woods
SMTP-based MTAs typically store a copy of the envelope sender field in

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



--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Greg A. Woods]

[ 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!

Post by Greg A. Woods
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

[phone] VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by Greg A. Woods

Post by David Woodhouse
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.

I assert that does not behave like a human agent, therefore we shouldn't
trust it to behave like one. You think that's a non sequitur.
Interesting.

Post by Greg A. Woods
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!

My software does precisely what I want it to, thank you.

Post by Greg A. Woods
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 have no recollection of seeing any examples of problems caused by
responses to $sender_address in this forum. Yet this thread was started
by a problem caused by responding to $reply_address.

Do please enlighten me if you would.

Post by Greg A. Woods

Post by David Woodhouse
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.

On the mail to which I'm replying I see:
Return-path: <exim-users-***@exim.org>
Sender: exim-users-***@exim.org

Do you _really_ assert that this is either coincidence or broken
software, rather than normal behaviour? Which of the two, in this
particular case, do you believe to be the case -- is it just a
coincidence or is something broken?

Post by Greg A. Woods
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).

I assure you I'm not at all confused, thank you.

Post by Greg A. Woods

Post by David Woodhouse
You automatically avoid responding to bounces

Where you respond to has absolutely nothing to do with whether or not
you avoid responding to bounces.

Theoretically true, practically false. Take, for example, the example
which started this thread. If it had been configured with
'to = $sender_address' I believe it would have automatically avoided
responding to bounces.

I assure you I have a thorough grounding in the real world.

Post by Greg A. Woods
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.

That would probably be a flawed assumption. Having witnessed your other
contributions to this mailing list, and having briefly entered a
discussion with you myself, I shall no longer be bothering to contradict
you in public. You shouldn't take that as implicit agreement on my part
either.

--
dwmw2


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Greg A. Woods]

[ On Sunday, January 25, 2004 at 21:28:04 (+0000), David Woodhouse wrote: ]

Subject: Re: [Exim] Stopping out-of-office auto-reply mail loops
Do you _really_ assert that this is either coincidence or broken
software, rather than normal behaviour? Which of the two, in this
particular case, do you believe to be the case -- is it just a
coincidence or is something broken?

Coincidence.

You keep confusing the protocol layers. You seem to be so confused on
these matters that you're not even aware of your own confusion.

Post by Greg A. Woods
Where you respond to has absolutely nothing to do with whether or not
you avoid responding to bounces.

Theoretically true, practically false.

Literally true, in fact. Simple logic, even. If one does not respond
to a message originating from "MAILER-DAEMON", then one will not respond
to bounces. It can't get much simpler.

Having written several MUA robots in my time I can assure you that it is
most important to design one's software in such a way that it first
decides whether or not sending a response is desirable, and only then if
a response is to be sent to decide where to send it.,m

Take, for example, the example
which started this thread. If it had been configured with
'to = $sender_address' I believe it would have automatically avoided
responding to bounces.

At the moment I'd have to read too much code that I've no interest in
reading to know whether responding to $sender_address in this context in
Exim would itself create a bounce, or even what, exactly,
$sender_address expands to in this context.

If one did respond to bounces then one would most likely be sending mail
to "MAILER-DAEMON" and hopefully one's local postmaster would quickly
slap one on the wrist and that nonsense would be put to an end.

--
Greg A. Woods

[phone] VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by Greg A. Woods
[ On Sunday, January 25, 2004 at 21:28:04 (+0000), David Woodhouse wrote: ]

Post by David Woodhouse
Do you _really_ assert that this is either coincidence or broken
software, rather than normal behaviour?

Coincidence.

<...>

Post by Greg A. Woods
I've no interest in reading to know whether responding to $sender_address
in this context in Exim would itself create a bounce, or even what, exactly,
$sender_address expands to in this context.

Interesting opinions. Your right.

--
dwmw2


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Greg A. Woods]

[ On Monday, January 26, 2004 at 07:02:28 (+0000), David Woodhouse wrote: ]

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

Post by Greg A. Woods
I've no interest in reading to know whether responding to $sender_address
in this context in Exim would itself create a bounce, or even what, exactly,
$sender_address expands to in this context.

Interesting opinions. Your right.

Did I forget to typ "reading _enough_code_ to know", or did you
accidentally delete it? That's what I meant to write anyway....

--
Greg A. Woods

[phone] VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Eli]

Post by Greg A. Woods
That's about as lame an excuse for using $sender_address as I've ever
heard of.
Clearly you have a strange and twisted and broken idea about what the
word "dangerous" means in this context.
Your beliefs are your own, but that's the very definition of a "Non
sequitur" if I've ever seen one.
That's completely lame argument too. <snip> We're talking about very
common software here, not laws of physics!
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?
It's either a co-incidence, or broken software. RTFRFC again.

Greg, I am sending this to the mailing list because your mail server refuses
to accept my email.

I would like to ask that you refrain from rude and unconstructive statements
and comments against others on the list. I am sure it is your intention to
merely correct people or try to voice your opinion or view, but the way that
you come across is really quite unproductive. You cause flame wars and stir
up hatred amongst others on the list. If you feel the need to personally
attack someone because they think a certain way, or want to do something in
a fashion that contradicts your beliefs (or even rules that are set out in
RFCs or the like), please do it to that person directly, and keep it off the
list.

I, like many others I'm sure, have signed up to this list to discuss Exim
and items that relate to Exim in a constructive and benefitting way to
everyone that has subscribed to the list. There is no need or reason to
your statements which I quoted above - they could have been ommitted
completely without reducing the effect of your statements.

I wish I didn't have to come across like a list maintainer, and I cerntainly
don't have the authority to tell you what's right or wrong, but I really
don't like to have to see others get shot down and insulted when they try to
say something that doesn't agree with you - even if it is wrong on
misguided.

If you feel the need to reply to this, you could email me directly, but
please let me reply back to you directly - I'm sure you can figure out what
my mail server is and whitelist it temporarily.

Post by Greg A. Woods
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.

Better be ready to put your money where your mouth is on statements like
that. Not everyone is 100% perfect, and although I can come close to saying
so far *most* of your "guidelines" mentioned for how vacation messages
should work would be good - it's not that easy to implement *everything*
you've said so far. If it is, please show us *your* exim config lines so we
can see how you've done it.

Post by Greg A. Woods
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.

Assuming someone agrees with you based on no feedback is far from
intelligent. I can think of tons of situations where this would obviously
not be the case.


Eli.



--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Edgar Lovecraft]

..[snip]...

Post by Eli
I would like to ask that you refrain from rude and unconstructive
statements and comments against others on the list. I am sure it is
your intention to merely correct people or try to voice your opinion or
view, but the way that you come across is really quite unproductive.
You cause flame wars and stir up hatred amongst others on the list. If
you feel the need to personally attack someone because they think a
certain way, or want to do something in a fashion that contradicts your
beliefs (or even rules that are set out in RFCs or the like), please do
it to that person directly, and keep it off the list.

Greg 'may' come off as being rude at times, but go back throught the
history of his posts on matters that concern ?proper? RFC SMTP mail
implementation and you will see that his arguments and points are very well
presented and NOT offenseive or rude, but then again, how many times so you
have to explain something to someone before they start thinking that you
are bieng rude.

Post by Eli
I, like many others I'm sure, have signed up to this list to discuss
Exim and items that relate to Exim in a constructive and benefitting way
to everyone that has subscribed to the list. There is no need or reason
to your statements which I quoted above - they could have been ommitted
completely without reducing the effect of your statements.

How have his statements not been related to Exim?? Exim is an MTA and that
is what is being discussed...

Post by Eli
I wish I didn't have to come across like a list maintainer, and I
cerntainly don't have the authority to tell you what's right or wrong,

Then don't...
..[snip]...

Post by Eli
*everything* you've said so far. If it is, please show us *your* exim
config lines so we can see how you've done it.

..[snip]...

Post by Eli
Eli.

--
and just for the record, here is what i use in Exim 4.xx for
autoreply/vacation message delivery and I have not ever had a problem in
3+ years.
(Please note that this is in a completely virtual user environment)
##Router##
uservacation:
driver = redirect
allow_filter
hide_child_in_errmsg
ignore_eacces
ignore_enotdir
reply_transport = vacation_reply
no_verify
require_files = <location_to_user_spool_directory>/.vacation.msg
file = <location_to_user_spool_directory>/.vacation.msg
user = exim
group = exim
unseen
##Transport##
vacation_reply:
driver = autoreply

--Sample Vacation.msg File--
# Exim filter
if ($h_subject: does not contain "SPAM?" and personal) then
mail
##### This is the only thing that a user can set when they #####
##### decide to enable vacation messaging. The vacation.msg.txt #####
expand file <location_to_user_spool_directory>/.vacation.msg.txt
once <location_to_user_spool_directory>/.vacation.db
log <location_to_user_spool_directory>/.vacation.log
once_repeat 7d
to $reply_address
from $local_part\@$domain
subject "This is an autoreply...[Re: $h_subject:]"
endif
--End Sample Vacation.msg File--

..From the Exim Manual...
http://www.exim.org/exim-html-4.30/doc/html/spec.html
..
The autoreply transport is not a true transport in that it does not cause
the message to be transmitted. Instead, it generates another mail message.
It is usually run as the result of mail filtering, a "vacation" message
being the standard example. However, it can also be run directly from a
router like any other transport. To reduce the possibility of message
cascades, messages created by the autoreply transport always have empty
envelope sender addresses, like bounce messages.
..and...
If the autoreply transport receives return code 2 from Exim when it submits
the message, indicating that there were no recipients, it does not treat
this as an error. This means that autoreplies sent to $sender_address when
this is empty (because the incoming message is a bounce message) do not
cause problems. They are just discarded.

--EAL--



--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Nigel Metheringham]

Post by David Woodhouse
If it's just like a human assistant then I agree -- since a human
assistant won't repeatedly reply to the same or similar
and all night without smelling a rat.

There are some helpdesk people I need to introduce to you....

Nigel.
--
[ Nigel Metheringham ***@InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by Nigel Metheringham

Post by David Woodhouse
If it's just like a human assistant then I agree -- since a human
assistant won't repeatedly reply to the same or similar
and all night without smelling a rat.

There are some helpdesk people I need to introduce to you....

I did specify 'human'. And then I believe I did even go on to qualify
that further with 'clueful'.

Besides, isn't there something in the Geneva Convention which says that
me and my baseball bat aren't allowed to be introduced to those people?

--
dwmw2



--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Tony Finch]

This argument is covered by draft-moore-auto-email-response-04 which
should be published as an RFC soon. It says:

4. Where to send automatic responses (and where not to send them)

In general, automatic responses SHOULD be sent to the Return-Path field
if generated after delivery. If the response is generated prior to
delivery, the response SHOULD be sent to the reverse-path from the SMTP
MAIL FROM command, or (in a non-SMTP system) to the envelope return
address which serves as the destination for nondelivery reports.

[...]

The Reply-To field SHOULD NOT be used as the destination for automatic
responses from Personal or Group Responders.

Tony.
--
f.a.n.finch <***@dotat.at> http://dotat.at/
SHETLAND ISLES: SOUTHWEST 4 OR 5, VEERS WEST OVERNIGHT, THEN NORTH TO
NORTHWEST 3 OR 4, INCREASES 5 IN NORTH LATER. SHOWERS. GOOD. ROUGH, LOCALLY
VERY ROUGH IN NORTHWEST AT FIRST.

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by Tony Finch
This argument is covered by draft-moore-auto-email-response-04 which

Hmmm. Thanks for that reference. It was about time something like that
was published -- there's clearly a _lot_ of broken autoresponders out
there, and a lot of people really don't seem to understand the problem.

One thing that concerns me is §3.3...

Since in most cases it is not appropriate to respond to an
automatic response, and the responder is not interested in delivery
status messages, a MAIL FROM address of <> MAY be used for this
purpose.

That really should have been a MUST, in my opinion. Although I admit I
expected it to have been beaten down by users of broken MTAs such as
Lotus Notes to a SHOULD. I'm amazed it's only a 'MAY' though... is there
a reason for that?

It's a little inconsistent that it's RECOMMENDED to use NOTIFY=NEVER,
which translates when sending to non-DSN-aware servers as MAIL FROM:<>
but it's not even RECOMMENDED to just use MAIL FROM:<> in the first
place.

--
dwmw2


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Greg A. Woods]

[ On Sunday, January 25, 2004 at 15:24:22 (+0000), Tony Finch wrote: ]

Subject: Re: [Exim] Stopping out-of-office auto-reply mail loops
This argument is covered by draft-moore-auto-email-response-04 which
4. Where to send automatic responses (and where not to send them)
In general, automatic responses SHOULD be sent to the Return-Path field
if generated after delivery.

Moore is one of the guys responsible for the borked sendmail "vacation".

Of course he's write a draft making such bogus claims. He's no more
correct now than he was way back then.

--
Greg A. Woods

[phone] VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Jan Johansson]

Post by Andrew Lewis
I believe I can rate-limit these messages, which could be good,

What you _should_ do is to set it up so it only sends ONE message per
X-days back to a recipient (options are available for this). A system
which replies to EVERY mail will piss a lot of people off fast
(especially on mailing lists)


###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft
Exchange.


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Greg A. Woods]

[ On , January 23, 2004 at 08:06:45 (+0200), Andrew Lewis wrote: ]

Subject: [Exim] Stopping out-of-office auto-reply mail loops
Currently I am experiencing problems where-in one user will set their
out-of-office auto-reply on, and then mail another user who's auto-reply
is on, causing an infinite mail-loop.

Perhaps you can at least point out the problem and its solutions to the
author/vendor of the software your users are misusing.

Here are some basic rules for automated e-mail agents such as vacation
autoresponders:

No response should _ever_ be sent to the list posting address.

No response should ever be sent unless the recipient's mailbox is part
of either the ``To:'' or ``Cc:'' headers of the mail. This will almost
always prevent your e-mail autoresponder from replying directly to a
mailing list injection/posting address even if non of the other
remaining mechanisms prevent a reply.

No response should be sent to messages from ``-OUTGOING'', ``-RELAY'',
``LISTSERV'', ``-REQUEST'', ``MAILER'', or ``MAILER-DAEMON'' (where
these strings are case insensitive suffixes of the base mailbox name for
the sender or originator address, and should match any and all domains).

No response should ever be sent to the same address within some decent
length of time, such as seven full days. This will prevent mailer loops
from becoming denial of service attacks and will also help prevent
annoying human readers who don't need instantaneous reminders of your
status every few moments.

Finally, and most importantly, no reply should ever be sent if a
``Precedence:'' header is found that contains the value ``bulk'',
``list'', or ``junk''!


--
Greg A. Woods

[phone] VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Eli]

Post by Greg A. Woods
No response should be sent to messages from ``-OUTGOING'', ``-RELAY'',
``LISTSERV'', ``-REQUEST'', ``MAILER'', or ``MAILER-DAEMON''

Where are these all typically seen? I obviously know about mailer-daemon,
but I've never seen the others in email addresses? Just wondering why these
shouldn't have autoreplies sent to them, since I'm just doing up an auto
reply router/transport myself.

What about postmaster? I thought about possibly blocking that, but then I
thought that postmaster should be a real person, and sending a vacation
message to them may help let them know if someone can't get to an issue
right away.

Eli.

-----Original Message-----
From: exim-users-***@exim.org [mailto:exim-users-***@exim.org] On Behalf
Of Greg A. Woods
Sent: Friday, January 23, 2004 2:10 PM
To: Andrew Lewis
Cc: Exim User's Mailing List
Subject: Re: [Exim] Stopping out-of-office auto-reply mail loops


[ On , January 23, 2004 at 08:06:45 (+0200), Andrew Lewis wrote: ]

Post by Greg A. Woods
Subject: [Exim] Stopping out-of-office auto-reply mail loops
Currently I am experiencing problems where-in one user will set their
out-of-office auto-reply on, and then mail another user who's auto-reply
is on, causing an infinite mail-loop.

Perhaps you can at least point out the problem and its solutions to the
author/vendor of the software your users are misusing.

Here are some basic rules for automated e-mail agents such as vacation
autoresponders:

No response should _ever_ be sent to the list posting address.

No response should ever be sent unless the recipient's mailbox is part
of either the ``To:'' or ``Cc:'' headers of the mail. This will almost
always prevent your e-mail autoresponder from replying directly to a
mailing list injection/posting address even if non of the other
remaining mechanisms prevent a reply.

No response should be sent to messages from ``-OUTGOING'', ``-RELAY'',
``LISTSERV'', ``-REQUEST'', ``MAILER'', or ``MAILER-DAEMON'' (where
these strings are case insensitive suffixes of the base mailbox name for
the sender or originator address, and should match any and all domains).

No response should ever be sent to the same address within some decent
length of time, such as seven full days. This will prevent mailer loops
from becoming denial of service attacks and will also help prevent
annoying human readers who don't need instantaneous reminders of your
status every few moments.

Finally, and most importantly, no reply should ever be sent if a
``Precedence:'' header is found that contains the value ``bulk'',
``list'', or ``junk''!


--
Greg A. Woods

[phone] VE3TCP RoboHack
<***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird
<***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim
details at http://www.exim.org/ ##



--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Greg A. Woods]

[ On Friday, January 23, 2004 at 16:03:50 (-0500), Eli wrote: ]

Subject: RE: [Exim] Stopping out-of-office auto-reply mail loops
Where are these all typically seen? I obviously know about mailer-daemon,
but I've never seen the others in email addresses? Just wondering why these
shouldn't have autoreplies sent to them, since I'm just doing up an auto
reply router/transport myself.

Post by Greg A. Woods
No response should be sent to messages from ``-OUTGOING'',

typical of several 0lder mailing lists, IIRC

``-RELAY'',

I can't remember where that one comes from. :-)

Post by Greg A. Woods
``LISTSERV'',

the mailbox used by several mailing list management software packages

I guess I should add "MAJORDOMO" (and maybe "MAILMAN"?) to this list! :-)

``-REQUEST'',

typically used for auto-responders for many mailing lists

``MAILER'', or ``MAILER-DAEMON''

typically what the empty envelope sender address ("<>") expands to for
presentation in in an RFC-822 header.

What about postmaster? I thought about possibly blocking that, but then I
thought that postmaster should be a real person, and sending a vacation
message to them may help let them know if someone can't get to an issue
right away.

exactly. :-)

The idea with avoiding the above is to avoid needless interactions with
the most common autoresponders.

(remember the 7-day delay between sending another reply is what actualy
prevents any mail loops from having any serious impact)

--
Greg A. Woods

[phone] VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Eli]

Ah, thank you. I have been thinking quite a bit about this
vacation/auto-reply stuff for a while now and still can't seem to fully make
up my mind about where it should be sent to.

Some say the From: or Reply-To: headers (which can make sense), but then I
think about these possibly being faked, or if someone is spammed (not high
enough to be discarded/dropped) and has a vacation message on, using these
fields could result in a bunch of emails sent out to faked addresses.

Others say the envelope sender, which makes sense too - possilby more than
others. If emails were sent to this, (I believe it's $return_path I'm
referring to, not the $sender_address or whatever) it would avoid sending to
bouncebacks (empty address, so it's discarded) automatically, and if a list
send a message, although annoying, only one message would get sent to the
list, thus everyone would know and you wouldn't send duplicates (rather than
just a message to every individual user). It could also avoid the high
volume possibly created by spam (although I have no idea how spam software
works, so I don't know if it would use different envelope senders).

Currently I'm thinking of using the $return_path variable, mainly because
it's a lot easier, and somewhat safer than using $header_from: (or at least
making some kind of long winded ${if ...} test based on from: and reply-to:
headers like a MUA should pick from).

However (possibly a new thread for this), I now come up with a new dilema -
the built in "once" stuff can't interface with MySQL, thus I have to try and
hack one in using conditions, but then... I've already got the biggest
condition line ever for my router since I check for null senders, the
precedence: header setting, and a MySQL query to see if the user has a
vacation message set and active. All this has to be in just *one* condition
statement because you can't have multiple condition statements in a router
like you can ACLs (which sucks I think!). Also, there's no other useless
command I could use to stick in other MySQL tests and such, so there's
apparently no way I can emulate the once feature using MySQL :(

So for those that do have vacation/auto-reply setups for virtual domain user
type setups using mostly SQL back ends, what sort of router/transport
entries do you have for this type of situation?

Eli.

(BTW, sorry for my top posts - Outlook's only good message format is top
posting :()

-----Original Message-----
From: exim-users-***@exim.org [mailto:exim-users-***@exim.org] On Behalf
Of Greg A. Woods
Sent: Saturday, January 24, 2004 12:22 AM
To: eli-***@experthost.com
Cc: Exim User's Mailing List
Subject: RE: [Exim] Stopping out-of-office auto-reply mail loops

[ On Friday, January 23, 2004 at 16:03:50 (-0500), Eli wrote: ]

Subject: RE: [Exim] Stopping out-of-office auto-reply mail loops
Where are these all typically seen? I obviously know about mailer-daemon,
but I've never seen the others in email addresses? Just wondering why these
shouldn't have autoreplies sent to them, since I'm just doing up an auto
reply router/transport myself.

Post by Greg A. Woods
No response should be sent to messages from ``-OUTGOING'',

typical of several 0lder mailing lists, IIRC

``-RELAY'',

I can't remember where that one comes from. :-)

Post by Greg A. Woods
``LISTSERV'',

the mailbox used by several mailing list management software packages

I guess I should add "MAJORDOMO" (and maybe "MAILMAN"?) to this list! :-)

``-REQUEST'',

typically used for auto-responders for many mailing lists

``MAILER'', or ``MAILER-DAEMON''

typically what the empty envelope sender address ("<>") expands to for
presentation in in an RFC-822 header.

What about postmaster? I thought about possibly blocking that, but then I
thought that postmaster should be a real person, and sending a vacation
message to them may help let them know if someone can't get to an issue
right away.

exactly. :-)

The idea with avoiding the above is to avoid needless interactions with
the most common autoresponders.

(remember the 7-day delay between sending another reply is what actualy
prevents any mail loops from having any serious impact)

--
Greg A. Woods

[phone] VE3TCP RoboHack
<***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird
<***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim
details at http://www.exim.org/ ##




--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[David Woodhouse]

Post by Eli
Others say the envelope sender, which makes sense too - possilby more than
others. If emails were sent to this, (I believe it's $return_path I'm
referring to, not the $sender_address or whatever) it would avoid sending to
bouncebacks (empty address, so it's discarded) automatically, and if a list
send a message, although annoying, only one message would get sent to the
list,

Lists never send messages. You'll never receive genuine mail with an
SMTP reverse-path of <exim-***@exim.org>, and as such, the list can be
set up to refuse to accept bounces.

If you were to autoreply to a list message, that goes back to
exim-users-***@exim.org, which is the list software -- not to the
list. The list software will probably just keep count of how many times
you do this and unsubscribe you if you do it too much. A much less
problematic failure mode than some of the other possibilities.

--
dwmw2



--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Wakko Warner]

Post by Eli
Ah, thank you. I have been thinking quite a bit about this
vacation/auto-reply stuff for a while now and still can't seem to fully make
up my mind about where it should be sent to.

How about just forwarding the user's email to someone else while they're on
vacation?

Post by Eli
Some say the From: or Reply-To: headers (which can make sense), but then I
think about these possibly being faked, or if someone is spammed (not high
enough to be discarded/dropped) and has a vacation message on, using these
fields could result in a bunch of emails sent out to faked addresses.
Others say the envelope sender, which makes sense too - possilby more than
others. If emails were sent to this, (I believe it's $return_path I'm
referring to, not the $sender_address or whatever) it would avoid sending to
bouncebacks (empty address, so it's discarded) automatically, and if a list
send a message, although annoying, only one message would get sent to the
list, thus everyone would know and you wouldn't send duplicates (rather than
just a message to every individual user). It could also avoid the high
volume possibly created by spam (although I have no idea how spam software
works, so I don't know if it would use different envelope senders).
Currently I'm thinking of using the $return_path variable, mainly because
it's a lot easier, and somewhat safer than using $header_from: (or at least
headers like a MUA should pick from).

This may help a little. If the recipient's email address is not listed as
the To: or CC: lines, don't send autoreplies. That would virtually remove
all mailing lists from auto replies and lots of spam. Granted not all spam
would be stopped that way. It (if there's no virus checking) would prevent
replies to virii.

Post by Eli
(BTW, sorry for my top posts - Outlook's only good message format is top
posting :()

IIRC, pine will work on windows. Or mozilla. Don't use outlook, it has
enough bugs as it is.

--
Lab tests show that use of micro$oft causes cancer in lab animals

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Greg A. Woods]

[ On Sunday, January 25, 2004 at 02:42:44 (-0500), Eli wrote: ]

Subject: RE: [Exim] Stopping out-of-office auto-reply mail loops
Some say the From: or Reply-To: headers (which can make sense), but then I
think about these possibly being faked, or if someone is spammed (not high
enough to be discarded/dropped) and has a vacation message on, using these
fields could result in a bunch of emails sent out to faked addresses.

There's a _lot_ more danger in trusting the SMTP envelope sender
address -- which is one of the reasons it must be used only by the MTA
for non-delivery notifications.

If you worry about the RFC [2]822 headers being faked then you've either
lost the game before you even start to play or else you need to learn to
use mechanisms that allow you to authenticate all message content.

In any case a proper mail agent autoresponder won't blindly trust the
originator address either -- it will refrain from sending more than one
response per week (or whatever) to any given address thus preventing any
third party from abusing it or tricking it into creating harmful mail
loops.

Currently I'm thinking of using the $return_path variable, mainly because
it's a lot easier, and somewhat safer than using $header_from: (or at least
headers like a MUA should pick from).

Much better would be to use an external agent program that was designed
to handle all of these issues instead of trying to over-load the purpose
of your MTA program. :-)

(BTW, sorry for my top posts - Outlook's only good message format is top
posting :()

Surely you can manually delete the original?

If not then that's yet another very good reason to _never_ use M$ crapware.

--
Greg A. Woods

[phone] VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##

[Michelle Konzack]

Post by Andrew Lewis
Hello,
Currently I am experiencing problems where-in one user will set their
out-of-office auto-reply on, and then mail another user who's auto-reply
is on, causing an infinite mail-loop.

First, an autoresponder should never respond to Mails with
"Precedence: bulk" or "Precedence: list". E-Mails of this
kind I get every day...

If you send Autoresponder, use for "From: " the same E-Mail
as for "To: " ;-)

This Message will never come Back to you !

... and on the Receiver-Side it depends on the Autoresponder-
Config ;-)

YES, -I have seen Windows-MUA's which have tilled them Self.
It was around one week to fill up a 160 GByte Harddisk.

;-)

Greetings
Michelle

--
Registered Linux-User #280138 with the Linux Counter, http://counter.li.org/

--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##