spf-discuss
[Top] [All Lists]

RE: [spf-discuss] Alias forwarder as associate MX

2005-09-16 11:44:11
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

<Prev in Thread] Current Thread [Next in Thread>