Re: [Asrg] Re: Why SPF? (was: Anti-spam laws do work, FYI. There's proof.)

["Alan DeKok" <aland at ox.org>]

Dave Crocker <dcrocker at brandenburg.com> wrote:
> In what substantive way is it different?

  Details follow.

> AD>   That's a false analogy, based on wording that MTA's "carry" traffic.
> 
> It is, in fact, an extremely precise and accurate analogy.  I'm glad to
> explore the details and explain why, but that will take some extended
> discussion.

  I explained why I held my position.  You deleted that text, and
ignored my reasons for holding my position.

  Let me be perfectly clear: I do not believe that SMTP "forwarders"
exist, except in certain limited situations such as off-site backup
MX's.  Let me explain in detail.

  An off-site backup MX is accepting a stream of SMTP traffic on
behalf of a primary MX, with the intention of storing that traffic,
and later sending it mostly unchanged to the primary MX.  For logging
purposes, each message is changed solely by the backup MX adding a
"received" line.  This behavior is similar to that performed by
routers when they process IP packets containing an IP "record route"
option.  Both processes may be called "forwarding".

  When an SMTP server "forwards" email on behalf of a user, I will use
the term "email forwarder".  This is to distinguish this case from the
previous one, of an "SMTP forwarder".  So far as the end user is
concerned, the content of the email has been forwarded through
multiple email servers, prior to its final arrival.

  However, on an SMTP level, the SMTP headers have been re-written, so
the SMTP traffic *cannot* be said to be forwarded.

  As an analogy, let's look at a NAT gateway.  It may forward user
appliction data (web surfing, etc), but the IP & TCP packets are
re-written.  The NAT gateway accepts responsibility for ICMP messages
associated with that traffic, and maintains state so that it can
re-write the ICMP message, and send it to the end host.  The NAT
gateway also accepts the responsibility of appearing to originate the
traffic itself.  The NAT gateway is NOT forwarding the TCP/IP traffic,
it is acting as a gateway.  the NAT gateway IS forwarding the
application data.

  In our current email system, the "SMTP gateway which forwards email"
often does NOT accept responsibility for the email messages that it
forwards.  Instead, such gateways try to get the recipient to send
errors to some third party, rather than maintaining state, accepting
the errors itself, and forwarding the errors to the original sender.

  That model works for IP, TCP, and NAT.  I don't see why it wouldn't
work for SMTP & email.

  That is, the current concept of "email forwarding" is, in many
cases, wrong and broken.  If we prevent the current broken system from
being deployed from now on, it wouldn't bother me.  But that means we
*should* update our SMTP implementations so that responsible
(i.e. state-maintaining) "email forwarding" can occur.

  The concept of "email forwarding" isn't a bad one.  The current
design and implementation is broken.

> Every MTA "originates" traffic.  SPF, et al, pertain
> only to the original posting of email into an MTA.  It pertains to every
> MTA that does relaying of the mail from the originator to the recipient.

  If those MTA's do "SMTP forwarding", then SPF doesn't affect them
much, as they've already established a trusted SMTP relationship with
each other.

  If those MTA's do "email forwarding" without maintaining state, then
while they may be "relaying" email message bodies, they are *not*
relaying SMTP sessions.  This distinction is critical to understanding
my position.

  e.g. Mailing lists.  The RFC 2821 SMTP headers from a mailing list
shows that the mailing list accepts responsibility for the message.
The RFC 2822 headers shows that the message was forwarded through the
mailing list.  The message *body* often is re-sent unchanged.

  So while a mailing list may be an "email forwarder" in some sense,
it is in no way an "SMTP forwarder".

> That is the nature of the specification and existing email architecture.

  For the vast majority of messages, no.  They get sent from an
outgoing SMTP server for a domain, and (using IP & TCP) get sent
immediately to an incoming SMTP server for another domain.  (modulo
backup MX's.)  Those messages may get submitted and downloaded via
non-SMTP methods, but there's often only one SMTP client-server hop
for a message.

>  Feel free to cite where constraints to a single MTA in the path are
>  specified and why they will work.

  I don't see why.

  Alan DeKok.

_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg