-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Kitterman wrote:
I have stayed away from marking mail from shared MTAs that don't prevent
cross customer forgery with PASS. I have also advised others to do that
too. If Meng's new philosophy is right (see excerpt from the last
council meeting below), then those of us on shared MTAs are in trouble.
Frankly, I don't buy into nihilism like "let's weaken the meaning of FAIL,
let's weaken the meaning of PASS, let's broaden the scope of v=spf1". All
of this sounds far too much like the old "SPF is bad because it breaks
forwarding" propaganda.
Ladies and Gentlemen, we need to stay focused. The ultimate goal must be
getting more accountability into the everything-goes-and-nobody-cares
e-mail system. As an instrument to achieving that goal, SPF is supposed
to fix some of the ambiguities of RFC (2)821, which naturally means
breaking certain legacy behavior and nailing down the laissez-faire
attitude of naive participants of the e-mail system.
If we aren't convinced of the necessity of that, we could as well give up
and go home right here and now.
It may be helpful to remember that SPF basically is nothing more than the
counterpiece of classic MX records. If that's too much for the e-mail
world, then what's the point of carrying on?
SPF assigns responsibility to domain owners and to the physical senders of
e-mail. Systems (including but not limited to SPF) must be designed and
configured in a reliable way so that people are willing to assume
responsibility for their actions. Only then will they accept the rules.
SPF in itself does not cause any real new problems, it only reveals ones
that have silently existed for a long time. If domains get bad reputation
because ISPs don't prevent cross-customer forgery, it would be fatal to
resolve that by weakening the meaning of SPF "Pass". If forwarding breaks
because forwarders don't rewrite the envelope sender, it would be fatal to
resolve that by weakening the meaning of SPF "Fail".
If ISPs insist on not preventing cross-customer forgery (i.e. allowing the
abuse of users' domain names), they're bound to get bad reputation, and
their users will move on to other ISPs. If forwarders insist on not
rewriting the envelope sender (i.e. not taking responsibility for the
messages they forward), they're bound to get bad reputation, and their
users will move on to other forwarders.
It is clear that this holds only if the masses out there do subscribe to
the idea of accountability and responsibility. It must be our goal to get
this into people's heads. Defy the nihilists!
With specific regard to what Meng said: Making only positive assertions
("Pass") and no negative ones ("Fail") is pointless. If an SPF modeled in
such a way could gain any relevance at all, people would just begin to
treat non-positive (=neutral) results as negative ones. Besides, there
will _always_ be detractors denouncing SPF for one reason or another. "I
can't send mail from everywhere any more! I can't use my employer's
domain against his will! SPF sucks!"
The important thing is, we _do_ have a consistent vision of how things can
work with SPF. Constantly conceding substantial ground to detractors
won't solve any _real_ problem whatsoever.
This doesn't directly require a change in the spec, but a statement of
policy (and an update to the web site when such things are being done
again) would likely be enough. The most I would suggest would be a
sentence added to 10.1, perhaps:
"Additionally, it is possible that a malicious sender is an authorized
user for the MTA in question, but not authorized to send for by the
domain owner."
A good idea. Perhaps it would be more appropriate in section 9.4, though.
Wayne, what do you think?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCfVERwL7PKlBZWjsRApdvAJsEOChazkLK+Eyi5OoQa3tixV2j2wCg5g7q
YA8u6VOWJKyXf3EPkqxlkQE=
=8FIA
-----END PGP SIGNATURE-----