On Tue, May 17, 2005 at 11:24:46AM -0400, Hector Santos wrote:
Hector wrote:
"v=spf1 ?a:spammer-example.com -all"
and the server [sender] always send mail with the email domain:
spammer-example.com
Alex replied to hector:
So?
The host with name "spammer-example.com" is emiting email with domain
"spammer-example.com" which is exactly what we want.
Maybe I don't get where you're going at. I think one of us has a bad day
and I sure hope it's you, (not too bad though) :)
HA!! I don't wish the worst even on my enemies :-)
I still think you have a bad day but I certainly don't wish you
any harm whatsoever.
I think we are more in agreement than not.
Maybe, in that case I still don't see your point. Better yet, I
am now more convinced that we disagree, not agree.
My only point is that relaxed provisions does put the burden on the
receiving system to decide how to handle relaxed results and I am on the
strong technical opinion, that this will get out of hand eventually once SPF
is widely adopted.
So why do we care if the "spammer-example.com" is being forged or
not? It is going to be blacklisted anyway. This is the purpose of
SPF: to be able to use domains as a basis for reputation.
I really don't care if "other-spammer-example.com" forges the
address of "spammer-example.com". They both have no business
in my inbox. If I can block "other-spammer" because he was able
to forge "spammer"'s domain, so be it. Let the spammers fight
each other, I couldn't care less. I'd say "spammer-example" is
really stupid to give "other-spammer-example" access to his box.
For my purpose, it doesn't matter if there is "+", "~", "?" or
even "-" in front of this host. Just saying "mail from:
<freind(_at_)spammer-example(_dot_)com>" is enough.
SPF is only important for mail from any@"winserver.com" and
similar domains: email I want to receive but which may be forged.
Depending on my mood, the maturity of SPF, phase of the moon
and other factors, I decide if "?ip4:208.247.131.9" is or is not
going to pass my filter. If it does, it will still go via the
virus scanner, spam filters and whatever. Should the ratio of
forged mail vs good mail from 208.247.131.9 be high, it will
end up on an RBL. RBL checking isn't going away and will most
likely be done before SPF. Should the host change its policy
from "?ip4" to "ip4", mail will still be blocked by RBL or,
if not blocked, will still be scanned by SpamAssassin.
Only to go back to square one with a SPF relax policy.
Original SMTP system + SPF with relaxed domain policy:
MAIL FROM: domain ---> indecision with relaxed result.
Not sure that it's not an authorized host for domain, not sure
that it is. In any case, if I don't want to receive messages
from "domain", I can block it right now. If my policy is to
only accept mail which is authorized by the domain owner, in
this example the sender is out of luck. Spoofer or not.
My proposal is to make the relax provisions time limited.
It already is. In a not too distant future:
- Domains without SPF are used to forge messages. Those domains
will be blocked more and more, not on basis of the domain name
but just because they aren't graylisted and thus blacklisted.
Eventually, domains will implement SPF and this problem is solved.
- Domains having "?all" are used to forge messages. Those domains
will be blocked more and more (see above). Eventually, domains
will specify "-all" and this problem is solved.
- Domains having "?outhost.provider.tld" will fall in two categories:
- those with active forgers in provider's customer base with access
to outhost.provider.tld (including zombies and such)
- those without.
In the first case, such a provider will be blocked en masse, similar
to what happened to the various microsoft domains. Bad reputation
and hard to repair. I think most of these providers will be listed
as spam havens, null routed or whatever else appropriate. Most
important: they will be lesser in numbers.
The second case is no problem.
In both cases mail will make it into the virus scanner. There is
no difference.
In both cases I think manual intervention from the receiver will be
the best approach. Eventually "domain"'s reputation will be damaged
and end up on a blacklist or similar. Again, these will be lesser
in numbers.
- domains with "~all". See "?all" (we're talking future, not present!)
- domains with "~outhost.provider.tld". See "~all".
Did I forget anything?
Alex