Dave Kitabjian <[EMAIL PROTECTED]> schrieb/wrote:
> When connecting to the SMTP server to send the message, the "From" and
> "To" fields are copied by the MUA to become the "From:" and "To:"
> headers of the message.
The "fields" are the "headers" -- the term used in email is "header
fields" for a "single header" and "header" for the complete list of
header fields.
Besides these header fields, there is an envelope, consisting of an
envelope sender (aka return path) and one or more envelope recipients.
The envelope is completly separate from the header fields and can
contain different addresses.
With SMTP, the envelope is transmitted with the MAIL FROM and RCPT TO
commands. With UUCP, it's the argument to rmail and "From " lines added
to the start of a messages[1]. QMTP uses a binary format.
For message delivery and bouncing, only the envelope is used.
When a user agent hands over a message to the message transfer agent
(injects it), it must already have prepared the envelope and the message
(which consists of headers and body). From that point, there's no
relation between envelope and message header.
User agents usually ask the user to give information for the header
fields and prepare the envelope out of that information, but that is not
necessarily true. BTW, qmail-inject is more or less part of the user
agent -- or can be used directly by users.[2]
> The "From" field is also used in the SMTP conversation as the "MAIL
> FROM:".
Not necessarily, see above.
> Then, all addresses in the "To",
> ("Cc",) and "Bcc" fields are used as SMTP "RCPT TO:" entries.
Not necessarily, see above.
> -> Question: Are "Bcc" recipients not stored anywhere in the headers, or
> are they stored in the headers until the message is ready to be
> delivered into the recipients box, and then stripped off?
Depending on the user agent, the Bcc recipients might be stored in the
header until the user agent prepares the message for submission. At this
moment, it creates the envelope and (hopefully) strips out the Bcc
header.
Note that the other possibility would be very stupid as noone can
guarantee that it will be stripped out by a non-trusted receiving
message delivery agent.
> (If they are NOT stored in the headers, where does qmail store them?)
As in any other MTA that deserves that name, the envelope addresses are
stored separatly.
> The "Reply-To" header is created by the MUA from either the "Reply
> Address" field, if present, or else the "From" field.
No. The "Reply Address" field is more or less the Reply-To header. If
you don't give one, there simply is no Reply-To header field either.
> The "Return-Path:" header is added by the SMTP server based on the
> "Reply-To" or "From" header (?)
No. The Return-Path header is added by _some_ agents that finally store
a message in a mailbox/maildir (delivery agents) It is a copy from the
envelope sender, which would otherwise be lost at this moment.
Also, _some_ delivery agents write a Delivered-To header to save the
very envelope recipient address used for this copy of the message. It
would otherwise be lost too.
> -> Question: So, now what do we look at to determine the "envelope
> sender" and "envelope recipient"?
At the envelope, which is stored separatly from the message headers and
body.
> Secondly, which of these terms/headers
> is used to determine whom qmail delivers the message to?
qmail sends the message to the envelope recipients of course. No sane
message transfer agent would look at the headers.
> Okay, now the message bounces because because it's an evil spam message.
>
> -> Question: Where does MAILER-DAEMON send the bounce message? To the
> "From:" person? "Reply-To:"?
To the envelope sender of course (as said above). And not that bounce
message have a envelope sender address of <> (ie empty), not <MAILER-
DAEMON@host>, which is only the From header.
___________
[1] Which is quite different from the "From:" header field.
[2] Although it comes with qmail, it does part of the UA's job of
preparing a message. You could also see it as the interface between the
UA and the MTA.
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
