Slashdot Mirror
AOL Now Publishing SPF Records
SPF Fan writes "It looks like SPF is starting to catch on with the bigger ISPs. AOL is now publishing SPF records which you can verify with 'dig aol.com txt'. Will Hotmail and Yahoo be far behind? Who else is publishing SPF records for their domains? Slashdot has covered SPF in the past a couple times."
SPF isn't gonna achieve anything
Good, now my skin won't burn as much!
How does AOL know my SPF and why do they want other people to have access to it? Are they that concered at the prospect of me getting a sunburn?
test
Don't assume we all know what "SPF" is. Unless you mean "Sun Protection Factor", you are leaving the /. readers to wonder.
Please, if discussing a topic that is not widely known, put a short description or definition in the article writeup.
Thanks.
I have been pwned because my
Okay, I am not trolling here, I'm serious. This plan will be moderately successful at preventing joe-jobs [catb.org] on unwitting victims. If you control the DNS for a domain, you can say who is allowed to send mail for that domain. Therefore, if a spammer attempts uses your domain in the "From:" header then it will only be delivered to those hosts that are NOT checking the SPF records. That's an important distinction, because getting everybody on the planet to do something is very hard, so this will never completely wipe out the possibility of joe-jobs. And there are the possible negative effects here, for example employees not being able to send company email while on the road without hassle.
But that aside, how does it reduce spam? The spammers will always be able to find a domain to stick in the "From:" header. They can choose to use a domain that they do not control that has not yet added SPF to their DNS or they can choose to use a domain that they control. In either case it's trivial for them to get their mail from their system to yours, and that's all that they really care about anyway -- the "From:" header has always been meaningless to spammers anyway, it's not like they would be forfeiting the ability to receive replies or something.
Note that in the case of using a domain that they don't control, we're back to the issue of "until everyone on the planet does this, there will always be some domain somewhere that can be forged." And even should those run out, spammers can just register anything for $7 a year, or less for bulk registrations. (They already do this when they're playing hosting tricks, to bounce you around from one host to another.)
Now, you might say that at least with this implemented you could discover what those domains are that the spammer is registering for use with his spamming. That is true. But, we've had the concept of a blocklist for ages, that's nothing new. Everyone has ranges of IP addresses that they won't accept mail from, and some very kind organizations have even maintained lists of "bad IP addresses", so you might expect a similar thing to happen with domain names. But all you have to do is look at the current state of blocklists and you'll know this doesn't buy you much. We already have blocklists, and they're riddled with problems. You're back to playing whack-a-mole with the spammers. They make a spam run with example.com, you block example.com; they make another run with example.org, you block example.org. You're always one step behind, while the spam piles up in your inbox. You might make the point that this inconveniences them, but you have to realize how many domains there are out there that are available for forging. The SPF-protected domains will be the vast minority of all domains for the forseeable future.
So, in summary: This might be moderately effective at preventing joe-jobs. It will not make a significant change, however, until everyone on the face of the earth that's not a spammer both updates their DNS and updates their MTA software to check these records. The likelyhood of this happening any time soon is quite small. And even if this were to happen, the spammers would still be able to deliver piles and piles of garbage to your inbox though domains that they control. You're back to blocklisting, which we've had for quite some time now.
So, I ask seriously, what does this do to combat spam that is really all that significant? I applaud any developments on the antispam frontier, but let's not get too carried away with visions of this somehow "plugging the insecure SMTP hole", or anything remotely resembling it.
But Aquaman, you cannot marry a woman without gills, you're from two different worlds...
[AOL]
Me Too!
[/AOL]
I've been publishing SPF records for the cavebear.com domain for about two months now.
I've only done the publishing side, I have not yet enabled my mail servers to use them.
Even though SPF may not be a complete or perfect solution, I see no harm in announcing to the world that if it purports to come from my domain than it also comes from my designated mail servers.
...thats 9 class c networks only for sending spa^H^H^Hmail
I think it's fantastic that major ISPs are taking proactive steps to curb junk email from their users. SPF seems like a great system because it introduces accountablity though simple server software, not some crazy, e-comerce based postage-stamp solution.
Some interesting info in their blog
I wonder if djbdns can use SPF records.
Have fun!
holepit
I only learned about SPF recently, but ever since I've been publishing SPF records for my domain.
It appears to be one of these "why didn't I think of that?" solutions that go and take care of a problem without ripping out everything around it.
Assorted stuff I do sometimes: Lemuria.org
I've always thought that ISPs should add a default "smtp" zone for their customers that resolves to their mail server. That way, you can set your progarm up to use "smtp" and no matter where you are, it will resolve properly.
... an unknown amount of time?"
Now, as far as blocking port 25, I've always thought that was a great idea as well, until last week. Our office has used BellZinc's DSL for connectivity. A few months ago, our smtp suddenly stopped working, and after calling tech support, they told me they had accidentally left port 25 on one of their racks unblocked (and I happened to be on that rack) so they had fixed the situation. (Actually, I had to call twice to find that out, the first guy had no clue whatsoever).
So I switched the smtp server in the office to resolve to Bell's, and all was good. But we've had a few interruptions, espessially over the last couple weeks, where we couldn't send mail at all. After talking to tech, it turns out their mail server is being hammered by whatever virus-of-the-week was hitting windows, and was unusable. I was blown away by their lack of willing to help me: they wouldn't unblock port 25 for me (even to one specific IP), and they has no answers to "Well, what am I supposted to tell everyone in the office? No email for
Of course, I could have just set up my server to accept mail on another port, but that would have been a pain for me - local change on every client, instead of one SMTP fix. Anyways, as of Monday, we have a new ISP. (I won't get into how Bell tried to tell us we had a 1-year contract and wanted to charge us 4 extra months for breaking. They couldn't send us any proof, but apparently it was a "verbal" contract. Wow.)
Anyways, I'm a little mixed on blocking port 25. I don't know what a better solution would be. Perhaps not allowing a computer running Windows to directly connect to the internet. Or maybe monitoring the email sent, and setting either a limit on the number per day, or just watching for patterns of mass mailings.
For more info, see here
doctor! this is worker speaking!
[no shoes doctor]
That's good news!
Anyone can develop standards, but still it's the ISPs that can make it or break it. Big ISPs can push some standard, and force the whole internet to use SPF or be cut off.
.sig: No such file or directory
Nerds don't go out into the sun.
Ben
Work Safe Porn
For instance, the box on which I get all my mail, to which all my mailing list subscriptions go, and which is associated with my online identity everywhere I have one...is located halfway across the continent from me. It's neither my home Linux box, nor my local ISP. I keep it that way because I never know if I might need to change ISPs for some reasons, and that box is always up and always there. I use fetchmail to pull down my email.
But as a matter of course, I have mutt configured on my desktop box to send in the name of my halfway-across-the-country account, even though it sends through my ISP's SMTP server. (It used to send through my home Linux box's own SMTP server, but then a lot of addresses started bouncing it because it was on a list of cablemodem IPs.) How would I be able to continue doing this under such a system?
For more info, see here
Hello master.
sid=92139
formkey=Q80laL8Oei
This is a joint venture that will be mutually advantageous to both parties involved.
I would advise you to read before you write.
SPF was invented especially to cater for your situation. The quick way out would have been to use MX records as the only validation, but this was not done.
How many more ISPs/mailservers will set this up? Only once it gets to a large level will it be useful, and even then what of when complete domains are forged?
OK I'm instantly cynical with any new technology. I can see SPF working well once it's widespread, but it's not a cure-all, just one step in the right direction.
Now to get all the mailers that accept mail to listen to what an SPF has to say.
Are there any reasons a mail application would purposely NOT want to read an SPF, that could undermine the process?
mac desktops, dare to be nude
You wouldn't. But that is part of the problem as legitimate uses can't be differentiated from SPAM when taking this approach.
Its one of those great "lose liberty in the name of enforcement" style things.
Or of course you could just set up SMTP on that remote server of yours.
An Eye for an Eye will make the whole world blind - Gandhi
We have dig for Windows too, no need for the holier-than-thou attitude.
Now I wonder if my ISP will now remove the SMTP port 25 block on my ADSL line so that my dynDNS can work without having to use the DynDNS port redirection ?
This just screws the people on dynamic IPs even more than we were before. I guess I'll have to keep paying a monthly fee just so I can have a smarthost to tunnel my mail through, since even more mail servers are going to think I'm a spammer now.
I wonder if djbdns can use SPF records.
From what I can see of SPF, it's just a matter of setting up the TXT record in DNS.
rbldns does it in djbdns.
Je ne parle pas francais.
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.
Matthew @ Bytemark Hosting
So you add the IP or IP range of your home Linux box to the SPF record for the domain you use for the colocated box you have. Problem solved.
My personal favorite ...
Sam Spade
-rick
As I don't think this will stop spam (at least not before massive adoption, as others said), I think it can protect us from having a spammer using our email address as From:.
I publish SPF records for my small domain now, and next time some dumb ISP complains getting spam "from me", I'll be able to tell them to go and check my SPF records, and to match these with "my" spam's headers.
Of course, this is for my little domain with few users, all well-educated enough to use authenticated SMTPS to my server.
blah
I read the page but it's too early in the morning for me. Would someone please explain the idea behind SPF _understandably_?
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
But does this perhaps also help prevent identity theft? For instance, if your ISP does not publish SPF records, spammers may use/happen to generate your email address, causing the world to think that you're sending out millions of spam emails.
Of course, this relies on the reciepents' ISPs checking SPF records too, but assuming this becomes more common (though by no means everywhere), this would already reduce the severity of the problem.
/MC
Some people seem to be missing the point of spf. SPF is a mechanism that allows people to publish their own records to defend themselves against joe-jobbing. Anyone who has been joe-jobbed will be all over something like this. The fact that publishing these records benefits you directly, will help something like this spread in a timely manner.
It's also beneficial in the regard that when rolled out to where it becomes standard, mail will be far more accountable, and as spammers start joe-jobbing those people who have not yet published these records, it will only help motivate those hold-outs to get on the bandwagon and defend themselves.
It reduces spam because spamfilters like spamassassin etc. can add extra points to those e-mails that did not verify against SPF records.
If Red Hat adds SPF verification to their default spamassassin configuration files, a lot of companies will start to add SPF records to their DNS.
If I send an e-mail to a RoadRunner mailbox, it is rejected. Why? Because my mailserver is a Linux box on my ADSL internet connection, and RoadRunner blocks all e-mails from residential IP ranges. With SPF, such filtering can be made much more careful, making it possible for me to send e-mails to RoadRunner customers again.
If you pay for a business line, ports don't get blocked. I have my server colocated at one ISP which means no port blocking and a home connection that blocks outgoing port 25. So, I have RinetD running on my coloed server that redirects an alternate port to port 25 so that I can send e-mails from home without going through my home ISP.
Blocking port 25 on dynamic IPs is perfectly reasonable. If you're running a legitimate mail server you can easily get to it without making your ISP that blocks port 25 liable for spam should you be so inclined to send it.
However, if you're paying for a static IP then it's no longer reasonable to block ports.
This SPF solution sounds reasonable. Although it's going to create a market for "rogue" servers that value privacy and allow their domain to be forged.
I think it's more for ISPs than casual mail server runners. It's been years since anyone took the sending domain seriously. For domains that choose not to threaten the ability to be anonymous on e-mail it should be part of the RFC that if a domain elects not to use SPF, a simple footer is added, by the client that cares about SPF, to e-mails sent with the domain as the sender that the e-mail may or may not really be from that server.
I'll add SPF if I can set certain IPs to "definitly validated by the server" and all others to "could have been validated by the server." The definites must then go through while the client can choose to let "maybe's" slide.
I don't like the idea of tracable e-mail. The big idea of the internet is that you can say what you want anonymously if you so choose. Killing privacy in the name of blocking ads is pretty silly.
Ben
Work Safe Porn
anti-spam measures available it's just that they're not used as support is not usually included/enabled in SMTP servers.
Including anti-spam features (not just anti-relaying) within the smtp server seems more appropriate rather than tacking records into dns entries.
DNS seems imho to be being overloaded with various add ons atm. If we're not carefull DNS will become the new bottleneck on the internet.
He could publish his local ISP's mail server's IP address in his domain's SPF record. This is not a problem at all.
Matthew @ Bytemark Hosting
Microsoft Originating Grammer
Pollocks Screwing Lightbulbs Discovered
Comment removed based on user account deletion
Though, honestly, I don't really care if "Linus Torvald (739359)" is karma whoring: If the post is pertinent and people have not seen it before and they honestly find it interesting enough to mod-up, whatever. If he's merely a troll, then hopefully people will learn from this experience.
Anyway, it seems SpamAssassin will be adding support for SPF in 2.70, at least according to bug 2143. That's cool!
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Are you used to sending personnal email (one that have another domain than your employers in the From: address) from work using your company SMTP server as a relay? You know, the only one you have access to with many reasonable security policies...
Can't do that anymore, your message will be flagged as spam by the recipient server if he checks for SPF records.
Have AOL warned its customers of this little side effect of it implementing SPF?
Plus SPF technically wise sucks, it should have been a new record type using TXT records is an ugly kludge...
Comment removed based on user account deletion
Add me to your DNS!!
America Online's apparently carving themselves a real niche in the music business, going to records as a means of publishing, rather than MP3, WMA, et cetera. I wonder if they're going to be putting some of the records out on the white vinyl, because it's totally collectible.
I, for one, can't wait to buy an LP-ROM for my computer so I can listem to them.
This is not going to work for domains that have dynamic IP addresses. Yet another reason we need to migrate to IPv6 and eliminate the need for dynamic IP addresses.
This will hurt people who use mail redirection services like Bigfoot.
I have switched providers but kept the same email address in the From: field.
On the other foot, direct spam and bounces from spammers that use my address for their From: could make my Bigfoot address unusable soon.
How about using the proper tag,
<acronym title="Sender Permitted From">SPF</acronym>
Or if you want to include it in a link
<a title="Sender Permitted From" href="link">SPF</a>
Comment removed based on user account deletion
In fact, as far as I can tell, you can add any record type to djbdns, since it allows entering a binary "type" in its data.
Therefore, even though a type is not "known" to djbdns, you can still publish / use it.
Caveat Emptor: this message won't selfdestruct if you memorize it!
You can have a personal list of "known good domains" with competent managers and SPF from which mail go directly to your inbox, without other spam filters. Safe knowing that mail from these domains really are from these domains.
You may even want to use a whitelist server ran by someone you trust.
...?
Ceci n'est pas une signature
What if I don't have access to the authorized relay, as in all company outgoing mail must go through company SMTP server, wether it as a @company.com from address or a @vanitydomain.com address.
If you read personnal email at work (bad) but keep it separate from your professionnal email (good) this will greatly inconvenience you.
And what about the consultant on a customer's site, if he don't have access to the authorized relay. He can't send mail while still having a perfectly usable SMTP relay at his disposition...
But I also have mail system at work with 25,000 user accounts. I need to get sendmail to auth through the same pam system-auth other services use (it's a complex mix of kerberos with fallback to ldap). A separate sasldb is just not going to cut it in that environment
I think saslauthd is the ticket. I'd just like some sort of pointer that that is the right track to persue and how to make sendmail use it.
Taken directly from here
It all goes downhill from first post
In an amazing coincidence I just implemented SPF filtering on my server yesterday.
This is what I got:
Jan 8 19:34:01 scrat sendmail[16839]: i08IY0ON016839: Milter: from=<larhondabeirne@aol.com>, reject=550 5.7.1 Command rejected
Jan 9 05:34:47 scrat sendmail[16305]: i094YlON016305: Milter: from=<krbsnag2gs@aol.com>, reject=550 5.7.1 Command rejected
Jan 9 08:59:45 scrat sendmail[25027]: i097xiON025027: Milter: from=<clairacree@aol.com>, reject=550 5.7.1 Command rejected
This is your sig. There are thousands more, but this one is yours.
Does anyone know how SPF can be managed via dynamice DNS type of DNS services?
It seems to me that having my reverse DNS lookup containing my ISP's domain name rather than mine would help my server configuration. I have a problem with my DNS in that reverse lookups are resolved to a DNS entry, but it belongs to my ISP domain and not my domain name. This gets some people pissy, but I don't see it being worth spending $100 a month extra from my ISP.
Would SPF help this problem? Would I actually be able to gain trust from others? Would DynDNS be able to accomodate this feature? (I'll have to ask them...)
I think a lot of this falls back to a much simply question: Why do we have DHCP addresses on the internet anyways? They do not change. I think mine is about 9 months old. Others tell of greater than a year with the same IP address. I think it would actually help security if people where give static IP addresses. Then they would have to take care of it to ensure they don't act stupid.
Is this not the exact reason the reply-to field exists?
Sign your messages with PGP so that everyone knows it's really you, whatever address the mail comes from. AFAIK all mail clients automatically use the reply-to field when someone replies to your message.
Wenn ist das Nunstueck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput.
MX records are not really sufficient. If I am a big ISP, I could have some servers to receive mail on, and some others to send the mails from my subscribers.
I gave up with the idea of an useful sig...
AOL has a ptr:mx.aol.com. Does that mean that I can just set the ptr record for my mail server to mx.aol.com and contin^H^H^H^H^H^Hstart spamming, posing as an aol user?
Perhaps now those foolishly idiotic silly ideas about per-email charges to reduce spam will go away now.
This is a much better solution! Sure it's not perfect, but it's a start. And it's not some silly proprietary system like MS would (will? It is inevitable...) force on there users.
I get the impression that more and more spam is sent from a highjacked home user PC, going through that users normal SMTP server. In this case, I cannot see how SPF should be of much use?
//Wegge
...SPF technically wise sucks
Agreed. I'm going to cut-and-paste the set of flaws I was talking about *last* time SPF came up on Slashdot:
First, this is nothing more than an authentication system. It's designed to allow a server to authenticate itself as a trusted source for a domain's email. However, the designers chose to use DNS as a transport mechanism. Not a good idea. DNS is designed to be lightweight and low latency, not to be secure. It's pretty easy to spoof DNS responses. Plus, DNS data tends to get cached. All you need to do is spoof a response, the nameserver's cache is poisoned with false data, and the next N emails (until the cached data expires) are accepted as valid.
Second, this system relies on having everyone implement such functionality. Spammers don't give a damn about return addresses, so they can send email with a from address at any domain. The annoying and ineffective attempts at stopping all open mail relays on the Internet illustrate the failure of this model. A security system that relies on correct implementation over the full Internet to function properly will not work in real life.
Third, this fails to deal with throwaway domains. The authors waffle a bit about them, and finally come out and admit that more mechanisms are required. Dammit, if we had a good PKI trust-ranking system (which is the sort of thing that they are requiring to fix their failings) we wouldn't need this system at *all*, since we could simply sign email and have trust rankings for users.
Enough about the bad design: other reasons I don't like it include:
* The authors have made a decision to make it really annoying to send email from a machine, and have to work with your ISP just to have a mail server. There are plenty of more solid antispam proposed mechanisms that do not place restrictions on who runs what servers (pay-per-email or pay-per-initial-email, PKI systems). This is much more in line with the way the Internet works for most services.
* There is a supposedly trusted authentication system being spread across the entire Internet over an insecure transport protocol.
* DNS caching can make moving an SMTP server or setting up a new one take a significant amount of time.
* IP-based auth isn't a great idea anyway, for a number of reasons. The authors claim that it isn't a huge issue, because IP spoofing is harder (I disagree -- things like Mobile IP have made it harder to *block* IP spoofing).
* Users have no control over what gets blocked. If I *want* to receive email of a particular type, I can't. Two ISPs (sending and receiving) are the ones that determine what mail I can receive). This is perhaps acceptable within a company, but annoying and goes against traditional Internet structure.
* It does nothing to avoid compromised end user machines.
* It does nothing to deal with throwaway accounts.
* It does nothing to deal with misconfigured servers.
May we never see th
He's happy to admit it. Mod the bastard back to the stone age.
It seems that at the moment, spammers send mails to millions of possibly-active email addresses, in the hope that some of them are active. What's to stop a spammer making up possible addresses, querying SPF records for these (possible) addresses, and publishing the list of validated addresses? Can we now look forward :( to spammers using better address lists??
All the spammer would have to do for a compromised box with SPF would be to tag their email as "From" your machine, and then spam all they want.
-- Hulver's site
paypal, ebay, circuit city, bank of america, and microsoft all have reason to publish SPF records.
Because the spam from the hijacked PC ("zombie") will most likely have faked "From:" headers.
So, the faked From: will say something like "ugh@aol.com" but it will be coming from (say) a Comcast IP. So when the receiver gets the message it will say it comes from "@aol.com" so according to SPF it should be coming from AOL's IP(s).
But it's not, it's coming through a Comcast IP. Therefore the message header is forged.
What happens then depends on what the receiving MTA is configured to do. Some may reject it right away, while others may flag it in some way.
Simple, yet elegant.
Anyway, I hope register.com hurries the hell up and lets me add these to my domains. I've actually been getting a bunch "recipient not found" messages going to [random word]@[mydomain.com] (not autpr0n.com, either my personal domain) meaning someone is spamming and using forged address claming to be from my domain
and for each bounced message, who knows how many are getting through. A friend of mine (an AOL user) actually had a spammer us his personal email address, and got not only a bunch of bounces, but angry emails and IMs.
The sooner this goes into effect, the better. It'll probably be a long time before we can block all email that doesn't come from a domain with SPF, but hopefully soon we can get rid of emails that are explicitly not authorized. (like those claming to be from my servers...)
autopr0n is like, down and stuff.
No it's not coming down the pipe. Check up on the SMTP standard and you'll see why:
First the destination spits out a banner on initial connecction. Then there's a HELO/EHLO from the sender which the receiver responds to. Next the sender sends a "MAIL FROM <person@domain>" string.
At this point the receiver can check whether the sender's domain matches the IP the actual connection is coming at, and whether that IP is authroized by the SPF record to send mail for that domain.
If it is not authorized to send mail, then the receiver can (if it wishes) to drop the connection right away.
The added bandwidth for a DNS query for the TXT record and the response will not be very large (and will be cached).
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.
Of course it can. Given that qmail was written in such a way that adding features like SPF checking is trivial.
Well, I can dream, can't I?
But seriously, the two technologies together would pretty much kill spam "as we know it". That is to say, most of the anonymous, illicit, untraceable SPAM we get today.
Simply set all messages that either have ridiculously liberal SPF records (i.e. *.*.*.* or something) or messages that don't come from valid SPF specified machines to be challenged (you could also employ some kind of Bayesian filter, but I doubt that will help. See more below). Then wait for the response before white listing the address, and letting the message through.
Once this is widespread, people sending out junk-email will need to spam using their own domains. Which isn't that hard to do. Which is where the third phase of my plan comes in. A distributed blacklist of domains. This would work much better then the current Bullshit IP blacklists. Enough complaints and the domain would be marked down as a spammer.
Spammers would need to buy new domains for each spam campaign, and hopefully not be able to get out more then a few hundred SPAMs before being blacklisted. That would make spamming completely unprofitable.
autopr0n is like, down and stuff.
Which is good for machines that have several users on them.. Get 40,000 users and all joe spammer needs to do it run some dictionary level attacks on the SASL SMTP AUTH and bam.. free spam relay! SASL SMTP AUTH is worse then an open relay, in my opinion.
I have email addresses under many domains, often not under my control. I send all from my home SMTP server. SPF will break this.
:(
It just adds more inconveneience for little gain.
What ever happened to "be liberal in what you accept and strict in what you send"?
See: this message on the SPF mailing list
SPF support for most open source mail servers can be found at libspf2.
For instance, the box on which I get all my mail, to which all my mailing list subscriptions go, and which is associated with my online identity everywhere I have one...is located halfway across the continent from me
Two solutions.
1) The "hard" but proper way, setup SPF records from all the machines you will be sending mail from or
2) Simply send all your mail out through the box you get it in from. What's so hard about that?
Anyway, I'll be happy to let anon mail through just for your convenience, so you don't have to setup SPF once every 6 months, or wait for your email to get forwarded through your own mail server, if you'd be willing to go through and delete the hundred or so SPAMs I get each day. Sound like a fair deal?
autopr0n is like, down and stuff.
First of all, why can you use the machine you receive mail on to send mail? Obviously that IP doesn't change too often.
And in any event, most dynamic IPs are within a certain net block. so you can simply add that net block to your SPF record. I'm assuming you have your own domain here.
autopr0n is like, down and stuff.
RMX was such a cooler Acronym. I know it didn't require modification of bind, but I don't know about other mail servers.
Seriously "SPF" doesn't make that much sense by itself while "RMX" both sounds cool and is pretty obviously decipherable.
autopr0n is like, down and stuff.
I just realized how the 222.235.48.0/N notation worked. It's the first N bits that are on of the host mask, not the last N bits that are zero.
That confused me for the longest time. But I was too much of a pussy to ask what the hell that meant.
autopr0n is like, down and stuff.
Will they HONOR them as well as publish them? Or will they continue to block connections from cable modem hosts even if those hosts have SPF records demonstrating their validity?
I'll have to see if dyndns can set up SPF records and test that later today.
A peer-to-peer network shouldn't have ghettos.
Ownz0red boxes arn't going to be added to anyone's SPF records, so letting all mail with valid SPFs should be okay. In that case, you will at least know who's responsible for spamming you : P
autopr0n is like, down and stuff.
What about sites like mail.com, where I get to use an email alias but the email actually comes from my ISPs SMTP server? There is no way they could do an SPF record for those. Hmm. Nice in theory but after deep thought doesn't seem to fix everything.
It's easy enough to add an SPF record to your domain (in fact, I just did it for mine), whatever your DNS server software... but what about implementing SPF on your mailserver?
I see plenty of instructions for various *nix mail services, but I suppose I'll have to wait for a $$$ 3rd party solution before I can add this functionality to my Exchange server. Bleh.
On the other hand, if you want to do things on a per-user basis, now you have to look at the "exist" directive. This is where you put out a definition using their macro language. One of the % commands is for the e-mail address, and another is for the source IP address.
The far end expands the %s into their real values, glues it all together, and arrives at something huge like username.domain.IP.foo.example.org. Then they look that up, and if it exists, it's accepted.
I can't imagine how evil and complex my foo.example.org zone would get, given a few dozen roaming users. This is going to make life miserable for me both at work and at home, since both places have people that don't send mail through the domain mail servers. I'm not going to turn on some kind of SASL/auth stuff, since that asshole spammer will just start attacking my accounts. All he needs is to find one, and now I'm hosed.
The problem with SPF is if it takes off, nobody will consider a different solution which can solve this problem a little differently. Everyone will be happy with their 90% solution, and the rest of us are screwed.
Sorry. Spent too much time looking at AOL's IN TXT, the brain was locked on /24.
How is this -1, Troll? Come on now...
Casual Games/Downloads
bmf + spamassassin on the front line get more that 99% of it meaning that I see a spam only about one every three days, filtering about 100 a day.
And I do care about a proposal that will hinder my ability to use SMTP relay that I have a legitimate access to, because some people can't take proper technical measure like filtering on content.
Filtering on dubious technical criteria is not the way, a spam message is one because of its content, not because of the relay it used.
I oppose any measure that affect current legitimate use.
"SPF" is not an acronym. The proper tag is:
<abbr title="Sender Permitted From">SPF</abbr>
Microsoft Windows is, fittingly, the official Desktop OS of Olig
The biggest problem I can see with this is that it breaks forwarding. I have several email addresses that I don't use anymore but that I still get email on. If I take the SPF people's recommendation and just remail it, I lose the sender information, or at least lose access to it when listing my emails. It would be nice if this could handel forwards as well.
THIS SPACE FOR RENT
I don't believe any sort of server should be dynamic. The whole idea of a server is that it's a static place one can always reach. Dynamic setups are partially the reason email is in the pickle it's in right now.
IMHO, the current situation where you check your work mail from home by connecting to pop.work.com, but send mail that's from "user@work.com" through smtp.home.net is not very good--in an ideal world, you would use some sort of secure smtp to send your work mail through your work domain's smtp server, not your home isp's.
I'm using qpsmtpd with qmail instead of qmail-smtpd, and the CVS version includes a plugin for checking SPF records.
As soon as the C library is done, I'm sure someone will write a patch for qmail-smtpd.
For more MTA compatibility info, check out The SPF download page
It's a bummer for those of us who use forwarded accounts such as bigfoot who I used to use (before they kept hiking prices and dropping support). It had the advantage that I could switch ISP's and keep the same email address... with spam filtering also.
Since most of these forwarders do it on the cheap, asking them to provide an SMTP/SMTPS gateway (so the address matches the SPF record) would probably be financially prohibitive.
Kills 'em dead. Also works on snails, slugs and leeches.
Need Mercedes parts ?
Great, just what I needed - AOL to regulate my sunscreen!
Must-not-watch TV!
We could now start a flamewar over acronyms v. initialisms. But if I wanted to engage in such a puerile waste of time, I'd go argue gun control and evolution on Usenet; and besides, it would be irrelevant to the parent comment. So instead, I'll merely point out that the tags <acronym> and <abbr> have semantically discrete meanings.
<acronym> is intended to be used for pronounceable formulations. <abbr> is for unpronounceable strings. Sometimes it's a judgment call - for example, some people pronounce "SQL" as a word and some don't - but two different tags exist for a reason. There will probably be other good reasons if/when somebody actually creates more widespread applications that use robotic parsing of semantic markup.
Users of aural browsers will thank you for honoring this distinction.
Microsoft Windows is, fittingly, the official Desktop OS of Olig
I have a site hosted on Hostway, and I don't see any way to put up an SPF record. I just emailed them about it.
Also, what about GoDaddy? I don't see any way to publish a SPF record, and by the results of a quick Google search, it looks like GoDaddy doesn't offer it. Before SPF gets off the ground, all these providers will need to support it.
pobox.com doesn't know any of these IP addresses, so if they *do* advertise SPF records for *@pobox.com, anybody who listens to SPF will reject me, and probably most of their other customers. It's fine for them on the input direction - blocking forged aol mail, for instance - but even that prevents you from sending mail From: you@yahoogroups.com when you want the replies to go to your yahoo address, not your real address, which can be important if you're sending to people with dubious Microsoft mail systems that might ignore Reply-To: or people who don't pay attention to message bodies that say 'Please reply to my yahoogroups address, not my work address" (like your mother-in-law on aol.)
For someone like Karl, I'd expect that the risk is that if you're using a dialup connection that requires you to use _their_ SMTP relay, or if you're on a hotel broadband connection that hijacks SMTP, you'd risk having some people block your mail. Hopefully SPF-using SMTP servers do so noisily and not silently...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Register.com's system also doesn't allow you to add TXT records to your DNS records either.
I've e-mailed them once about it, and will probably bug them again once AOL adds the SPF record on a more permanent basis. Basically, they need to get with the program and provide the ability or I'll take my domains elsewhere. The e-mail response I got the first time was pretty much clueless.
Wolde you bothe eate your cake, and have your cake?
Simple Authentication and Security Layer allows a user to identify themselves to a mail server. POBOX just needs to set up a mail server that uses SASL and then their users use that to send mail.
This is often referred to as SASL auth or sometimes SMTP auth.
They probably need to set it up on both port 25 and another port generally 587 in case users ISPs block connections to port 25.
Alternatively there are older solutions that may work for some mail services like POP before send. Where any IP address that has successfully logged into the POP server can send e-mail through the mail server for a certain period of time.
Basically once SPF catches on public mail services need to run their own mail servers. This makes sense, it's their e-mail and they should be responsible for sending it.
In the case of pobox.com seems to already be running SASL:
% host -t a sasl.smtp.pobox.com
sasl.smtp.pobox.com A 64.71.166.114
pobox.com is already publishing SPF records so it looks like they think it will work for them.
% host -t txt pobox.com
pobox.com TXT "v=spf1 mx mx:fallback-relay.pobox.com a:emerald.pobox.com ?all"
They are specifying the loose "? = unknown" for servers other than their own, but it is up to the receiving MTA to allow or deny "unknown".
They are following the SPF adoption strategy:
"Initially, domain owners can set ?all, which means "default unknown". They start educating their users to switch to SASL AUTH, and maybe set a local sunrise date.
When the vast majority of users are doing the right thing (sending mail out only through the domain's designated mailers) they change the default to -all, which means "default deny". That tells SPF-aware receiving servers that it's safe to reject SPF violations rather than classify them as spam."
This message is encrypted with Quad ROT-13 to protect the author's copyright under the DMCA.
For example on my domain dszd0g.org the record looks like:
'dszd0g.org:v=spf1 include\072dragonpaw.org -all
The only pain is the need to use \072 for the : in the text record.
This message is encrypted with Quad ROT-13 to protect the author's copyright under the DMCA.
w3schools.com is hardly the be-all end-all authority on HTML semantics. In fact, I'd say that a website that (as of 2004-01-09) uses tables for layout and <b> for navigation bar heading text wouldn't know what "semantic web" meant if it reared up and bit them in the you-know-where. (Go ahead, view the source.) The disclaimer on their homepage states, "W3Schools is for training only. We do not warrant the correctness of the content. The risk of using it remains entirely with the user." I'd listen to their disclaimer (and homepage joke-of-the-day) much more than their markup advice.
Come on: A random link does not an argument make. I've seen horrible HTML tutorials "explain" how <blockquote> is used to indent text and <h1>, <h2>, et al are good for making text bigger and smaller. If "somebody wrote it on the Internet" links constitute an argument, though, I'd say that Web Design Group offers a much more reliable and better-thought explanation of <abbr> and <acronym>.
Also, note that the W3's homepage itself uses <abbr> and <acronym> as I described, with the incomprehensible exception of their copyright-footer link to the name of the W3 itself. Their entire homepage navbar marks up abbreviations such as "HTML", "CSS", and "XMLP" using <abbr> while reserving <acronym> for pronounceable formulations such as "SMIL" and "SOAP". (Again: View the source.) I'd say that if any page has been extensively tested using a diverse spectrum of user-agents (including aural browsers and experimental semantic web applications), the W3's homepage is probably the benchmark to be exceeded.
As for the formal specs and other documentation (which really ought to be referenced here), I'm way too lazy to dig through them for a random /. argument. But that's ok, since another poster already took a decent crack at it. :-)
But the central issue remains: Assuming that <abbr> and <acronym> are to be used as you say, they're semantically indistinguishable and therefore redundant. I say that each has its own correct discrete usage. <acronym> is for acronyms, which are pronounceable by definition and often words in and of themselves (e.g., Web Design Group's example of "radar"). <abbr> is for other abbreviations, including unpronounceable initialisms, which cannot be pronounced or used as whole words in their own right. This is an important practical distinction for Web robots and aural browsers.
HTH.
Microsoft Windows is, fittingly, the official Desktop OS of Olig
None of AOLs DNS servers are currently publishing TXT records.
% host -t txt aol.com dns-01.ns.aol.com
aol.com has no TXT record at dns-01.ns.aol.com (Authoritative answer)
% host -t txt aol.com dns-02.ns.aol.com
aol.com has no TXT record at dns-02.ns.aol.com (Authoritative answer)
% host -t txt aol.com dns-06.ns.aol.com
aol.com has no TXT record at dns-06.ns.aol.com (Authoritative answer)
% host -t txt aol.com dns-07.ns.aol.com
aol.com has no TXT record at dns-07.ns.aol.com (Authoritative answer)
So it isn't a matter of propagation. Either they put them out and decided to remove them or Slashdot failed to check that the article was correct -- but that would never happen.
This message is encrypted with Quad ROT-13 to protect the author's copyright under the DMCA.
LiveJournal is publishing SPF records since they got joe-jobbed a few months back:
;; ANSWER SECTION:
marnanel@spectrum:~$ dig livejournal.com txt
[...]
livejournal.com. 3153 IN TXT "v=spf1 a mx ip4:66.150.15.140 ?all"
(PS: I'm nothing to do with LJ other than being a satisfied user.)
GROGGS: alive and well and living in
Oooh, wow. I didn't even think of that. You're right. That's *incredibly* nasty -- someone spoofing DNS responses containing SPF records could take down, say, all AOL to MSN email for however long the SPF records stay cached. With one packet. Without even needing to flood any system, since we're talking UDP, not TCP.
May we never see th
... at least for client-side filtering. To confirm that an email address johndoe.com.com is live, send a message to him from johndoe-com-com.spamdomain.com, then wait for the SPX request. Confirm with a custom DNS server. Unlike a web bug, it doesn't prove that he read it, but it confirms that the address is live *and* running SpamAssassin.
Of course, putting SPX in the SMTP server doesn't suffer from this problem, especially since the server can cache the SPX data for spamdomain.com.
I hereby place the above post in the public domain.
SPF pushes the identity issue down to the IP address level. How secure is that? Say I'm a spammer and I want to forge a respectable, SPF-using domain. I create a program that sends my email in special packets, to make it appear that they originated from the respectable domain's email server IP addresses. My host just looks like a router doing its job. Is it possible to fool an SMTP server this way, or would it figure out that my traffic is bogus?
I don't know the answer to this, just asking.
Looks like SPF is everywhere today! LaneChange.net had a press release announcing that it had added TXT records to its DNS hosting service to allow their clients to publish SPF records too!
e .h tm
http://www.cpureview.com/news/20040109lanechang
Imagine if all the big email players published SPF recs, man the spammers would burn in hell!
-Joel
Pay per email? Pay whom, precisely?
:-)
I would advocate a middleman. However, other folks prefer the recipient (which avoids the political problems of creating another Verisign-like monster).
Why should I pay you to send you email that isn't spam?
Because doing so means that globally, spam goes away. The primary network-visible differentiator between spammers and nonspammers is that spammers send vast quantities of email for which they are willing to pay almost nothing.
Would you pay, say, a tenth of a cent, or perhaps even a cent per first email to a person you send? I really think that, for most people, this is not financially stressful. In my entire time on the Internet, I believe that I have probably directly emailed fewer than three hundred people, which comes out to three dollars or thirty cents, depending upon which of those two pricing things you're using, for years and years of spam-free email.
Would you give me the cash back?
This could be implemented, yes. In the case of a middleman, I suspect that they'd want to make some fee, and would probably want to keep at least some percentage.
You say that SPF works against the way the internet works, well, the internet is a free-for-all, so why is paying per email NOT against the way the internet works?
Well, you're right about that much.
Because it allows peer-to-peer connectivity, which I view as the fundamental feature of the way the Internet works. There are no "special" hosts. The reason I think that pay-per-email is justified in only the case of email is that email is a very unique service, different from almost everything (with a possible exception of instant messaging) in that it allows anonymous people, anyone on the Internet, to grab your resources in the form of human time and storage space. Web servers and anonymous FTP servers mostly only provide resources in the form of connections (and most sysops have some sort of system to prevent folks from eating up connections like mad...you can't grab all 1000 or so of ftp.apple.com's connections) and bandwidth. Bandwidth (except in the case of zombies, which are dealt with in their own way) costs an attacker as much as it costs a defender, which generally is acceptable on the Internet. The Internet has many places where an attacker can cost a defender an equivalent amount of resources -- this is generally considered acceptable. Anyway, I'm rambling a bit. Email allows *anonymous* people to get at your time (which is extremely expensive relative to computing resources) and storage space (still somewhat expensive, since mostly people only have mailboxes of a few megs).
PKI? If Computer A trusts Computer B, does that mean Computer B gets a high ranking? What if Computer A is a spammer? Computer C, which nobody knows, and therefore nobody trusts, how do they get email out to people? They may be the next Slashdot, or have something earth-shatteringly important to say. Are you going to reject their messages because nobody trusts them? If they spam, presumably they get a negative score. But what if someone who has an axe to grind says they've spammed when they haven't?
These are all pretty general PKI/trust issues. There are plenty of proposals to deal with drawbacks. The thing is that trust networks aren't fundamentally flawed on multiple levels, as SPF is. There are *pages* of obvious solutions for each point you listed above -- deciding on a particular one takes thinking and hammering on, but I don't think it's unreasonable to claim that something generally acceptable to Internet folks can be settled upon.
How do PKI/Pay-for deal with throwaway domains, or compromised machines?
Well, *I* tend to favor pay-for-initial-email, using a middleman, which certainly do not encompass all pay-for systems. Middlemen would probably be accredited by ICANN, as they've done for the existing name registrar system. It's a business much like name reg
May we never see th
OK, I read the links and still don't know exactly how spf works. I'll stipulate my cluelessness but would appreciate a basic run through on how this works.
I'm no expert, but why didn't we slap this problem in the face long ago with digital certificates?
... here's my cert ... you trust the root CA. If I'm known to be a spammer, blacklist me ... bada boom!
I'm sending a piece of mail
Is it an implementation problem? Could authentication be implemented on top of the existing system and phased in?
http://www.emediawire.com/releases/2004/1/emw97845 .htm should provide some ammo they can understand.
Yes! I still don't see a solution to this problem, and _plenty_ of people are affected by it.
I use demon internet now (cancelled TeleWest cable) because
1) Fixed IP without paying around 4 times the price
2) No silly rules like against running servers
3) Decent news server
4) No silly rules about not VPN to work
5) Save 5.00 per month
6) Did I mention no silly rules?
7) Twice the upload speed
Sam
blog.sam.liddicott.com
I'm probably missing something stupid, but why do I get a 0 answer on the query?
~$ dig aol.com txt
; <<>> DiG 9.2.1 <<>> aol.com txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11765
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;aol.com. IN TXT
;; AUTHORITY SECTION:
aol.com. 600 IN SOA dns-01.ns.aol.com. hostmaster.aol.net. 2004010902 1800 300 604800 600
;; Query time: 25 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 9 18:08:39 2004
;; MSG SIZE rcvd: 89
~$ dig @dns-01.ns.aol.com aol.com txt
; <<>> DiG 9.2.1 <<>> @dns-01.ns.aol.com aol.com txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31149
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;aol.com. IN TXT
;; AUTHORITY SECTION:
aol.com. 600 IN SOA dns-01.ns.aol.com. hostmaster.aol.net. 2004010902 1800 300 604800 600
;; Query time: 23 msec
;; SERVER: 152.163.159.232#53(dns-01.ns.aol.com)
;; WHEN: Fri Jan 9 18:09:43 2004
;; MSG SIZE rcvd: 89
I had missed an earlier post from Wayne that indicates aol was just testing it briefly and planned to roll it back temporarily:
9 27 250
http://slashdot.org/comments.pl?sid=92139&cid=7
SASL is certainly a good start, and particularly needs the alternate port to deal with fascist ISPs that block Port 25 (an increasingly popular thing to do, unfortunately, especially for US cable modems), but it still doesn't deal with firewalls. Users who want to do this from work need to get their offices' sysadmins to enable Port 465 or whatever port their provider likes.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It will be of great use in discouraging them from forging my domain in their headers.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
What's wrong with setting different From and Reply-To?
For one thing, in today's Internet business climate, it looks unprofessional to have From: somebody664509@aol.com, Reply-to: sales@bindaca-inc.com. For another, your clients will likely categorize their e-mail based on your reputation, which their MUAs would tie to your From: address, which would change every time you switch ISPs, resetting your reputation to zero.
So you have to ask your ISP if you want to run a mail server. Why exactly is that so difficult?
ISP will probably charge you upwards of $50/mo for the privilege of running your mail server over its private network. "If you want to run your own mail server, you must be a reasonably large business; we'll have to upgrade your contract to business class. What's your D&B D-U-N-S number?"