[ On Thursday, February 28, 2002 at 00:32:47 (-0800), Mark Morley wrote: ]
> Subject: Re: [Exim] Proper autoresponder behavior
>
> RFC 2822 says "Resent fields are strictly informational. They MUST NOT be
> used in the normal processing of replies or other such automatic actions on
> messages."
Then RFC 2822 is clearly wrong. More on the reasons why below.
You should go back and read RFC 822 to understand resent-* headers if
RFC 2822 isn't saying the right things -- the latter is still only a
proposed standard, not the real thing. In any case it's quite likely
your autoresponder is doing something outside the direct scope of the
RFCs -- you need to treat it more like a real human e-mail user (though
if the above is all 2822 has to say on the subject then it's still very
wrong and is introducing incompatability between existing
implementations, something a revised standard MUST NOT do).
> So one shouldn't be replying to any address in resent-* headers (whether
> it's an autoresponder or not).
If there are resent-* headers in the message then whomever or whatever
is responding to the message must decide who the kind of response is
indended for.
When the responder is a human (or an MUA being driven by a human), this
is potentially easy -- if you're responding to comment about the
forwarded message then you're either intending your comments to be read
by the forwarder, or by the originator, or by both. A decently
implemented MUA will have shown the resent-* headers (perhaps even
highlighting them because of their importance) and then only suggested
which addresses any reply should be sent to.
However when the responder is an agent acting on behalf of a human the
response is likely to be intended to the closest person in the chain of
those involved in making the message arrive in your mailbox. This is
certainly true for an agent responding with an "out of the office" kind
of reply. In this case any resent-* headers must be preferred to derive
the address(es) the response will be sent to. In other words if your
buddy forwards you a joke then you want your agent to reply on your
behalf to tell him that you won't be able to laugh at the joke until you
return from vacation -- you probably do not want the agent to embarrass
you and to reply to the person who your buddy received the joke from
(which is why RFC-2822 really "MUST" be wrong).
The rules for deriving the reply address(es) are the same for resent-*
headers as they are for the normal headers -- use the address(es) in the
"resent-reply-to:" header, or if there is none then the one(s) in the
"resent-from:" header. Presumably you should fall back to the normal
"reply-to:" header and then the "from:" header if there's only a
"resent-to:" and/or "resent-cc:" (and maybe other "resent-*"
informational headers, such as "resent-subject:" or whatever).
It is true that many MUAs often make incorrect use of "resent-*", but
most of the mis-uses are benign from the point of view of a responder.
(given these problems it may have been best to officially deprecate
"resent-*" support and to instead suggest MIME encapsulation of RFC-2822
messages for all forwarding actions, but that does not seem to be what
has happened so far, and we still have to deal with "resent-*" anyway....)
Obviously the same rules of thumb apply as to how to classify an address
you're about to respond to, regardless of what header it came from. You
don't want to respond to MAILER-DAEMON, LISTSERV, etc., and usually you
do not want to send a response to any address you've recently replied
to, etc. :-)
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
