On Sat April 9 2005 14:07, Frank Ellermann wrote:
Bruce Lilly wrote:
The term "mailbox" has two uses (RFCs 822, 2822):
o As an abstract term for an entity that receives email.
Or submits it (the 3rd occurence of "mailbox" in STD 11 is
the "Sender" defined as "actual sumitter", later defined
to be the responsible "bounces-to" address. Pun intended.)
If you mean part of the EBNF or the phrase "The Sender mailbox
specification", that refers to the grammar production.
The message header Return-Path field is derived from an SMTP
command argument and is subject to the same restrictions.
Unlike an angle-addr it can be empty, not exactly the same.
Correct, the restrictions include no display name, no named groups, etc.
the Sender mailbox and the SMTP return path (for delivery
notifications) may in general be unrelated.
That's in fact the main problem of this draft, in general they
start as not only related but as identical.
Not necessarily. I might have a cron process which is the Sender
(see RFC 822 section 4.4.2 and RFC 3834), whereas I might wish
delivery notifications to go to a person, since the cron process is
unlikely to be able to handle notifications. Note also that while
the syntax in Sender field for the case of an automated process must
match the "mailbox" grammar production, there is no requirement that
mail can be received via that specification (see RFC 3834 sect. 4).
"MAIL FROM" is an entity responsible for the SMTP transmission
incl. errors, "Sender" is a human responsible for the mail or
news transmission incl. errors.
We've discussed MAIL FROM and it's origins. Sender need not
reference a human.
List expanders SHOULD set the reverse path (MAIL FROM) to
point to the list administrator, and SHOULD NOT leave MAIL
FROM unaltered.
Not necessarily the human list admin, it can be also a mail-bot
handling error messages for the admin.
It should be a mailbox (in the abstract sense) that can receive
delivery notifications, expressed in the path (a.k.a. angle-addr)
syntax required for the MAIL FROM command argument.
Another case where the
Sender and the MAIL FROM could be different (the responsible
Sender is always a human).
"[C]ould be different", yes; "always a human", no.
MAIL FROM path (angle-addr) might have to be transformed into
something comparable on the "foreign" side of the gateway,
but SHOULD NOT be changed to point to a gateway operator
mailbox except as a last resort (otherwise delivery
notifications will never reach the correct mailbox).
NAK, that depends on the nature of the gateway. If it's for a
list or newsgroup or similar cases (e.g. Fido echo) it SHOULD
point to the gateway operator, normal list etc. users are not
responsible for or interested in the problems behind a gateway.
In the specific case of a news-to-mail gateway, there is no
path to transform, since news has no corresponding "envelope". So
the "last resort" case applies. Conversely, if I send a message
to a recipient via an SMTP-to-X.400 gateway, I expect to be
notified of delivery (esp. delivery success), whereas the gateway
operator probably couldn't care less. Perhaps there is a need to
differentiate the different types of gateways; I believe that I
identified about a half-dozen types in comments on an earlier
version of the architecture draft...