> Of course, if you don't lock the door of your car
> and somebody breaks into it, your probably should
> have locked your door.
If somebody breaks into your car, it doesn't matter if you locked the door, and it doesn't matter if you will lock your door.
If somebody opens the door and enters your car without breaking into it, you probably should have locked your door.
The difference matters both for insurance purposes and for fighting spams ^_^
Yeah, I guess my point was to not make it any easier for spammers. It's not a great analogy, but it will do.
Terry, I thought the Microsoft-approved statistic was something like 80% of domains publish SPF/SIDF records?
How does this square with your, "Only a minority have ... published SPF records"? Am I missing something?
My statistic is based upon a quick search for SPF adoption. I don't know where MSFT gets their official stats, but wherever they come from I didn't use them.
1. True, and worst is there are those that are not properly implemented... Not even microsoft (huge proponent of SPF) is yet properly configuring SPF records for their smtp servers and for instance smtp.microsoft.com has no SPF record.
2. Not so true, that is only for Sender-ID with PRA, the more common and more widely used spf1 does not make such distinctions (restrictions) and with SRS is perfectly capable of relaying mail successfully.
SPF doesn't have the shortcomings of "Sender ID". It is probably rarely practical to ever implement Sender ID.
For newsletters, other domains or subdomains can be used while it is entirely possible to use SPF to restrict all but a few addresses or allow a few addresses and individual users to use third party relays or be indifferent of the relay used.
Your examples of SPF are not proper working examples -- the SPF records should be updated to account for whatever examples you want or they shouldn't be allowed. Messages should not be accepted just because they are not spam (imagine a message with a .EXE attachment or perhaps a 50MB message), and it is perfectly acceptible to reject messages because the SPF is bad -- it is infact what should be done so we can get back to my point about #1 -- PROPER implementation.
3. Not so much of a big deal, spammers still have strikes against them and this allows us to blacklist real addresses not bogus ones and forces them to use additional real resources (for hosting) which can be tracked down unlike trojan resources.
Regarding number 2. You can use the include directive of an SPF record to include the SPF records of your third party mail sender. For example: if awesomewidgets.com has outsourced newsletters to awesomemailers.com its SPF record might look like:
awesomewidgets.com. IN TXT "v=spf1 mx include:awesomemailers.com ~all"