From: Dick St.Peters [mailto:stpeters(_at_)NetHeaven(_dot_)com]
Sent: Friday, September 16, 2005 10:08 AM
Seth Goodman writes:
Here's what RFC1123 says about gateways:
....
This is pretty clear. Gatewaying involves relaying between the internet
using SMTP and private networks, generally using a foreign protocol.
Just a couple of minor nits: At the time of 1123 most internet
gatewaying was between the internet and other public email systems,
not between the internet and private networks. Some of those public
mail systems were arguably part of the ill-defined internet but
neeeded gatewaying for various reasons. For example, JANET (Joint
Academic NETwork) used addressing with domain components written in
the opposite order - e.g.,
user(_at_)uk(_dot_)ac(_dot_)oxford(_dot_)cs(_dot_)host(_dot_)
Very good point. The networks gatewayed to and from were usually public.
To further clarify, the internet is really the complete collection of all
the interconnected networks, including gateways, so my statement was not
very precise. RFC2821 does get more precise, as in section 2.1:
An SMTP server may be either the ultimate destination or an
intermediate "relay" (that is, it may assume the role of an SMTP
client after receiving the message) or "gateway" (that is, it may
transport the message further using some protocol other than SMTP).
This is reinforced in section 3.8:
3.8 Mail Gatewaying
While the relay function discussed above operates within the Internet
SMTP transport service environment, MX records or various forms of
explicit routing may require that an intermediate SMTP server perform
a translation function between one transport service and another. As
discussed in section 2.3.8, when such a system is at the boundary
between two transport service environments, we refer to it as a
"gateway" or "gateway SMTP".
So the distinction of a gateway appears to be that of different transport
protocols on each side. However, section 2.3.8 extends the gateway
definition to include the boundary between the public internet and a private
network where the transport protocol might be the same on both side (i.e.
NAT routers):
2.3.8 Originator, Delivery, Relay, and Gateway Systems
This specification makes a distinction among four types of SMTP
systems, based on the role those systems play in transmitting
electronic mail. An "originating" system (sometimes called an SMTP
originator) introduces mail into the Internet or, more generally,
into a transport service environment. A "delivery" SMTP system is
one that receives mail from a transport service environment and
passes it to a mail user agent or deposits it in a message store
which a mail user agent is expected to subsequently access. A
"relay" SMTP system (usually referred to just as a "relay") receives
mail from an SMTP client and transmits it, without modification to
the message data other than adding trace information, to another SMTP
server for further relaying or for delivery.
A "gateway" SMTP system (usually referred to just as a "gateway")
receives mail from a client system in one transport environment and
transmits it to a server system in another transport environment.
Differences in protocols or message semantics between the transport
environments on either side of a gateway may require that the gateway
system perform transformations to the message that are not permitted
to SMTP relay systems. For the purposes of this specification,
firewalls that rewrite addresses should be considered as gateways,
even if SMTP is used on both sides of them (see [11]).
It's a bit unfortunate that they left out the MSA role defined in RFC2476,
but that's another issue. The last sentence quoted above makes it tempting
to extrapolate, "forwarders have SMTP on both sides and SRS causes them to
rewrite addresses, so forwarders must be gateways". However, the same
standard explicitly defines alias forwarding in 3.10.1:
3.10.1 Alias
To expand an alias, the recipient mailer simply replaces the pseudo-
mailbox address in the envelope with each of the expanded addresses
in turn; the rest of the envelope and the message body are left
unchanged. The message is then delivered or forwarded to each
expanded address.
This is pretty much the same language as in RFC1123, so while RFC2821 is
still a proposed standard, it is clearly affirming the practice of alias
forwarding described in RFC1123. Lest there be any doubt, RFC2821 further
says in section 3.4:
3.4 Forwarding for Address Correction or Updating
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.
I hope that puts to rest the argument that alias forwarding is
bad/broken/undesirable/evil/immoral as irrelevant as well as the claim that
alias forwarding is really gatewaying. Alias forwarding is a part of SMTP,
for better of for worse, and it is not going away any time soon. We can't
ignore it, even if we don't like the practice.
In support of some of the concerns that Alex and others have voiced, the
next paragraph in section 3.4 warns about unnecessarily exposing the final
address through the careless use of 251 and 551 codes. However, they do
_not_ mention anything about final destination gateways not bouncing to the
original sender, which has exactly the same effect. I think the reason is
obvious: without a reverse source route, sending the DSN back to a
forwarding account is pretty useless. An alias forward is a one-way conduit
that changes the address of RCPT TO and reinjects the message. No one
fetches mail from such an account, as it is designed to forward to another
account that you _do_ fetch mail from.
If you really feel the need to hide your "real" email identity and make sure
bounces come from the forwarding address, get a separate mail account
somewhere and fetch your mail directly from that server. In other words,
don't use forwarding. That's very simple and doesn't break the forwarding
mechanism that has been part of SMTP for a very long time. I think the
number of people who are concerned with hiding the final address of their
forwards is extremely small compared to the number of people who use
forwarding. The option I gave here solves their problem with no chance of
leakage of their private address. I am unaware of any contemporary MUA's
that have difficulty fetching mail from more than one server.
--
Seth Goodman
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com