Re: Philosophical discussions
Frank Ellermann <[email protected]> Wed, 08 Jun 2005 03:18:16 +0200
| Newsgroups | gmane.ietf.mxcomp |
|---|---|
| Organization | <URL:http://purl.net/xyzzy> |
| Message-ID | <[email protected]> |
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