On Dec 27, 2005, at 5:20 PM, Frank Ellermann wrote:
Douglas Otis wrote:
The response was specifically against the use of "authorization."
With respect to SPF/Sender-ID or SSP, these are indeed email-
address "authorization" schemes.
There's no "burden shifting". If you have a PASS you know that the
Return-Path is no random garbage, you can bounce or challenge
without hitting innocent bystanders.
The email-address domain owner bears the burden when email-address
authorization is considered "weak" authentication and used to accrue
reputation. The burden is shifted when the email-address
authorization does not indicate the actual sender. In shared
environments with millions of compromised clients, these public
authorizations will act as invitations. Most email-address domain
owners will suffer harm well beyond their control, as only a few
administer their own private servers. Repairing exceptions only
increases these exposures when this involves open-ended
authorizations (by any name).
...
Back to SPF PASS, I'm free to say "v=spf1 +all". If that backfires
with whatever you do it is my problem, it's not your problem. A
bogus SPF record is as bad as bogus MX records, that's no "burden
shifting", it's a fact of live.
This back-scatter problem can be resolved by implementing BATV at the
cost of two additional wafer-thin packets. (This would be far less
overhead than looking up SPF records.) Unlike the (defunct) SPF
scheme aimed at qualifying the return-path, BATV does not wait for
wide adoption before benefits can be derived. The BATV signatures
should be obfuscated upon delivery, and the same obfuscation could be
common practice for DKIM, as described the in the options draft. : )
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf