On Fri, 6 Apr 2007, you wrote:
Michael Deutschmann wrote:
5 - The MX checks the SPF policy of mailout-N.fwd.example, expecting a
PASS for the HELO. If that's the case it accepts the AUTH (end of
the SASL business, a kind of EXTERNAL mechanism). Any other SPF
result kills the AUTH.
TENBOX/E doesn't care about the HELO argument. The "AUTH TENBOX"
command always succeeds.
Strange. Why bother with this SASL mechanism if it does nothing at all,
and any random spammer claiming to be mailout-N.fwd.example would "pass"
the EHLO step ?
You could replace "AUTH TENBOX" by "AUTH ANONYMOUS" (RFC 4505) if the
whole purpose of this exercise is to enable later AUTH= parameters.
I'd prefer a new AUTH SPFHELO requiring a HELO PASS, i.e. something in
the direction of SASL EXTERNAL instead of SASL ANONYMOUS. Please note
that we're talking about receivers suporting SPF, they should check the
HELO-identity anyway: An SPFHELO SASL mechanism would reenforce this.
6 - The forwarder says MAIL FROM x AUTH=user(_at_)fwd(_dot_)example (or
another
kind of "TENBOX token"), the MX accepts it on probation.
You've missed the most important step:
6a - the MX looks up a "v=tenbox1 ..." TXT record for fwd.example (or
whatever the domain part of the TENBOX token was), and does something
very similar to SPF with it.
I've never heard of any v=tenbox1 records. What's the difference from
v=spf1 TXT or SPF records ? But yes, I've missed that step - you talk
about it as if a draft exists, please post an URL if that's the case.
If this AUTH=user(_at_)fwd(_dot_)example is almost the same as Stuart's
"pretend
MAIL FROM" we might talk about something that's really better than SRS,
so far I was only curious... :-)
The main reason TENBOX/E might be expected to do better than SRS is
that it can lessen backscatter and reputation-blackening effects
that presently occur when a bad mail (spam, virus, etc.) gets past a
forwarder's own defenses but is detected by a downstream MX server.
So forwarders have an incentive to deploy it.
That's from a forwarder's POV. From my POV as original sender I'm not
interested in any bounces for mail not sent by me, that's why I have
an SPF FAIL policy. Does TENBOX guarantee that forwarders reject any
SPF FAIL before trying their TENBOX forwarding magic ?
In contrast, SRS solves only one problem forwarders have, which the
forwarder can more conveniently solve by simply insisting that the
recipient not use SPF.
Well, for an account at one of the three largest email providers in my
country I've just enabled "reject SPF FAIL", and it promptly rejected
a forged mail from google on my behalf (claiming to be a mail from me).
It's one of those Google beta tests, the mail was an "invitation" to
a service for "ordinary" accounts (= my own mail address, not gmail).
What I really want to say, I'd insist that my next mail provider does
not only publish SPF FAIL, but also rejects it.
Frank
-------
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
-------
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