ietf-mxcomp
[Top] [All Lists]

Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004

2004-09-15 14:18:19

On Wed, 15 Sep 2004, David Woodhouse wrote:

Right.  When you add SRS in to the equation, SPF Classic essentially
"degrades" in to CSV-like functionality.

That's twice you've said this of only 'mailfrom' scope, and it doesn't
seem to have been an accident.

It should be noted that the 'pra' scope, with the forwarders able to add
an arbitrary domain in whatever header is used in place of the
'Resent-From:' header, has precisely the same characteristics.

Not arbitrary, forwarders can only add domains they are authorized to add
in the Resent-From: header (if the receiver is checking the PRA).

The difference between adding headers and using SRS is that in order to
avoid blowing 64-byte localpart limit, SRS advocates that secondary
forwarding hops (anyone doing an SRS rewrite on an SRS0 address) remove
the interim hop information, so you really only do know the first hop a
message purported to take and the last hop it really did take.  By adding
Resent-From headers you can get some idea of the full path that a message
took, and if you trust different hops along the path to add the proper
checks then you can do some work to determine where a message came from
before it started along a chain you trust.

Of course, this is ludicrously complex, difficult to implement and manage,
and probably subject to creative spoofing somewhere.  If we want to admit
that none of the IP-based schemes can safely give us any assurance beyond
the most recent hop, then we should be working on systems that admit that
and don't try to reach beyond what they can really do by changing a
fundamentally important piece of envelope information like the bounce
address.

I personally believe that Sender ID gives a positive benefit in that its
going to allow people to positively identify a user-visible piece of
messages coming from certain sources for a large majority of real internet
traffic (direct site-to-site, no interim hops).  The IP-based solutions
won't allow many of us to outright reject forgeries at the border because
the risk of false positives introduced by forwarding and mail lists is
just too high, but they will allow us to remove uncertainty about the
legitimacy of messages that came directly to us.

To get end-to-end security we will have to use crypto, and I think
everyone here would agree with that.

-Rand