Michael Deutschmann wrote on Saturday, April 07, 2007 6:51 PM -0500:
On Sat, 7 Apr 2007, Frank Ellermann wrote:
Yes, and that's where I'm *V*E*R*Y* *I*N*T*E*R*E*S*T*E*D* With SRS
it is clear that forwarders take the responsibility for mails
forwarded by them as they should under RFC 821 rules (and
explicitly did by adding their identity to the reverse path in the
pre-1123 world).
Ah, you're calling it a feature that SRS forces forwarding providers
to stake their IP reputation on the identification of a message as
non-forged.
It was a very intentional feature of SRS. SPF gives domain owners a
tool to tell recipients how to detect when that sender's domain is
forged. It works by associating IP with MAIL FROM domain name, which
happens to force senders to take responsibility for *everything* they
emit, regardless of how they got it. This is the fundamental SPF
assumption. While forwarders feel they are an exception, because
someone else purportedly originated the message, that violates the SPF
assumption of full responsibility for your outflow.
"Be liberal in what you accept, and conservative in what you send"
- J. Postel
But SRS also forces them to either "sign off on" or refuse to accept
SPF-neutral, SPF-none, and SPF-softfail mails. This just isn't
reasonable today.
I don't agree. Identifying the party responsible for a given message is
fundamental to stopping network abuse in general. If forwarders to be
part of the solution rather than part of the problem, they have to be
careful of what they send and that means taking responsibility for it.
While this clearly makes forwarders' lives more complicated, it puts
responsibility where it belongs: at the original destination hop, where
it is possible to detect forgeries and spam based on sending system
identity and identity.
Entities that punish backscatter, such as UCEPROTECT, generally
believe that backscatter should be prevented by abolishing DSNs
entirely, not by sender validation. So for them "I couldn't get
a clear SPF answer" is not an excuse for backscatter.
Abolishing DSN's would also abolish the reliability of SMTP. At the
same time, a forwarder claiming they couldn't determine the responsible
sender is not an excuse for backscatter, which is network abuse.
And for an SRS forwarder, abolishing DSNs entirely just isn't
possible. Even if they go to the *extreme* of conducting
incoming and outgoing SMTP transactions simultaneously, they
can still get saddled with a "MAIL FROM: <> / RCPT TO:
<SRS0=blahblah(_at_)blah>" hours later from the next hop.
Conducting the outgoing leg of a forwarding transaction during the
incoming session will create problems and in some cases is network
abuse. Getting a delayed DSN for a message you didn't send is
unfortunately the nature of alias forwarding and is why many people
consider it a poor practice. Unfortunately, it is now enshrined in
practice.
If you accept the idea that everyone is responsible for the mail they
emit, as SPF assumes, then forwarders' lives are undeniably harder than
they used to be. At the same time, there is no good reason for everyone
else to accept forgeries simply because forwarders are used to a more
relaxed environment.
If the final recipient trusts the forwarder's TENBOX token enough to
stand down SPF, it would be silly not to also stand down their content
filters (SpamAssassin, ClamAV, DCC, etc.). And content filters are
the leading cause of forwarder bounces.
In general, recipient systems have a large incentive to continue
performing content checks, even on whitelisted forwarders, as end users
blame the final recipient system for all spam in their inbox. While the
first forwarding hop is in the best position to reject spam and
forgeries, end users don't know that and would likely consider it an
excuse.
I would still like to hear how tenbox might reduce effort and user
complaints for recipient systems.
Big ISPs who want to stay off the FrankBL would maintain their own
blacklist of forwarders who ignore SPF and simply refuse to allow
their customers to extend TENBOX/E trust to those forwarders.
BigISP doesn't care about FrankBL (they like Frank, but they barely care
about SPF). BigISP also does not care about forwarders' problems or
even their continued viability. They care only to minimize complaints
from their own users.
--
Seth Goodman
-------
Sender Policy Framework: http://www.openspf.org/
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/?list_id=735