Hello!
On Thu, Dec 02, 2004 at 12:21:34AM +0100, Frank Ellermann wrote:
Hannah Schroeter wrote:
Where is it really defined that .forward style forwarding
w/o envelope rewriting is *not* correct (best some RFC
source)?
It's hidden in STD 10, discussed in MARID and ASRG recently:
Ok, cited from /afs/stacken.kth.se/doc/rfc/std-index.txt:
: 0010 Simple Mail Transfer Protocol. J. Postel. August 1982. (Format:
: TXT=120432 bytes) (Obsoletes RFC788, RFC780, RFC772) (Obsoleted by
^^^^^^^^^^^^
: RFC2821) (Also RFC0821, RFC1869, RFC974)
^^^^^^^
[...]
"Not correct" doesn't cover it, it's only the fact that there is a 551
error code (as an alternative to 251), and the one
sentence: "The first host in the <reverse-path> should be
the host sending this command" (i.e. MAIL FROM).
Obsolete.
RFC2821 says:
Historically, the <reverse-path> can contain more than just a
mailbox, however, contemporary systems SHOULD NOT use source routing
(see appendix C).
later:
circumstances. SMTP servers MAY decline to act as mail relays or to
accept addresses that specify source routes. When route information
is encountered, SMTP servers are also permitted to ignore the route
information and simply send to the final destination specified as the
last element in the route and SHOULD do so. There has been an
[...]
When source routes are not used, the process described in RFC 821 for
constructing a reverse-path from the forward-path is not applicable
and the reverse-path at the time of delivery will simply be the
address that appeared in the MAIL command.
So, if quite a few MTAs *do* decline to work with source routes (see
"MAY"), we'd break things if we were to re-use source routes for
something else (e.g. to rewrite the 2821 sender at forwarding sites to
<@forwarder:original(_at_)sender>).
Then things like SRS would be a *much* lesser evil in my eyes (it only
has length problems and one might find it inefficient to force DSNs
through more relays than would be needed if they could be sent directly,
as e.g. with SES).
Why should SPF impose effort on non-SPF sites instead of
do the effort themselves
It doesn't. If the receiver does not like SPF all he has to
do is to ignore SPF. And if he likes SPF he has to do it at
his border MTA, not somewhere else (later in his routing).
Often the user has no control about the MTAs. Seems there already
exist sites that reject SPF fail and perhaps don't allow to whitelist
non-SRS forwarders.
Ya know, not all mail users are also MTA admins/developers.
[...]
Kind regards,
Hannah.