Slashdot Mirror
AOL Tests Sender Permitted From / E-mail Caller ID
securitas writes "ZDNet reports that AOL is testing Sender Permitted From (SPF), 'an antispam filter intended to accurately trace the origin of e-mail messages.' AOL is performing the widescale SPF test with its 33 million subscribers worldwide. The system works by letting recipients use the SPF record to cross-check DNS data associated with AOL's IP addresses and confirm that the message originated from AOL's servers. The system is one of three competing e-mail authentication protocols. The other IP-identifying protocols are the Designated Mailers Protocol (DMP) and Reverse Mail Exchange (RME/RMX). All systems alter the DNS database to let e-mail servers publish the IP addresses that they use to send e-mail."
So what? Microsoft is working on a new secret email technology and they need people to test it. They are paying people for it too! Send this email message to 10 people and receive a check for $50.00 from Microsoft. My friend Tom did it and it really works!
Ruby on Rails Screencast
WTF?
BTW, anyone used any of these schemes yet? Which is the best one so far?
I don't know anyone respectable who uses AOL so I won't ever be able to find out how this works...
Small potatoes make the steak look bigger.
Do we really want the kind of split-down-the-middle stance on formats that we have to deal with when it comes to DVD burning, VHS vs Betamax, anything like that? No, it only ends up being harmful for everyone in the long run.
I'm reminded of what Microsoft did with IE. All these different DOM objects that aren't part of any standard, which no one can really use because it's not browser-compatible.
Using muscle to force the Internet into a standard isn't going to work. We need something that *is* a standard, rather than *pushing* a standard upon people.
When are companies going to learn?
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
I've had trouble with spammers doing small runs with my domain name on AOL. Since I've set up SPF, I haven't had a single bounce from AOL-bound spam. It might just be luck, but as far as I can tell, SPF is helping.
Seriously. Are you people really getting so much spam every day that the "delete" button just doesn't do it for you?
Really, now, junk mail is just not that pressing an issue to me. And I can't see why/how it's such a huge issue for anyone else. So, can someone please give me a few rational replies to this question?
Oh, and to get back on topic, I don't think that anything coming from AOL will work properly - and if it does it's only a matter of time before someone hacks it.
sig not found
Here's a nice way. Before someone can send some mail, he has to get some exponent from mersenne.org which needs double-checking, run the primality test and report the low order 64 bits of the final S_{P-2} value, called a residue. If that value matches the value that mersenne.org expects, then the mail goes through.
Nice deterrent for spam, and as a side-effect one more Mersenne exponent has been double-checked.
For once I might actually approve of something AOL does. OK I didn't RTFA but it sure looks a lot like whitelist filtering. Here's hoping that others pick up on this idea if it works out! (my dialup had 530 spams in the last month... thank you, Bayes!)
C|N>K
I like how AOL has recently been classifying all email from my domain as spam, making it difficult for new users who are expecting their registration confirmation in their mailbox to actually complete their signup on my site. Or to get their important notices that, like, their transactions (with other users - it's an auction site) are completed.
I get a half dozen AOL users complaining that they never get their registration or notification emails every single day. And, of course, I can email them to tell them that it's an AOL problem, because AOL will filter that out, too.
So.. basically. Fuck AOL up the ass.
Anyone want to buy squares on how long 'til it's cracked?
Sheesh, evil *and* a jerk. -- Jade
Sure I'm libertarian like many other nerds, but I can't think of a good reason to fake email. I want my whitelists to work. A technical solution is always better, though.
-I am an elective eunuch.
Now that this is being backed by AOL, a massively-used service, SPF will be pushed into the forefront, hopefully becoming a more universal standard and dealing a major blow against spam.
This may just be what we've been waiting for.
This is not a whitelist filter.
It's not any kind of a filter.
It just means that AOL has published SPF records for its mail servers in their DNS entries. Any mail server speaking SPF, receiving mail from AOL.COM, will check the SPF record.
If the SPF record (which will contain the IP addresses of AOL's mail servers) doesn't match the originating IP address of the mail message (as in, a spoofed header) the message is invalid. Then it can be either dropped or bounced or whatever.
If the SPF record matches the initiating IP address (as in the case of a message legitimately sent by the mail server) it's clear and goes through.
I suspect that as the big commercial guys get more and more aggressive in breaking email standards in the name of combating spam, the internet will split into different incompatible email groups: the old-fashioned types (which include many university departments still) who use a text console and a program like pine or elm, and the AOL/Hotmail/Yahoo crowd. To some extent it's already happening: I can barely read some messages sent from MS Outlook, they're formatted so badly, and as a result I'm less likely to reply to them.
The biggest weakness of this system is that it doesn't protect against some user's system sitting on a broadband DSL/Modem line that has a Trojan Horse used to e-mail the spam. AOL's system probably would only encourage more viruses/worm designed to make computers email relays.
Of course if all non-business accounts were prevented from hosting an SMTP server that would help solve that problem, but I don't think that would go over very well with the Slashdot crowd. I'm not even sure where I stand on that issue.
Ok, I give up, why you?
What will work is a certification that is revolkable. The concept is embodied in public key encryption and certification.
Basically - all we need to do is this. We have a trusted institution like a bank or your local government office issue a digital ID to everyone who wishes to participate... purely voluntary.
Next - those who wish to participate use an email client that refuses to accept anything from anyone who does not have a valid certificate.
Next - we set up a black hole list and the email clients refuse emails from anyone in the blackhole list.
Next - we make this list available to the issuing authorities and if they re-issue we blackhole that authority.
By doing this we create a beuracratic nightmare for our wanna be spammers and everyone else is pretty much free to go on as they have.
I for one will NOT join an opt in list because there are far to many people who have legitimate reasons to contact me. Yet the spammers? well - there are not that many of them... they are really a fringe group actually.
My brother coded this SPF implementation in a day, but then he was using Python.
Everybody should start using SPF. No, it's not the perfect solution. Think Saving Private Ryan. SPF is like the guys in the front of the boat who get gunned down when the doors open. But without them, the other guys (other to-be-developed protocols-or-whatever) wouldn't stand a chance..
Is this truly the only Earth I can live on?
It works well with them for two primary reasons:
1) It is easy to do. You can go to the SPF site and they have a wizard to fill out so you know exactly how to change your DNS, and
2) You can change things over gradually. After you've changed the DNS, you start by aloowing everyone, and then as more people join the system, you implement the protocol slowly.
That last point is particularly good, since the PHB types freak if their email isn't exactly the way that they're used to... and they also freak when implementing new technologies. You can assure them that nothing is changing at first, and that all changes will be made gradually and in steps.
The SPF guys understand that that's necessary, and even have a PHB Executive Summary page.
libertarianswag.com
Don't forget to publish SPF records for your domain if you have the ability to do so. If you have already done so, please register your domain via the validator.
Prevent email address forgery. Publish SPF records for y
Well, I guess I'll just go on being the only person who must not get spam.
And, I reckon I'll not post any more honest questions in a /. forum. Bastids.
sig not found
See: this SlashDot post story
I've seen 0 legitimate emails from AOL since they started, 100% spam. If this technology proves it comes from an AOL server so what? Its just more spam but confirmed to come from AOL.
;(
Big deal
If anyone could force a change to the current email system (unfortunately), it's AOL. If AOL said that beginning 00:00 next Sunday, mail from hosts without valid SPF records would be rejected, major ISPs and corporations would fall immediately into line. Those running their own SMTP servers would either make SPF records or be forced to use their ISP's smarthost.
Call (206) 338-5780 COLLECT for information about a genuine BA, BS, MA, MS, MBA, or Ph.D.
Please forgive me if I completely misunderstand Yahoo!'s proposal, but wouldn't e-mail signing need some sort of public key infrastructure? PGP and other web of trust schemes depend to an extent on key-signing parties, which impose hardships on users who want to communicate with others who live in areas where they don't travel. I would assume that most Slashdot users who have read about Verisign's actions wouldn't want Verisign or any other for-profit "trusted" third party to take control of e-mail.
Um, I thought Bill was going to take care of spam for us?
The _only_ thing I see working that the spam scum will simply never get around is going with whitelisting email address' (much like what Apple's Mail does -- it's not junk if they're in your Address book) -- and authenticating said From: lines with RMX type DNS lookups.
Email!certainly!is!not!what!it!used!to!be
I'd love to bang! a spammer some time -- right up side the head.
The idea behind Internet Mail 2000 is obviously correct. Why waste time on DNS-based approaches when we COULD be developing the Solution?
This presents a problem to those of us who have unreasonably short penises.
Of course if all non-business accounts were prevented from hosting an SMTP server that would help solve that problem, but I don't think that would go over very well with the Slashdot crowd.
As long as ISPs:
I don't see who would have a problem with that.
Why, you ask?
It's sure as hell a lot easier to publish SPF records for major carriers, and then maybe getting that added to the DNS system officially...than to try and go through the absolute hell of writing an entire successor to SMTP, getting the RFC done, and then implementing an entirely new mail protocol on millions of hosts.
If you want something to work in the battle against spam, you've got to keep it simple for everyone to implement.
This actually is the case for my wife and I, who still pay for and use our older dialup ISP's email accounts for both professional and personal reasons, but have been connected to the internet 24/7 via cable for the past few years. We cannot send email out through out email provider's mail server unless we dial in and connect to them directly using one of their dialup lines. Thus, we use the mail server provided by our cable provider to send the mail for us. Of course, if ADSL was available in my building, I would simply subscribe to that via my ISP and it wouldn't be an issue, but it's not... so a system like this would seem to render my wife's and my email accounts unusable.
File under 'M' for 'Manic ranting'
It means that any system administrator can configure their mail transfer agent to bin any spam pretending to come from aol.com with a 100% success rate. And this goes for anyone else publishing an SPF record for your domain.
SPF is a proposed standard for a domain owner to tell mailers where mail From: that domain may originate. The domain owner publishes a DNS TXT record for their domain with (at the simplest) list of IP addresses. Participating mail transfer agents can then look this record up and make a policy decision on whether the mail is likely to be legitimate. The presence of an SPF record on a domain at present means that while you still can't be sure when you're handling spam, you can be sure when you have a piece of non-spam because the SPF record tells you so.
SPF is not a wholly original idea (e.g. up "designated mailer protocol"), and certainly not the simplest implementation but the important factor is that its proponent, Meng Wong, is an excellent lobbyer and spokesperson, as well as someone who as the nous to put forward a useful protocol (he founded pobox.com). It's currently at the point where lots of implementation are being written, with the canonical version being Meng's Perl modules. Currently I'm helping to finish the C implementation which will shortly be integrated into qmail and exim.
The tipping point (I hope) will be when a domain not publishing an SPF record or publishing a globaly permissive one will be considered "obviously" untrustworthy. Combining SPF authorisation with a more traditional "From: domain blacklist" will give spammers a very very hard time indeed forging mail. But AOL publishing a record (we hope) shows the way the wind is blowing: the rest of the world does seem to have to change their mail server configuration to keep mail flowing to AOL.
So go on, it's dead easy, publish a record for your domain now. Tell people where your mail comes from. Look, there's even a wizard to help you.
Question on this whole SPF thing.
I'm interested in it but have a slight issue with it at the moment that
I'd like to get resolved.
My domain is: mydomain.com
Customer A is traveling and is using his e-mail of joe@mydomain.com
However, I do IP filtering on my mail server (not SASL AUTH), for my
dial-up pools.
When Customer A is at hotel he must use their mail server to send mail
out, so his mail will be rejected because the hotel mail server isn't
listed in mydomain.com's SPF txt list.
You suggest running SASL AUTH as a work around for this, however in my
experience this creates MORE of a spam problem then not using SPF..
here's why:
On a mail server with over 40,000 users it's relitively easy for someone
with a password cracker to hammer away at common names like 'joe'
'jeffp', etc and try to get some passwords. Once they have a
username/password combo they can happily send e-mail out as that user
through MY mail server, and I can't do anything about them. Doing IP
filtering requires that they are on MY network to send mail through MY
server, thus allowing me to terminate/prosecute/etc the person.
We've been waiting for an anti-spam standard for years now. What do we have? Nothing.
It's about time someone with clout got up and started making decisions.
I have 4 blocklist on my email server, and still we get a ton of spam everyday. My users hate it, I hate but we have to deal with it whilst the IETF works out their political agenda.
PS. I've also been waiting for the Calendar Access Protocol for a while now. Years, where is it? We're on draft 11 now.
Sometimes design by commitee plain sucks; and we just have to admit that.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Basically - all we need to do is this. We have a trusted institution like a bank or your local government office issue a digital ID to everyone who wishes to participate... purely voluntary.
1) Banks and government as "trusted"? This sounds like a wonderful way for both of them track every e-mail you send with no problem.
2) "Voluntary" will rapidly become mandatory.
No, for e-mail to remain useful and to ensure that those who need it can have privacy it is important that we develop technology that block the spammers while not further infringing on the privacy of users.
Unless of course the preceding message was a troll.
Three Squirrels
Before looking at SPF you may want to read what Claus Assmann, and Wietse Venema have to say on the subject.
If you don't know who these two people are, I seriously hope you're not someone who's making decisions affecting SMTP on the Internet.
The receiving mail server just asks the originating domain DNS for the list of allowable IP addresses for originating mail. Then it verified the e-mail it just received came from one of the allowable IP addresses.
I have yet to RTFA, but how could I implement this into my SMTP server (Postfix)?
The problems with Yahoo's Domainkeys, are as follows:
I think SPF is a far better better proposal for this kind of thing.
SPF support for most open source mail servers can be found at libspf2.
The recipient's MTA will check the sender's SPF record. You can auto-generate all the email accounts you'd like, only the domain name portion of the email address is authenticated in SPF.
In fact that was one of the arguments against SPF, people said that it did not go far enough and actually authenticate users.
Personally, as someone who has to administer an email server and whose domains are sometimes used in forgeries for spam ( last one was a few days ago ), I'm all for SPF.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
AOL has rate limiting implemented server-side. Try to send too many e-mails at one time and your AOL account gets nuked AUTOMATICALLY by a script. If you're getting spam with @aol.com as the origin, it's forged. This is EXACTLY why AOL is implenting SPF - they're probably sick of being associated with spam they are NOT The origin of!
---
DRM is like antifreeze, to the MPAA/RIAA it's sweet, to the consumers it's poison.
Just stop sending them?
Ok, how about all you potential spammers send $6 to my home address:
123 Fake St.
Springfield, Il
12345
United States of America
and U will $ee many monies! No need to spam again!
Sincerely,
Prince Mobutu of the Nigerian Empire.
Someday, I'll have a real sig.
Well then, I guess you're sorry that you clicked the link to see br1tn3y t0ple55 pix!! !!! zvdfvczx
Wealth isn't really money. Wealth is the ability to do what you want when you want where you want. Money helps, but *time* is probably the most fundemental unit of it. Spammers steal that, on a massive scale, and turn it into almost nothing. They steal a lot from a lot of people and turn it into pennies. They're horribly destructive people.
Which is why they should all die horrible screaming deaths before their ashes are mixed into the concrete of a sewage treatment facillity.
If a domain uses SPF, users can now with assurity filter by domainname. That means I can say "if sender_domain==aol.com then [ file under ok ]". You can't do that right now cause anybody can spoof aol.com
If the major players use SPF, then spammers will have to resort to creating their own domains or spoofing non-SPF domains. Hopefully the non-SPF domain admins will eventually get the idea and publish SPF records.
SPF rocks, I wish Yahoo and hotmail would pick it up.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Okay, I've been thinking about this one for a while, but feel free to shoot me down.
When you send someone an email message you initiate a potential financial transaction for a tiny amount of money (say $.5). If the recipient is so inclined they can complete the transaction and "cash in" your $.5. The idea is that people that want to receive email from you will not redeem your offer.
If you send a non-spam email to someone and they decided to be a jerk and cash in then you're only out 5 cents. Of course if you're a spammer and you just sent that email to 200,000 people then you've got a problem.
Obviously this would not be built into SMTP (to preserve compatibility) but would rather be a layer on top that the common email clients would have to handle. There's also some infrastructure details to be worked out like cryptographic method, payment processing (perhaps 1% of the completed transactions go towards the organization handling the payment processing), etc.
I know it just can't be that simple, so why wouldn't idea this work?
Probably because he's a fscking moron who plasters his address all over usenet and the web in mailto's.
Not to mention his system is probably riddled with spyware and worms.
Some of my addresses are older than many of the posters here, and I runs dozens of mailing lists, some more than a decade old.
I get about 5000 spams a day. After filtering I only get about 2-300, which I delete.
Need Mercedes parts ?
I notice that a number of people knocking SPF are looking at it breaking some sort of standard, or that it's an exclusive, it's-the-only-answer technology, ie it's being proposed as a silver bullet.
It's not. SPF just provides one more bit of helpful information -- which IPs email from the sender's domain should really be coming from.
While someone could use SPF in a pure binary decision system that breaks SMTP, it's going to be an incomplete solution. Just like blacklists, whitelists, and bayesian filtering are also incomplete solutions.
However, you start using these things in combination and magic happens.
Example: I use ASSP for server-side spam filtering. ASSP uses bayesian filtering, but also whitelists people you email and uses blacklists.
The blacklist implementation is interesting, however, as when it determines an IP is blacklisted it simply starts off with a higher spam probability in the bayesian stage -- it's not truly blacklisted, just more suspicious.
You could do the same thing with SPF, initially giving a lower spam probability to mailservers with SPF, and when there's more infrastructure using SPF, switching to penalizing non-SPF servers.
Nice thing about this approach: it doesn't require everyone to convert their infrastructure, but it does incentivise legitimate servers to do so without penalty. It doesn't break any standards. Legitimate mail still gets through, but spam suffers.
Stop thinking that all spam solutions have to be single silver bullets. Anti-spam tools can be additive.
One more tool against spam == a good thing.
From this little blurb, I'm not quite sure how this is supposed to work. So the sender's ISP sends a notification to the recipient's ISP that a message is available instead of sending the whole message. How does this combat spam? All I can think of is that it forces the spammers to host their own spam and pay for their own bandwidth, which is, I suppose, a large deterrent.
So now AOL users are SOL if they want to use any of the large number of applications that send mail for you, such as all those "Mail this story to a friend" links, or tools like eVite which manage party invitations for you. And tons of other applications, many of them useful.
You don't want something like SPF until a protocol is established so that if an application needs to send mail for you, it has some way of sending the mail to your browser for it to mail, authenticated by you. At the same time, this is hard because you want it to be secure (not usable against your will) but also easy (not always prompting you.)
But the bad news is that even if SPF were to make it, some planners have a long term goal of demanding it be universal. Ie. to refuse mail that does not come with some form of ID.
Your papers please!
The spam problem is real, but it doesn't affect everybody.
It is easy to deal with using standard smtp protocol, but the larger ISPs don't seem to wish to implement the existing methods (smtp-auth plus block all emails not originating at an IP that matches an mx record. If you want to run your own mail server, you better get a (sub)domain. simple blacklists and filters).
There is a drive to monetize email as well, and the arguments for this usually begin with "smtp is broken".
Whitelists are a social-engineering product, as this then limits the number of people contacting people for the first time by email, and will greatly shrink the communities formed on the internet to people your company does work with, people you have met and exchanged email addresses with, and people on subscribed mailing lists. This slows the flow of ideas, and it makes it more possible to track who is comunicating with who.
Most of the proposed "anti-spam" tech also includes something in the lines of a centralized database, often in the form of your whitelist being maintained on your ISP's server. This allows easy mapping of the social network, which, IMHO, is not necessarily a good thing.
Many people think that changes such as these are necessary to "save the internet" because they've bought into the idea that the internet is somhow under threat by the very people who built it, and they are ignorant of the fact that it is mostly these "internet saving" ideas that threaten the usefulness of the network, and are more intended to make the internet more like other media (centrally controlled, corporately censored) and less of the decentralized (publishing/communiocation/colaboration) forum that it is today.
> I don't see who would have a problem with that.
I run a few private mail domains on my own servers and with my own smtp server, yes, I would have a problem with that.
The SMTP server that you use SMTP AUTH or SMTP after POP does not have to be running on port 25. The SMTP SUBMISSION protocol runs on port 587. ISPs have little reason to block these other ports because you will only be able to connect to a very limited number of SMTP servers and they will usually want some sort of authentication.
SPF support for most open source mail servers can be found at libspf2.
A lot of you know that spammers get your email address using webspiders (similar to the ones web search engines use) to catch email addresses on homepages.
A lot of those are from mailing lists archives. Mailing lists usually take care to remove user email from the header of the messages they archive, but they don't (what maybe would be hard to do) filter the content.
And a lot, maybe most, of mail readers (like outlook from microsoft-sue-spammers) include the email address of the original sender in the message content when replying/fowarding a email address.
So you may take care using your email to avoid spam, but if someone foward your email (with your address included) to some "open archive" mailing list the damage is already done.
So if mail readers (webmail included) didn't (at least by default) automatically post the email of the original sender on the content of every replied/fowarded email the spammers would have much less email addresses on their databases.
Go on, webmail providers, for you it's much easier to update the whole base, and that will save you some bandwidth/disk
Even Dan Bernstien decided that IM2000 was a stupid idea, which is why he never wrote a single line of code.
I've read the article and I can't figure out what the test is. Does this mean that AOL is publishing SPF records (in which case it's old news) or does it mean that AOL is going to start rejecting incoming mail which fails the SPF tests?
This is no solution. It stops the load of sending the bodies of spams, but the annoyance of spams still remains.
It also introduces a lot of problems. Unless you just immediately fetch, it tells the sender where you were (IP address) and when at the time you fetch the mail. If the sender's server is down you may not be able to fetch it at all. Response times get slower, again unless we just use this to implement the old pre-send system, in which case we don't get its benefits.
A mixed system (pre-send small mail, post-fetch large or questionable mail) can have some of the benefits but still faces problems. And spam still comes.
They'd have to either switch ISP's, or no longer be able to receive email from users who didn't implement SPF.
Isn't this a repost???
http://www.spamgourmet.com is a free customizable forwarding service that creates disposable email addresses with a limit. You just create give out addresses of the form something.numberofemails.realuser@spamgourmet.com
Does this person know Long Duck Dong?
The idea behind Internet Mail 2000 [cr.yp.to] is obviously correct. Why waste time on DNS-based approaches when we COULD be developing the Solution?
Because it's not backward compatible.
SPF is a simple and backward compatible solution to email forgeries. People who don't use it are still able to use email, while people who use it are protected against forgeries.
Everyone and their brother are reinvented email theses days without realising that you need to improve the existing email system. It's not possible to throw away the existing system.
Also, under your system there would be several email lists where my 'correct' offlist reply address would never be seen (if I changed my 'From'): they (or I, in some cases) change the 'Reply-To' to the list. So, if I were to change my 'From' based on some idea of 'where I'm sending from', my DStaal@usa.net address would never be seen. So no one could ever reply to me offlist. Or recognize me from another list, or...
'Sensible' is a curse word.
The other change that I've seen from AOL (and some other ISPs) recently is that e-mail from dynamic IPs is being rejected. I understand the reason for this, but it seems a poor criterion for mail rejection; an SPF record should be able to override this, yet this does not seem to be the case.
This is going to affect a number of Linux distros, where the Sendmail configuration assumes that e-mail may be sent directly to remote hosts.
here's a glimpse into the growing popularity of SPF:
SPF Adoption Roll
anyone have any info on quantifiable interest for either DMP or RME/RMX?
So now AOL users are SOL if they want to use any of the large number of applications that send mail for you, such as all those "Mail this story to a friend" links, or tools like eVite which manage party invitations for you. And tons of other applications, many of them useful.
I've got 1 word for you: Sender Rewriting Scheme, well three words.
And how much of a performance hit is this? And does it really matter? Contrary to popular opinion, spam does originate from many, many different sources, not just a large group of megalo-spammers with furry, white, fat cats and their faces in the shadow.
Pelé!
The parent just put the original poster to the test. Not off-topic or flamebait at all!!
But how could you possibly live without email for 10 days? People would think I'm dead. =)
It's called a long deserved vacation.
Please dont propose a solution that takes control from my hands because my computer 'might' be compromised. Trojan horses are wrong but they are not justification to steal control of my computer.
If a trojan would take control of this computer - against my best efforts. My computer IP on the mail would allow someone to inform me that my computer is spewing spam. I can then remove the trojan and find a way to protect it.
LS
Spam is a huge problem lets not turn it into a WMD!
Anyone that can provide us with a link?
Yes, I agree that SPF would help. Still, nits remain to be picked:
If you don't like the way your ISP handles it, complain or switch ISPs, just like you would now.
So do you expect every residential broadband customer to maintain an extra $20/mo dial-up account in addition to a web access account through the local broadband monopoly?
ISPs aren't regulated.
ISPs that control the residential broadband last mile are regulated franchise monopolies. But would complaining to city government about the cable ISP's poor service have any positive effect?
Microsoft is an example of this, its what the people choose, web developers didn't have to take advantage of this if they didn't like it. Average users found it acceptible so they went with the developers.
If a company creates a standard and no one uses it then the company is spinning it's wheels and the company standard will die eventually.
Sometimes it takes some steping back from your preferences and stubberness to see what the people have choosen.
Crashoverride025
Surf the faster and more efficiently with 4
Damnit people, come up with some original acronyms please! SPF is already taken! :)
SPF == Shortest Path First, as in OSPF (Open Shortest Path First)
Damn you AOL, damn you yet again!
I have no signature
I don't understand... why can't all email servers just check forward/reverse MX record lookups to help deminish spam. I know that will not end it, but it would drastically help from spoofing email... which is all that AOL's initiative seems to be doing (i.e. not killing it, just preventing their servers from being spoofed).
Oh, yeah, and have the email servers not accepting relays, and patch the damn home user windows boxes. Instead of AOL blocking ADSL, they just need to block windows '95-ME, 2000 pro, and XP. They are all home systems, not servers. Network packets can show OS footprints, so this is doable.
Just more media hype, I'll beleive it when I see it. AOL just has to rebutt microsoft (MSN) from stealing more AOL users with their latest news about anti-spam pledge from Gate's.
[Now that i cannot even do it] I wasn't sure if i should have moderated that Funny or Flamebait/Troll .... shoulda flipped a coin
If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
Because his solution has flaws which he continues to ignore and nobody is interested in implementing it.
So... you're saying that it's okay for domain forging to continue just so that people can still e-mail party invitations, putting any old from address on it that they want?
It's pretty simple math - if domain forging is possible and undetecable, then spammers will continue to forge domains.
Something has to change, and as a mail admin - I want control over who is allowed to send e-mail purporting to be an agent of my company. That means domain forging has to be stopped or placed under my control to either allow or disallow. E-Mail is pretty much already badly broken, breaking a greeting card site (who has other options like SRS, or even sending using their *own* domain name), is a minor additional loss.
Wolde you bothe eate your cake, and have your cake?
Ha! This gives spammers exactly what they want. They will know which addresses are "Real" because those users will be _forced_ to connect to the spammer's mail server. Also note that the user's computer will be unable to filter the spam without downloading it... so nothing is solved but everything has to be rewritten.
Also, this will kill the ability migrate your mail to different addresses and will make the accessability of your email depend on _all_ the servers sending you messages being up and accessible at the same time.
For some reason, people tend to read the message that recent nslookup spits out and glaze over once it gets to suggesting dig. Dig is really only useful for diagnostics -- for day to day use, the second replacement program nslookup suggests, host, is much prettier and simpler.
Using dig spits out about a page of info for aol; `host -t txt aol.com` just gives back a nice one-line response containing only the information asked for.
AOL Whitelisting Guidelines
Jump through the hoops, because as the spam problem gets worse more and more large domains are going to implement whitelist procedures. SPF might mitigate that a bit, so instead of talking to all of the large ISPs and telling them what your e-mail servers are, you can just publish a SPF record.
Wolde you bothe eate your cake, and have your cake?
Gates plans an end to spam in two years
Not true.
AOL's SPF records 'whitelist' their own servers whilst saying nothing about the rest of the net.
This means that mail sent from @aol.com addresses via AOL's servers can be treated as authentic by spam filters, whilst any mail sent by other means is treated exactly the same as before (ie maybe forged, maybe not).
Nobody wants spam. (Well, except spammers.) So just because you are not for one method of anti-spam doesn't mean you want spam to continue.
There are many features of our E-mail system that were deliberate and which spammers abuse. Before we give them up to stop the abuse, we want to be very sure there isn't another way.
if your solution involves invading my pocketbook or my privacy, it's not a solution at all.
I simply filter based on links that e-mails contain and I get virtually no spam. And new spam domains that manage to get through are quickly added to the rule file.
The header doesn't matter. Who sent it doesn't matter. Nobody gets any bounces. The server just eats it.
Write up and souce/binaries to automate yanking out links for consideration for filtering.
"so why wouldn't idea this work?"
Because it's a shitty idea. E-mail is free. Deal with it. If you want to have some moronic pay to send system feel free to set it up and watch as no one in their right mind uses it.
SMTP is so easy and open that it's not going away. If asshats like yourself want to set up a fee based e-mail system. That's fine. My SMTP server will remain under the current free system. If the rest of the internet switches to something incompatible and retarded, I guess I'll just have to start handing out accounts to people so they can circumvent the idiocy. It's not challenging at all to run multiple mail servers if needed.
The problem of SPAM is not worth sacrificing free and privacy over as some nerds have decided.
Ben
Work Safe Porn
I've been using the same two e-mail addresses (from mail.com) for over six years, through several ISP changes.
My outgoing e-mail originates from my ISP's servers, not my mail.com address, so would show as "non-validated" using such a simple-minded and poorly thought out system as this.
Yes, we need a "fix" for the SPAM problem and the MS virus/worm/trojan-of-the-day problem in our e-mails. but this is NOT it.
Sorry. Try again.
-= This post made from a Microsoft Free Zone =-
Are you saying that every port 25 listener is supposed to check incoming IP addresses against the SPF list for the domain in the envelope-From? That means that you're not to relay through anything not in the SPF list? If you can relay, the relay can just forge the appropriate Received: headers. If you can't relay, then, hmm, your flexibility is impaired but maybe that's the idea.
Spam is subject to natural selection, so by looking at what makes it past today's filters we're looking at nearly 100% of tomorrow's spam.
Very little of the spam that makes it past my filters even bothers to spoof aol/hotmail/yahoo/etc anymore. Since it tends to be very crafty spam, this isn't really surprising, since spam doesn't really *need* to spoof any headers. You could have 99.999% of the world's domains be registered to legitimate entities AND implementing SPF, and the last 0.001% be registered to spammers, and either not implementing SPF, or implementing it with rules that let the spam through. If you have little or no control over domain registration, and you want the ability to receive mail from domains you haven't whitelisted beforehand, the most SPF can do is turn pen1s3nl4rg3m3nt@aol.com into sales@pen1s3nl4rg3m3nt.nu. It helps against bounces and the likes, but little else.
If I use dyndns.org for a dynamic domain pointing to my cable modem, is there a way I can have them put the right stuff in my DNS text field ?
Implement automatic account deactivation and some kid will code a script to brute-deactivate your users. You only have to know or guess a login name (that 99% of the time will be like the email address) to cut someone the ability to use email...
You're real smart aren't you?
There are many features of our E-mail system that were deliberate and which spammers abuse. Before we give them up to stop the abuse, we want to be very sure there isn't another way.
We've had 10 years worth of abuse to figure out a solution. It's about time someone stepped up to the plate and just tried one. If people generally aren't satisfied with it, it will get removed and replaced by something better.
You need to realise that there will never be 100% agreement on a solution.
Maybe I don't know SPF, but I think there is a critical flaw in their implementation. As I understand it, the 'ptr' mechanism allows (ie labels a message as 'acceptable') a message to come through if the PTR record of the IP address for the sending server matches.
If a spammer has her own class C, or at least something that she can publish her own PTR (or 'reverse lookup' records), she can label her own IP address as 'chinanet.mx.aol.com' or even just 'mx.aol.com'. My incoming SMTP server checks the SPF record for AOL, sees that if the IP address resolves to 'mx.aol.com', and accepts it as coming from AOL. I think the 'a' mechanism is much more spoof-proof.
Please correct me if I am wrong, I may be reading the docs incorrectly.
Don't call 'em chicks. Bitches hate that.
What exactly will be in the notification? Let's say you don't know luser5637883@aol.com, so they could be either someone sending you a valid email or a spammer.
"luser5637883@aol.com has sent you a message. Click _here_ to receive it"
No indication at all of what the message is. You're going to click on it out of curiosity, unless you ignore it totally in which case you're effectively implementing whitelist-only email.
"luser5637883@aol.com has sent you a message ('GET YOUR PEN91S ENLRAGED'). Click _here_ to receive it"
Well, damage done, as far as I can see. I don't want to even see this stuff. Sure, I can tell that this is spam, but what if the hint text were "Account overdue", or "Virus alert from Symantec"? Again you're back to clicking on it out of curiosity.
It's the first sign of a serious attempt to slow down SPAM, so every responsible Slashdotter should be onto this.
First of all, domains are cheap, and a spammer can definitely get one and enable his SMTP server. You will have to subscribe to some blacklisting service in order to recognize his mailings as spam. These services are mostly not free, and they mostly don't work reliably, and they are often seen as a solution that is worse than the problem...
Secondly, SPF does not stop spam that is sent through rooted boxes or stolen accounts.
Besides, I have some domains and I use Dotster's DNS services, but Dotster does not allow me to create TXT records... That may change, though.
In any case, SPF looks like a kludge, probably because it is a kludge. Is it useful? Probably. I have only one SMTP server that is supposed to receive and send my mail, and once I configure it, things should work. But practically speaking, this change requires a lot of work - the whole world has to [re]configure their DNS records and to replace their SMTP software with something newer that supports SPF (I use Postfix.)
Myself, I would prefer the "sender pays" scheme, where you can easily exercise your option to charge the sender if you want. However there are many practical limitations, such as the need to have a world-wide and free email escrow service - or some way to get your $0.05 from some dude hiding behind a throwaway IP address in some faraway country...
One intermediate option would be to demand mandatory GPG encryption for all incoming email, and make the recipient's public keys available for only non-automated retrieval (such as using fuzzy images as access passwords.) If this won't stop spam, at least we will make major progress in image recognition :-) Of course, if you keep your public key available to your normal circle of senders then no spammer will ever be able to send you anything. Also you can have several keys, and make some of them public; these will be accepted, but treated as likely spam (and you can go through them once a week or so.)
But generally speaking, if you make your email address (or the key) available to everyone (with more or less difficulty to obtain) then you can be spammed.
The only way to prevent this is to force the sender to pay. As long as sending remains free, spammers will be sending. You either make it impossible to send (which you can't do if you want mail from unknown people - most users are like that) or you make it financially unrewarding. Either way will do. Anything less than that will not work.
So this SPF proposal is a technical hack that tries to make it more difficult to send some forms of spam. I don't think it will really make any dent in the spam stream. It will only take lots of time (and money) to implement, and spammers will be simply using their shiny new domains from the same faraway countries, or hacking into Mom & Pop's unpatched WinXP boxes that sit on cable. I think AOL implemented SPF only as a specific measure to shield itself from spamming accusations; it has little to do with stopping spam in general.
SPF won't work as a forgery prevention system.
.sig
SPF identifies servers that are "proper" senders for a domain.
If you get an email that claims to be from a domain, and it's sent from one of those servers,
then you can be very confident that the email was actually from that domain.
But if you get an email and it's not from one of those servers,
you can't really be sure it's bogus.
It's like comparing the return address on an envelope with the postmark.
If Alice lives in Anchorage, when you get a letter with her return address postmarked Anchorage,
it's a reasonable bet it's really from Alice.
But if you get a letter with Alice's return address that's postmarked Hawii,
would you conclude that the letter was a forgery?
You might conclude that SPF would at least reduce the number of false positives,
but that assumes that we don't implement something better.
Digital signatures, for example.
-- this is not a
All known froms can come in quickly, live VISAs etc..
If its unknown, then go 'HEY' lets check your passport, if its invalid, or that your have a fake from record/trace/ip.
Then all the unknown sources, or domains, scruitinize the content hard, so if its says viagra, just deny passthru.
2. All these damn ISPs should force customers to run a 'check for security' app or port scan/test if customers dialup/adsl boxes are crap/infested or insecure, and email them they must patch their systems they use as its part of the TOC. If they dont, their account gets suspended. This would help if AOL / Other ISPs, sent out CDs with ALL of MS's patches in one go, rather than 'windows update' stuff which can take forever on a modem, and customers dont want to waste their time/hours $$$$$ downloading updates, perhaps the ISP can detect if they are doing that and make that time FREE.
Liberty freedom are no1, not dicks in suits.
It would give a foolproof way to authenticate a spammer making very easy to publish accurate blacklists.
And if they try to to use throwaway digital identities thankfully generating a key is computationaly expensive so it would greatly reduce the rate at which they send spam...
I really don't think this is going to go very far - primarily because it seems to me that a spammer from say bigisp.com can say he is ANY OTHER CUSTOMER from bigisp.com.
Suppose we have joesixpack as an example - and he has a laptop. At home he connects via his ISP and sends an email to his mom. The letter is received because the from address is valid in his ISP's SPF list. Then he goes to work and tries to send her another email. This time the email will get rejected. So he tries to send it through his ISP's mail server. Since he is not connected to his ISP's system, the email is rejected.
This means that joesixpack has to somehow LOG IN to a server and go through an authentication.
-------
This sort of comes to the nub of the problem. Authentication. If Joesixpack is a good guy - he should be able to send email to anyone - and if he is not a good guy we will find out fairly quicky and we can fine him or pull his priviliges.
The issue is not much different than driving a car actually. It needs to be dealt with in the same way as traffic infractions... perhaps through the police.
One way to implement something that will work is via issuing a certifiation. At the time joesixpack signs up with his ISP - the ISP could act as a CA and certify him as a good guy. They can record his identiy just as they recorded that he paid his bill. At this time they could install a cert for JoeSixpack into his email client - AND - bond it to his machine. There are many ways to bond it - including using a dongle or smartcard. But a practical way would simply bond it to the hard drive. I'm sure ways can be invented so that certs cannot be simply pulled from one machine and stuck into another.
If Joe later abuses his cert - then his ISP can blacklist it and refuse to issue another. Also - the ISP's can trade blacklist information just as banks and businesses trade credit information.
The mail clients can be modified to send the cert and the MTA's could check for and eventually reject any unsigned mail.
As for the ISP's being a trusted CA? Well - we have to trust some people somewhere. The question would really boil down to which ISP's trust which other ISP's and they could cooperatively run their own blacklist.
With a system like this - I would think that an ISP that is shady would find their email services would be in jeopardy of being refused and that should serve to keep the ISP's in line to.
------------
I also think the spamd solution in OpenBSD has a lot of merit. Spamd does not block email. Instead - if the sender is blacklisted - spamd accepts it very very slowly. This creates an incentive for the owner of the mail server sending out the spam to deal with it. With spamd in wide spread usage the problem comes under control in a number of ways.
(1) suzy spammer will find if she runs a spam server that it can't spew very fast - because her IP address and/or domain will end up in the RBL rather quickly and the moment this happens. Receiving MTA's slow to a crawl.
(2) If Suzy spammer tries to send through her ISP's account - the same thing happens but now the ISP has to deal with the problem. No ISP's will want to have a significant number of their IP addresses in an RBL. Since this will pose a significant admin problem - the ISP has a huge incentive to give Suzy spammer the boot.
(3) We have some bad ISP's and these people will find their errant ways are causing themselves grief.
(4) It might encourage ISP's to actually issue static IP's which many of us want anyways. Note we would NOT have nearly the spam problem if static IP addresses were issued.
Excellent point. I run an outgoing MTA on my home LAN because my ISPs SMTP server is not consistently reliable and does not warn senders about queued messages until they bounce after 48 hours. I get very annoyed with admins who use these blacklists of all dynamic IP addresses and with the arrogant people who say broadband users should not route their own mail directly but use their ISP's server. Maybe they live on some planet where a number of ISPs compete for their business by providing excellent service, but here in the real world I have one choice for broadband and it does not provide a very good SMTP service.
People assume IM2000 would stop spam because:
1] You don't get a message unless you want to retrieve it
2] The sender has to store the mail not the receiver, so the sender has to pay to store a bajillion messages
This doesn't work because:
1] By seeing the notification, you're already annoyed and have wasted your time.
2] The sender need only store ONE copy of the mail on a customised MTA, not millions - so as long as he has a custom server, he can still spam and use only a few hundre kb of disk space per message type.
3] Retrieval of email would become extremely slow for anyone with large attachments or similar. Connectivity problems would be noticeable to the end user
1. Please if you have moderator points mod this up. /. has replied I'll post the new ANTI-SPAM method. I just want to make sure that everyone knows about it, because once it is posted there is no going back to plain old SPAM ladden email.
2. Everyone please post a reply to this post, on or off topic it doesn't matter.
3. Once everyone on
Remember post early and if you want often.
I don't see that this is much different from using DNS as a suppliment to the SMTP VRFY protocol.
VRFY simply asks the SMTP server if the arguement is a valid email account for that server. This has been historically used to exploit addresses from this server for email spoofing by spammers. Being able to prevent someone to use this same kind of reverse lookup procedure to block email seems redundant.
I would think that if everyone supported the existing VRFY command and every mail server did a reverse VRFY to validate the email account, you would be MUCH better off. Consider this process:
Maybe I'm missing something, but how can that not be just as effective as what they are offering today? However, I would consider it to be much easier to use because now one server (SMTP) manages all the information regarding email, rather than publishing it into the DNS records and yet another server. This is starting to sound like FTP's data/control channels.
It won't stop spam. But it will guarantee a level of traceability that we don't have today.
And it won't require someone to constantly update/modify the DNS record system every time you create a new user account
AOL has a Postmaster site at http://postmaster.info.aol.com
From what I've read, albeit briefly, this seems to be a process in which email being sent is validated against DNS entries for what mail servers can send email for my address.
Seems like a variation of the VRFY command in SMTP.
Except now I have to keep DNS records in sync with my SMTP records.
Generally having the same information kept in two places is a complication that people try to avoid.
I was considering if you used the SMTP VRFY you might be able to accomplish must/all of the objectives provided by SPF et al without the need to managing two seperate sources of information or two protocols.
Something like this:
Once the information from the Envelope is received, this information is sent back to mydomain1.com (after validating reverse DNS lookup to match mydomain1.com as a MX record for mydomain.com) asking to VRFY joe_user@mydomain.com. Response from this inquiry determines the delivery of the email.
mydomain1.com must be the lowest numbered MX record in the mail delivery system to ensure that relays are not required to manage a complete list of users.
I realize that in the past VRFY has been used to exploit deliverable spam addresses, but I think that's pretty moot considering I routinely see massive dictionary attacks against my mail servers in search of any names it can match.
But you now ask for the same level of open information from your senders. I think this won't do anything less to block spam than SPF or other domain records, it simply ensures that the addresses being used by the sender are valid.
The advantage I see here is that there is no change to existing technology and might be implimented much easier by providing a single point of information for email addresses.
Instead of sending from:users_email@isp.net , they can send from:robot@the-actual-site.com, subject has recommended this page, or whatever.
I've got half a dozen public addresses, I get about 100 legitimate and just 2 or 3 spams in a day. My ISP uses Maia (sp?) spam filter. I go into the quarantine once a week, they're always crap, and clickformail.com was blacklisted, so nothing gets through.
WTF are you doing, using MSN and AOL for email?
...and it's called a 'white list'. Seriously, this would work perfectly well for 99% of the folks out there. Most people only exchange email with those they already know, or with those they've specifically given their email address to (e.g., through PMs via forums they frequent, or - gasp! - in person). White lists would work perfectly well for them, if the white list were configured in such a way that adding or removing an accepted address via their email client was a simple process.
Combine this with existing Bayesian filters for sites which need to accept all incoming email and you'd cut the amount of spam actually reaching a target to tiny levels. The point wouldn't be to stop spam altogether (a silly goal), but to reduce the number of 'live hits' to the point where spamming is no longer profitable. Once spam isn't profitable anymore it'd die like any other failed business model.
Max
My god carries a hammer. Your god died nailed to a tree. Any questions?
People through FUD around to mean any sort of bullshit, but, yours is the first real, bona fide FUD in a while :)
The problem with people of your ilk is that you don't understand the difference between an envelope from and a header from.
SPF works on the envelope from (you know, as transmitted by the MTA, often using MAIL FROM if we're talking SMTP), not the thing that's listed in the "From:" header of the message.
When a message is forwarded by a mailing list (or by your MUA), the From: header may belong to someone else but the envelope from is yours... and, of course, that's what's checked against SPF.
In other words, the list's SPF records will be checked against the list's domains, not your records against your domains.
Using pre-canned prime numbers and making key using combination of them can be quite fast. But at least the actual signing of the message is expensive. But if does not help much if it is sent a million times...
On the other hand using professional certificate authorities may not be needed, if a key is not somehow trusted, like not linked to the PGP core of intertrusting keys if could rise a likely spam flag...
Somehow I hate the concept of fatcats like Verisign being part of the solution against spam...
I've been using a single email address for almost 10 years. I've had 7 or 8 ISPs in that time and I've used this address with all of them. In fact, I've never used many of the email addresses that came with the Internet service I've purchased. I currently use this email address with T-Mobile on my Sidekick, with Optimum Online when sending from home and with whatever tier 2 providers my place of business has used for their multiple T-1s.
If SPF takes off, it looks like I'm going to have to switch to an email address on a domain I own just so that I can code an SPF record that will allow me to do exactly what I've been doing since late 1994 -- sending email from various devices. With luck, I'll be able to automate the process of adding a new SMTP server for when I stay in a hotel and use their IP services.
I hardly call this a step forward.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
This is the big problem.
Solutions from the UNIX world are implemented, and then it can never be changed again. Supporters point to RFC's from the 80s and say 'it works as specified, so there cannot be a problem'.
Seriously, it's time to phase out SMTP. It has caused a lot of problems for the last 15 years, not only buffer overruns in sendmail compromising root, but the whole protocol is flawed. It has also been extended with too many extensions (like EHLO).
The internet has grown, from an environment with mature peers and trustworthy colleagues it has become an underground free-for-all hostile environment. The way SMTP accepts mail and trusts on your good faith to provide a correct From: is not feasible anymore.
Receiving mail can be done with IMAP/POP3. Sending mail should be switched over to a new protocol that authenticates the sender with username/password, just like NNTP can do. Then the From: line has to match one of the stored addresses in its database. Clients can modify their list of addresses through a secure webpage, allowing the server to connect throwaway accounts to the user.
Then only listed clients can send mail through that server. Server to server relies on public key authentication.
There can be a 2-year transition period for everyone to update their software, after that SMTP should be gone.
If you're going to "out" someone by posting their email address for spammers to harvest, you ought to post your own email address at the same time so you can both "share the love" with all that lovely spam. (And yes, my real email address is deven@ties.org -- I never hide my email address as a matter of policy, even on Slashdot...)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
As soon as your find a Solution, let us know - DJB's idea is just, well, dumb.
Here's why. I run quite a few mailing lists for various projects of mine and a few local non-profit organizations. As it stands, whenever I need to broadcast a message, I feed it to my outbound mailserver, which queues up the message and transmits it as efficiently as possible (multiple recipients at example.com? Send them in a single batch!) given the constraints of my local resources.
If everyone migrated to DJB's toy system, whenever the notifications went out that there's a new mailing list message, everyone gets to nail my server whenever they want, regardless of whether I can currently handle the load.
Put another way, if I have a slow outbound pipe, and I want to send 4,000 emails, then my SMTP server can spool those out over the course of hours (or days, if need be). In DJB's system, I have 4,000 irate users as they all try to fetch their individual copies (no destination-combining) from my system at the same time.
Tell me again what part of that seems attractive to server admins? DJB is the King of Unintended Consequences. He has some interesting ideas ("Who needs IXFR?"), but he never seems to think them through to their logical conclusions.
Dewey, what part of this looks like authorities should be involved?
Thats a LOT of spam man. You might be one of the random email address I (and people like me) make up to put in the detailed forms that almost EVERY worthwhile site makes you fill out. Yet the pain it causes others whose email addresses I use (mostly whoever has stone@aol.com- I've been using that one for years as a fake email. I actually feel sorry for that person) prevents my email address from getting too much spam. Its a dog eat dog internet out there man. Maybe you should stop filling in all those forms with YOUR real email address. Or get a better spam blocker.
Open Source Sushi
SPF == Sun Protection Factor?
That would be matrophe@sdf.lonestar.org ?
You're welcome.