On Sat, Dec 02, 2006 at 09:01:37PM +0000, Julian Mehnle wrote:
Well, fine, then I'm going to just assume that "the host was authorized"
and _still_ apply domain-based reputation. If a domain authorizes hosts
to send abusive e-mail on their behalf, they _will_ get blacklisted, no
matter the amount of semantical hair-splitting you throw at it.
When I publish "+include:provider.example", I do not, I repeat: not,
authorize a host to send abusive e-mail. SPF is not about content.
Policies or technical measures: some amount of abuse will be
hard to prevent. That's why domain based blacklists will not
operate on a "one mistake and you're out forever" policy.
What matters is that cross-customer forgery will eventually be
minimal. It doesn't matter if that's going to be because of
technical measures or strictly enforced provider policies.
Providers not enforcing their policies will lose customers, or
end up on blacklists (and lose customers).
Actually I find the remark "hair-splitting" insulting. If it is
not that important to you, you should not put so much effort in
getting it your way.
When I authorize a host, I am not authorizing all of its users
to forge my name. You seem to think that I am. Well, as the
RFC clearly states, an SPF policy is about the host, not about
its users.
Additionally, in stead of having to deal with billions of possible
forgers, most of them at providers I have no relationship with,
I only have to worry about a fraction of them. If my provider
wants my money, they will remove malicious users. If they don't,
I will remove my money from them and stop authorizing their hosts.
If my provider sends mail in my name, send your bounces to me. I
authorized the host, thus I want to know about problems so that
I can act, and demand my provider acts as well.
You say you can only authorize a host when you trust its keeper
to do the right thing using technical measures (that's how I
interpret it anyway.) However: If you rely on technical ways to
prevent abuse, you could also find yourself authorizing hosts
sending spam. Two examples
would be:
- your own PC is hacked (or virus infected) and is sending out
messages via your authorized provider
- your provider screwed up, and the technical barrier isn't as
sound as you believe it to be (is the webhost authorized?)
Alex
-------
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