On Tue, Sep 19, 2006 at 06:04:00PM -0400, Scott Kitterman wrote:
SPF allows a receiver to quickly sift forgeries from other mail. It
does so by looking at the authorization status of a host. The remaining
messages (after throwing away obvious forgeries) still needs to be
examined further. Cross user forgery is such a case. It's just that
you only have to examine 10% (or so) of the original amount of mail.
Agreed, except it'll be more than 10% soon if it isn't already. Getting an
SPF pass for a random throw-away domain is pretty trivial. Reputation
systems will have to step up to fill that gap.
Indeed. And as their reputation goes down the drain, either such domains
will change their methods or they will be "darwinized".
If a customer feels such irresponsible provider should be kept alive
and thus brings his money to the provider, well, that's their choice.
Smart customers will move, or setup their own mailservers.
It's not a question in my mind of just trusting the provider, it's trustung
their however many hundred thousand customers too.
If you cannot trust your provider to deal with problems quickly and
accurately then you cannot trust your provider. Don't send your
precious mail through them.
If you have employees, you also trust them. That does not mean you
will never have a rotten apple aboard. But if your company has
several rotten apples and if you don't get rid of them, the company
should, and does, suffer. Translated into an email policy, this
justifies "a:mailserver.example.com", not "?a:mailserver.example.com".
Yes, your employees signed a contract. You will have to enforce this
contract. Dito for the provider. Each customer should have signed a
contract. If not, or if not enforced, the provider cannot be trusted.
All other cases where these contracts are enforced deserve a `pass'.
Does `pass' mean bad things will never happen? No. I don't think so.
`pass' does not mean `not forged' just as `fail' does not mean 'forged'.
`fail' means: `not authorized' and implies `probably forged'. This
also means it is OK to have `pass' implies `probably not forged'.
Currently I do not know of any commercial SMTP service that permits
'foreign' e-mail addresses to be used that will also prevent cross user
forgery, except mine. That's why I set it up. Telling someone to get a
provider that will not allow cross-user forgery today isn't much of a
choice.
And exactly this is what I want to see happening. The market will
deal with the problem, the protocol does not need to be changed.
Perhaps you are the first one. Good for you. Now if many will follow
the world will be a better place.
Not if you include: free mail providers. Agree cross-user forgery is not a
high risk today unless someone has a specific rreason to target your
particular domaim, but I still recommend Neutral as a future proofing
method. Most people aren't going to keep in touch with the latest trends
and know when to change.
[...]
These days I generally recommend ~all for small domain owners so there some
distinction.
I'm pretty sure ~all was intended as a temporary measure, for people
not entirely sure they got their SPF record right. It certainly is
quite different from "?all" which some people need and want, even
after careful consideration.
I may not agree with their decision but I will support it. Their
intention is to be able to authorize some hosts, distinguishing them
from other hosts covered by "all".
If you want authentication, the minimum is some form of encryption,
like SES. Do not mistake SPF for something providing authentication.
I would have said PGP or S/MIME. What does SES tell you beyond it passed
through a certain mail server that signed it. I'd say the same for DKIM.
I was assuming here that you, as the true sender, would sign it. I, as the
receiver, only need to compute the hash for those few messages being sent
through an authorized host, not those being sent from or through hinet.net,
swipnet.se, tele2.fr and other infested sources/relays.
Forget I said SES and DKIM. Use any example protocol that would benefit
greatly from a reduction in work.
I think we are disagreeing about what authorization is good for. I say if
example.com authorizes a server to send their mail and it comes out spammy,
then they should pay the price and have a bad reputation, get RHSBLed, etc.
For just one occasion of such bad mail: no, that shouldn't happen. But yes,
if example.com authorizes open-relay.stupid-provider.example and does not
change things, example.com is guilty and should pay the price.
Maybe we have a different opinion on how reputation should work. I don't
think 'one strike and you're out' is the correct thing to do.
I think authentication is for things like "You sent me a signed e-mail
accepting the contract, now you are obligated to pay".
That's email body, not envelope.
But now you are receiving 100 of such messages. Using SPF, you can get
rid of 90 (or any other number). You only need to process the remaining
10. That's what SPF is about. So even in this example, SPF is worth
something yet is no substitute for authentication.
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com