From: Frank Ellermann
Sent: Sunday, June 06, 2004 1:37 AM
Seth Goodman wrote:
this protocol is fairly easy to implement in MTA's
Sure, but why do you want to send bounces to innocent
bystanders as shown in your step 6 ? Why not use the
verified domain (step 4) ? You say, that the old 821
routing syntax is still accepted but ignored everywhere.
Therefore you're free to use it with a new meaning.
If that's the case, you could also use the original
MUST in RfC 2821, i.e. send bounces to the forwarder:
| If they do utilize the source route, the message MUST
| be sent to the first domain shown in the address. In
| particular, a server MUST NOT guess at shortcuts within
| the source route.
But your assumption is that (almost) all mailers today
use the MAY, i.e. ignore source routes. Therefore your
idea unfortunately doesn't work, the bounces go to the
wrong party. SRS solves this problem. Bye, Frank
This snippet of 2821 is easily misconstrued out of context. It deals with
forward source routes and does not apply to reverse source routes or DSN's.
Read in its full context, this section (F.2) gives a forwarder who receives
a message for a recipient address in forward source route format two choices
as to how to send the message. They may send it to the target recipient or
the first address in the source route list, but not to any addresses in the
middle of the source route list.
Here is the section that that applies to reverse source routes and DSN's:
|6.1 Reliable Delivery and Replies by Email
|
| When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
| message in response to DATA), it is accepting responsibility for
| delivering or relaying the message. It must take this responsibility
| seriously. It MUST NOT lose the message for frivolous reasons, such
| as because the host later crashes or because of a predictable
| resource shortage.
|
| If there is a delivery failure after acceptance of a message, the
| receiver-SMTP MUST formulate and mail a notification message. This
| notification MUST be sent using a null ("<>") reverse path in the
| envelope. The recipient of this notification MUST be the address
| from the envelope return path (or the Return-Path: line). However,
| if this address is null ("<>"), the receiver-SMTP MUST NOT send a
| notification. Obviously, nothing in this section can or should
| prohibit local decisions (i.e., as part of the same system
| environment as the receiver-SMTP) to log or otherwise transmit
| information about null address events locally if that is desired. If
| the address is an explicit source route, it MUST be stripped down to
| its final hop.
|
| For example, suppose that an error notification must be sent for a
| message that arrived with:
|
| MAIL FROM:<@a,@b:user(_at_)d>
|
| The notification message MUST be sent using:
|
| RCPT TO:<user(_at_)d>
|
This seems pretty clear that you cannot send the DSN to "@a". Even if it
was permitted, who would you send it to at that domain? If the innocent
target of the forged bounce implements SES, they will reject the forgery
before DATA. If they don't implement SES, they are no worse off than they
are today. It is definitely in their interest to implement SES, and I hope
most domains will elect to do so.
When you mention that SRS solves this problem, it only does so if _all_
forwarders implement SRS. Until that happens, and from a practical
standpoint, it is extremely unlikely that everyone will implement anything,
you still have to whitelist some forwarders and you will receive forged
bounce spam through those channels. You are also forgetting the response to
Meng's question about dropping SRS. There was an immediate, resounding
affirmative response. The comments made it clear that most people
considered SRS as overly complicated, too different from existing practice
and a hindrance to adoption.
I argue that the SES+SUBMITTER (or better yet, SES+reverse source route) is
an equivalent solution that is much simpler, is interoperable with legacy
systems and doesn't require the whole world to cooperate.
--
Seth Goodman