This is clearly off the topic of Sender's Declaration of Identity. Please
change the subject when you go off topic. It will help if we ever need to
go back and review a discussion. Thanks.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *
At 07:54 AM 5/17/2005 -0400, Bruce Lilly wrote:
On Mon May 16 2005 23:00, John P Baker wrote:
> First, let us consider a local mail server receiving mail from a directly
> connected remote client
Which is it -- "directly connected" or "remote"? What is the significance?
> to whom is allocated a mailbox address
"Mailbox" or "address" ((at least) two different things -- see RFC 2822)?
> on the
> server.
One use of "mailbox" -- a mailbox receives mail -- makes little sense:
o you speak of "allocated" and "client", but a mailbox has no relationship
to any specific instance of "client" (MTA, MUA, or IP address) and need
not have a one-to-one relationship with any person.
o in the scenario posited, where the sender is associated with the mailbox
for receipt of the message, the sender is sending mail to himself, which
is at best an edge case of little general interest or utility.
The other use of mailbox -- name-addr / addr-spec -- makes zero sense in
the scenario.
One use of "address" -- as in IP address -- has no relationship to either
meaning of "mailbox". Another use of "address" -- mailbox / group --
relates the syntax of message header "address" (a third use, categorizing
a set of message header fields) field components and has no involvement in
mail transport.
> In this scenario, I will argue that when the mail origination
> authentication extension is enabled, the local mail server should verify
> that the "From:" mail address specified in the message header
NO! The message header is end-to-end, user-to-user communication.
Delivery transport uses SMTP command RCPT TO arguments. Transport
agents (other than gateways) are forbidden from poking around in the
users' private communications -- see RFC 2821.
[...]
> Second, let us consider a local mail server receiving mail from a connected
> remote mail server. In this scenario, I will argue that when the mail
> origination authentication extension is enabled, the local mail server
> should be required to maintain a resident list of "trusted" remote mail
> servers (i.e., remote mail servers who stipulate that they require that all
> mail message traffic must comply with the requirements of the mail
> origination authentication extension), and no SMTP session establishment to
> a "non-trusted" remote mail server should be permitted.
[...]
One of the fundamental rules of email is that no prior arrangement is
required between sender and recipient. You seem to have completely
missed that fundamental rule.