[ On Wednesday, February 27, 2002 at 11:58:36 (-0800), Mark Morley wrote: ]
> Subject: [Exim] Proper autoresponder behavior
>
> We have some software we've developed that allows end users to filter
> and process incoming mail in all sorts of ways (you can read about it
> at www.islandnet.com/pep). One of the things it can do is generate
> automatic replies.
Been there, done that, got a project for it on FreshMeat.... :-)
> Here's what it looks for before sending a reply. Am I missing anything?
> Am I being overly cautious with any of these?
>
> - It replies to the return-path value, not reply-to or from. There seems
> to be some debate about this - comments?
There's no real debate about it -- just some confused souls apparently
suffering from some silly misconceptions they seem to have about the
differences between SMTP envelopes and message headers.
Replying to the return-path is wrong for a "mail user agent", of which
an auto-responder is almost always acting as (eg. when the auto-
responder is used to handle "out-of-the-office" types of messages,
"info" mailbox replies, and so on).
On the other hand if it is used to generate bounces (i.e. delivery
status notifications, or DSNs, on behalf of the MTA) -- then of course
it "MUST" reply _only_ to the return-path address. (Mine shouldn't be
used to generate bounces -- the MTA does that for me!)
Usually the "from:", "reply-to:", and "return-path:" are all the same
address, but not always of course, and that's why it's wrong to use the
return-path for anything but bounces (i.e. DSNs).
A mail user agent responding to a proper mailbox must reply to the
addresses given in the "reply-to:" header, or if there is no such header
then those given in the "from:" header. No more, no less, as they say.
> - It won't reply to DSN messages (sender is <>)
Note that most MTAs expand an envelope address of "<>" to
"Return-Path: MAILER-DAEMON@*", so....
> - It won't reply to addresses that match "mailer-daemon@*", "postmaster@*",
> "*-request@*", "owner-*@*", or "bounce-*@*".
You might want to add "listserv@*", "mailer@*", "*-relay@*", and
"*-outgoing@* too.... "listserv@*" is the most critical of course
(because of L-Soft's idiotic refusal to add a "precedence: list" header).
(I assume you're checking both the address in the "return-path:" header
as well as _ALL_ addresses in the "from:" header....)
(I assume you're comparing those particular mailbox patterns without
regard to case too....)
> - It won't respond to messages that have a Precedence: header containing
> "bulk", "list", or "junk".
>
> - It won't respond to any message that contains an "x-mailing-list"
> header or any "list-*" headers.
Is that really necessary? It shouldn't be....
> - It has a user-configurable response limiter so they can set it to
> send only one reply every X hours, days, weeks, etc.
You'll want to be careful how you recognise addresses you've already
replied to (ignore the comments, etc., parse out multiple addresses,
etc.) -- that's a feature coming in the almost-released version of my
program....
> - The reply message itself is sent with a "Precedence: junk" header and
> a null return-path. If the customer wants it to be replyable they can
> add a Reply-to header.
You really don't have to send it with a null return-path. It might be a
nice option to have in a full-featured auto-responder (mine has it), but
it should not be the default.
If I were a user setting up an agent to send responses to an "info"
mailbox or such then I would certainly want to know about bounces! I
probably even want to know about bounces to my "I'm out of the office"
notices....
There are more than enough other checks to make it impossible for
bounces to cause dangrous resource consuming loops -- any loops, even
those forced by a malicious act, will by definition have slower cycles
than "X hours, days, or weeks".
Note also that if the message has a "From:" header (which will likely be
added by the MTA anyway) then it can be replied to even without a
"reply-to:" header.
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
