Sorry for the length... I know few people read my messages anyway, being
the thread killer that I am. ;)
On Thu, 2004-12-02 at 09:20, David Woodhouse wrote:
On Thu, 2004-12-02 at 14:21 +0000, Chris Haynes wrote:
I wonder: Do those forwarders who re-use the same mail-from address use
this 251
response?
No, almost nobody ever uses it. It doesn't really make much sense for
the reasons you state.
Well, then this is an odd-predicament the receiver/forwarder gets
himself into if there is even the slightest chance there would be a DSN
sent. Chris Haynes's reasons were:
1) Confidential and/or,
2) Subject to frequent change (Someone on this list reported
that he forwards to his client-of-the-week's site)
If a DSN is sent, then that breaks the confidentiality of the
forwarding. This seems like a risk that those who are actually
concerned about confidentiality of their email path wouldn't want to
take.
If forwarding is frequently changing then why would the sender care
about that or even want to know? The whole point of doing forwarding in
that case is so that senders DO NOT need to know about the latest
forwarding setup.
This whole "who is responsible for forwarded messages" issue is getting
quite silly. It is outlined right in RFC2821.
From RFC 2821, section 4.2.5:
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
When an SMTP server returns a positive completion status (2yz
code) after the DATA command is completed with <CRLF>.<CRLF>, it
accepts responsibility for:
- delivering the message (if the recipient mailbox exists), or
- if attempts to deliver the message fail due to transient
conditions, retrying delivery some reasonable number of times at
intervals as specified in section 4.5.4.
- if attempts to deliver the message fail due to permanent
conditions, or if repeated attempts to deliver the message fail
due to transient conditions, returning appropriate notification
to the sender of the original message (using the address in the
SMTP Forwarding support is most often required to consolidate
and simplify addresses within, or relative to, some enterprise
and less frequently to establish addresses to link a person's
prior address with current one. Silent forwarding of messages
(without server notification to the sender), for security or
non-disclosure purposes, is common in the contemporary Internet.
MAIL command).
When an SMTP server returns a permanent error status (5yz) code
after the DATA command is completed with <CRLF>.<CRLF>, it MUST
NOT make any subsequent attempt to deliver that message. The
SMTP client retains responsibility for delivery of that message
and may either return it to the user or requeue it for a
subsequent attempt (see section 4.5.4.1).
Exactly how strong is the "[server] accepts responsibility for" and
"client retains responsibility for" above? This seems to create well
defined points of responsibility transfer: if the server gives a
positive completion status, the server is assuming responsibility.
Section 3.10, "Mailing Lists and Aliases" is ambiguous as to what
constitutes a "mailing list" and "alias" (something that RFC821 points
out in section 3.3, some of the text of which is copied into RFC2821
section 3.5.1). One could say that "aliases" were intended to mean
changing one LHS for another, but the domain stays the same. It might
not be accurate to cite 3.3 as the definition of a responsibility
boundary, as there is also this paragraph in section 3.4, "Forwarding
for Address Correction or Updating", that seems to set the tone for the
RFC:
Forwarding support is most often required to consolidate and
simplify addresses within, or relative to, some enterprise and
less frequently to establish addresses to link a person's prior
address with current one. Silent forwarding of messages
(without server notification to the sender), for security or
non-disclosure purposes, is common in the contemporary Internet.
"often required to ... simplify ... within some enterprise" and "less
frequently to establish to establish addresses to link a person's prior
address with current one". This would appear to mean that RFC2821 was
written with a focus on the "enterprise" (a single, non-overlapping
sphere of influence) and thus colors the rest of the RFC in that light.
As such, mentions of "forwarding" and "relaying" could be taken to mean
within the enterprise's domain of control, not including the Internet at
large.
The case of silent forwarding seems to imply taking responsibility for
the forwarding, since the sender can not authorize a change of
responsibility. If a sender has any issues, they should go to the place
they sent the message, not some third party they are not aware of.
Section 2.3.10 "Mailbox and Address":
[D]ue to a long history of problems when intermediate hosts have
attempted to optimize transport by modifying them, the
local-part MUST be interpreted and assigned semantics only by
the host specified in the domain part of the address.
One might say that a host that performs forwarding is attempting to
"optimize" transport by re-injecting the mail into the Internet at large
by using the MAIL FROM it received for the message. This would be an
"optimization" because DSNs would not go back through the forwarding
host. By performing this "optimization", the forwarding host is taking
responsibility for the message. There is no way the forwarding host can
avoid taking responsibility for the message, or skirt that
responsibility by either considering itself an intermediate host and
"optimizing" or by not doing this and using it's own MAIL FROM.
There are some interesting things said in Appendix C of RFC 2821,
specifically paragraphs 2 and 6, if source routing was resurrected
(which may be relatively easier to do than getting a completely new
system deployed, but we've already talked about that months ago):
For relay purposes, the forward-path may be a source route of
the form "@ONE,@TWO:JOE(_at_)THREE", where ONE, TWO, and THREE MUST
BE fully-qualified domain names. This form is used to emphasize
the distinction between an address and a route. The mailbox is
an absolute address, and the route is information about how to
get there. The two concepts should not be confused.
...
When the list of hosts is present, it is a "reverse" source
route and indicates that the mail was relayed through each host
on the list (the first host in the list was the most recent
relay). This list is used as a source route to return
non-delivery notices to the sender. As each relay host adds
itself to the beginning of the list, it MUST use its name as
known in the transport environment to which it is relaying the
mail rather than that of the transport environment from which
the mail came (if they are different).
In order to make this usable, it could be required that when handling
reverse source routes for forwarding failures the HELO domain must pass
SPF and the DSN must have a null <> MAIL FROM and a null <> RCPT TO,
except for the last one, which would be, per the example, JOE(_at_)THREE(_dot_)
This would be the way to designate this is a DSN that needs to forwarded
via reverse source route.
It may be reasonable to insist that hosts that forward keep a log of
MAIL FROM and RCPT TO pairs and reject if it never forwarded a message
matching that -- MTAs already keep message queues with limits specified
in section 4.5.4, so this is not that big of an addition. Define a
forwarding limit, say 5, and these values only need to be kept around
for the limits specified in 4.5.4 * that forwarding limit. The DSN
should only be accepted if the host can verify it forwarded a message
through the client, otherwise immediately reject. Yes, this is similar
to issues that SRS originally had (before attempting to stuff everything
in the LHS), but overall a small addition for hosts that do not do a lot
of forwarding. Those that do do a lot of forwarding, storing long lived
forwarding data is part of the business of doing forwarding. A number
of solutions have already been proposed for storing this kind of data
for SRS in distributed environments that could be reapplied here.
Reverse source routing has been mentioned a number of times before
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200405/0349.html
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200405/0465.html
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200405/0491.html
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200406/0324.html
at the very least.
Why did we stop exploring reverse source routing as a "solution" to
forwarding?
Andy.