ietf-mxcomp
[Top] [All Lists]

Re: Philosophical discussions

2005-06-07 18:23:06

Alan DeKok wrote:

if I deliver a message to the MX that is authoritative for
the domain of the mailbox, the message is *delivered*.  It's
*done*.

"Final delivery" is something different, I'd say "sent" where
you say "delivered".

You're assuming that *my* message gets forwarded *from* the
domain I sent it to, and that it's still marked as *my*
message.

There's no problem, the MX can be a gateway to some fascinating
UUCP forwarding, or forward your mail to an MDA, with several
hops, it's all fine and still MAIL FROM you RCPT TO recipient.

If it does, I don't see why it's labelled as "my" message.

Here you're talking about a _new_ recipient with _another_ MX.

That's of course not more your responsibility, and if there is
a technical problem it's definitely not your problem.  As soon
as another MX of a third party is involved it's the problem of
the "original" recipient.  He could adjust the MAIL FROM - one
of the many ways to deal with his responsibility.

The historical approach to label it that way is nice
historically

It is _not_ the historical approach, that's only a legend of
the "bounces-to" camp.  Historically each forwarding host added
its name to the reverse path, MAIL FROM @mx3,@mx2,@mx1:you

For obvious reasons that design worked against forged addresses,
mx2 and mx1 were not interested to forward any MAIL FROM you if
they would have to deal with later bounces to you.

That's also the reason why there's a 551 "user not local" code.

When they killed the source routes in 1123 they simply "forgot"
that this is a security loophole for the 251 alias-style of
forwarding - RfC 1123 is 16 years old, nobody could foresee the
disastrous effects of this security loophole in SMTP today.

But when you said (in your LMAP memo) that some LMAP proposals
_change_ the original _semantics_ of the MAIL FROM this is NOT,
repeat NOT, repeat NOT, true.

The MAIL FROM _semantics_ is as it always was since STD 10.  And
SPF simply uses it to fix this security loophole in SMTP today,
for those who want it.

if they choose to accept that accountability, isn't that
their choice?

Of course.                 Bye, Frank