On Sat, Dec 02, 2006 at 11:41:54PM +0000, Julian Mehnle wrote:
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.
I am fully aware of that. Still, by saying "+a:host", you are authorizing
host to send mail using your domain in the envelope sender, and if mail
with that domain in the envelope sender becomes increasingly abusive,
expect receivers to reject mail with that domain in the envelope sender.
Sure. But that's no reason not to publish PASS. I don't expect this
to happen, just as you don't expect it to happen at your ISP.
Whoa, slow down a bit! Saying that you are splitting hairs should not be
taken as an insult. I merely ment to say that I think you are seeing a
difference between
"I authorized this host to use my domain in the envelope sender"
and
"I authorized this host to use my domain in the envelope sender, and
I expect receivers to start rejecting mail from that domain if it
becomes increasingly abusive"
where I don't see such a difference. What does "authorization" mean if
others can't take you seriously for it?
I _also_ don't see a difference. Again, this is not a reason to
not publish PASS for such a host. I do not expect that my provider,
where it would be possible ***on a technical level*** to do cross
customer forgery, will emit large quantities of forged email. I trust
that they will track down the forger and that they will get rid of it.
That is another way of dealing with cross-customer forgery and, as far
as I'm concerned, a completely legitimate way. Money talks, you know.
Whatever, this is not about the RFC, it is about what hosts you authorize
to send mail using your domain in the envelope sender.
Indeed it is. And nothing more than that. This is exactly my point.
Semantics of how trustworthy the message is, is not part of the spec.
You can send bounces to me (as the victim) if I publish PASS. And my
reputation is at risk so you bet I will ask my ISP to deal with the
forger should I become aware of a problem. In the end, forgery stops,
and that is the goal of SPF. If forgery would not stop, I would stop
using the host (and stop publishing PASS for it.) This also would
end the forgery (from authorized hosts).
But in reality, I expect my provider to notice abuse before I do, and
I expect them to deal with it before I have to. That's why I bring my
money to them, so that I don't have to worry about it.
*How* they fight forgery is their business. If they feel they need to
make cross-customer forgery impossible on a technical level, that's
their choice. And if they can manage it without technical implementations,
that's also their choice. As long as they are doing a good job, they
earn my confidence and I publish PASS.
If we went by your interpretation, then you could rightfully demand that
nobody reject even some theoretical kind of "HardPass" (meaning that
cross-user forgery is being prevented) if your domain is on an abuse
black-list, because after all you just authorized the host to send mail
using your domain, and not the runaway processes on that host or the evil
hacker that just hacked your machine.
All that I ask is that such a blacklist is not permanent. If an
authorized host is indeed emitting spam in my name, I expect you
to contact me or my provider, and the problem is delt with. But
if the same spam is coming from a provider in China, I have no
control over it thus I will not publish a PASS for that host.
Hosts for which I publish PASS, can indeed be input to a reputation
based service. That's the whole point of the SPF specification as
it is published now, and we don't need yet another result, such as
"++" or "*+" meaning "and I really mean it" because I do already
mean it.
I just don't see how this concept of yours can make sense. If you want
"Pass" to mean nothing but "You can send bounces here", then what is that
worth? If there was a cross-user forgery, the bounce would go to the same
domain, but still to an innocent victim.
If the technical provisions at the provider aren't as secure as you
think they are (e.g. hacked php scripts sending from or via an authorized
host, or cross customer forgery is possible after all) then your host will
*also* emit forged email. You don't expect this to happen, at least
not so often that you won't authorize the host. Same here, but using
a different method (something political in stead of technical).
There is no difference. You are confusing the means with the goal.
*How* something is done is not important. The important thing is
*that* something is done. "something" in this case meaning fighting
forgery.
No. If "Pass" (+) doesn't mean that I can apply reputation, then it is
worthless.
Nobody is saying that you can't. That's the whole point. I don't need
NEUTRAL, I trust my provider. So do you. No difference.
This whole idea of publishing NEUTRAL for shared hosts is pointless.
It means "I don't know if this host is authorized or not". It does
not mean "I don't know if messages from this host are mine or not".
That would be another protocol, not SPF.
Additionally, in stead of having to deal with billions of possible
forgers, most of them at providers I have no relationship with,
[even if cross-user forgery is possible,] I only have to worry about a
fraction of them.
Great! Only that doesn't say much for domains like aol.com, hotmail.com,
or gmail.com.
Doesn't it? If aol does not deal appropriately with spammers, their
hosts get a bad reputation. And they will go out of business, or change
the way they behave. Does this sound familiar perhaps?
It doesn't matter if such a reputation is IP based or domain based.
The Internet *will* deal with it.
If aol would get a bad reputation again, I would be a fool to publish
PASS for it. Thus I wouldn't. But don't you say that *any* host where
cross-customer forgery could potentially happen is to be given NEUTRAL.
First of all, NEUTRAL is not a punishment, secondly publishers are
allowed to end their record in "?all" but that would make other
NEUTRAL mechanisms moot.
Telling newbies to publish NEUTRAL for shared hosts, without telling
them why you think so and that there are other opinions (and why) is
something I consider short sighted. It results in stupid policies
like "v=spf1 ?include:isp.example ?all".
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