On Thu, 28 Feb 2002, Greg A. Woods wrote:
> [ 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).
Ah, but if you buddy _forwarded_ you the message, there wont be any
Recent-* headers.
Its only if the caused it to be redelivered to you, keeping the existing
To: and From: headers intact, (Pine calls this "B"ounce), that those
headers would be in place.
And the purpose of doing this is if the mail was supposed to have gone
to you in the first place, and it was just addresses by the sender
incorrectly.
Regardless of this, only messages initiated by direct human action
should be sent to any header address - any addresses sent 'autonomously'
under program control should always use the envelope address.
And yes Greg, I know you disagree with this. And regardless of the fact
that I agree with most of your other positions, you are wrong on this.
Automation should NEVER use the headers for any response. If you have
to, think of it this way - a program running non-interactively handling
mail IS acting as an MTA, not an MUA.. An MUA only sends mail when
interactively commanded to. Anything sending mail automatically is NOT
an MUA. (Even if it is part of a package that otherwise functions as an
MUA)
Think of it this way - lets say a company wanted to automatically mail
out (I talking postal mail here) an acknowledgement to everone that sent
them a mail. Lets say this cmpany has thousands of employees. Lets say
all incoming letters are placed in a machine that automatically prints
out the acknowledgements. This machine would (and SHOULD) scan the
return address on the _envelope_, without opening the envelope itself.
>
> 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@???>
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
>
--
