[ On Saturday, January 24, 2004 at 11:34:59 (+0000), David Woodhouse wrote: ]
> Subject: Re: [Exim] Stopping out-of-office auto-reply mail loops
>
> On Fri, 2004-01-23 at 14:17 -0500, Greg A. Woods wrote:
> > [ 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.
> Consider the example from page 42 (§A.1.1) of RFC2822:
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
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
