Slashdot Mirror
IETF Approves SPF and Sender-ID
NW writes "According to the records in the IETF's database (here and here), both the SPF and Sender-ID anti-spam proposals were tentatively approved by the IESG (the approval board of the IETF) as experimental standards. It remains to be seen whether any of them will actually put a dent into spam." At the same time, the FTC has opened a central site about email authentication.
I dunno, but hasn't this failed with caller ID?
Not at all. If I get a phone call and the CallerID says "unavailable", "out of area" or "private" then I don't even bother to answer it.
If my incoming e-mail doesn't have SPF headers then it bumps up the scores in SpamAssassin. If the score gets too high then the e-mail gets filtered & I never see it.
"Bounce to sender", what a dumbass feature. You (and Incredimail) don't KNOW who the sender is. That option should be "forward this email to some random person who probably has nothing to do with sending spam".
Of course we will never see a central database of mailservers. That has been proposed before, but will always be unsuitable for the Internet. Remember, the Internet is meant to be decentralized. And a centralized database is open to abuse by governments, corporations, and whoever runs it (or provides the funding for it).
There's nothing to stop spammers from infiltrating such a system, via legitimate and illegitmate means. So it just plain won't work.
Between the fact that it is easy to abuse, it just won't work and it won't provide any benefits over existing systems, your system is just a bad idea (no personal offense meant, of course).
Cyric Zndovzny at your service.
What we need, and what will NEVER happen, is a central database of mailservers. If you aren't in the "registry" of legit mailservers, then other mailservers won't accept your mail. To get in the registry, you'd have to pay a fee, and prove that your server are secure, and that you aren't a spammer. Obviously, each "legit" server would have to append some kind of digital signature to outgoing emails, so that the verification coudl take place.
Who would run this registry? Why do you need to pay to get on it (spammers usually generate income and do not mind spending money to further their business while individuals who want to run private/personal webservers would not want to pay money just to be able to send email)? How would you prove that they aren't a spammer when the only email "legit" email servers would receive would be through this registry (thus no trial-runs for the prospective applicant)?
Every post I make begins with the assumption P=~P.
you obiously have no practical experience...
putting up SPF records has not made any noticable difference in the spam abuse from one of my domains.
obviously, spammers do not (yet) check of a domain they use for joejobs has an SPF listing. this means that little or no receivers are bouncing the spam because of SPF.
I'm not going to say you're a moron, but how do you allow for legitimate unsolicited email from people?
Currently I receive lots of unsolicited mails from people that I want to hear from. Let's call these people "customers".
Your scheme would have me polling only people I have already talked to.
John.
I think a protocol change is in order. Instead of sending the message via SMTP, only send a notification that an email is waiting to be picked up, and it's location. When your email is checked, it loads the email from the server.
This has the following benefits:
1. The cost is on the sender. It would be prohibitively expensive to send millions of messages - you'd have to host all the clients!
Huh? You'd still only transfer the same amount of data, it would just become unpredictable how much you would transfer, when.
Plus, you'd be able to tell which of those e-mails were actually being retrieved, therefore you'd get a better form of address verification out of it than is currently available.
Also, it would create problems for people who check their e-mail infrequently (because the originating message might have disappeared).
No thanks, I think the current method is better.
Let's place the blame where it is due. If the recipient's ISPs are rejecting your bosses' mail on the basis of SPF records (as you claim), it means your boss is sending mail through a SMTP server which is not authorized by the SPF records you have published.
Which means your bosses' machines are misconfigured. It's lame to try to lay the blame for that on SPF, which, while imperfect, should never lead to cases like this.
I stopped answering my telephone yesterday. So far nobody has called and complained.
Arrest the fuckers. Throw Scott Richter in jail for a decade or two for fraud and theft. Break the back of the organised crime syndicates that are profiting. Revoke FDIC/CDIC approval for banks who benefit from mortgage spam. Have the CEOs of explicitly supportive ISPs (MCI, for instance) arrested and fined tens of millions of dollars. Threaten economic sanctions against countries who don't take reasonable action.
Like most crime, the laws exist to stop the small criminals, and have no ability to nail the true sources. Technology is always used to try to fix this problem, and always fails.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban