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."
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?
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
[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
They said the same thing about SPEWS... but heck, it works ;-)
I'm working on another thing called DoNotPost.com, and that doesn't look like it has too good a chance, because while it mimics the Do Not Call registry, it doesn't have the same kind of enforcement (US Laws).
Skaag
All those moments will be lost in time, like tears in rain... time... to... die...
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
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
In case any windows user is interested, but cant use dig:
$ dig aol.com txt
; <<>> DiG 9.2.2 <<>> aol.com txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49576
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;aol.com. IN TXT
;; ANSWER SECTION:
aol.com. 300 IN TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/24 ip4:205.188.157.0/24 ip4:205.188.159.0/24 ip4:64.12.136.0/24 ip4:64.12.137.0/24 ip4:64.12.138.0/24 ptr:mx.aol.com -all"
;; AUTHORITY SECTION:
aol.com. 3071 IN NS dns-02.ns.aol.com.
aol.com. 3071 IN NS dns-06.ns.aol.com.
aol.com. 3071 IN NS dns-07.ns.aol.com.
aol.com. 3071 IN NS dns-01.ns.aol.com.
;; ADDITIONAL SECTION:
dns-02.ns.aol.com. 3273 IN A 205.188.157.232
dns-06.ns.aol.com. 1887 IN A 149.174.211.8
dns-07.ns.aol.com. 431 IN A 64.12.51.132
dns-01.ns.aol.com. 192 IN A 152.163.159.232
;; Query time: 110 msec
;; WHEN: Fri Jan 9 09:06:32 2004
;; MSG SIZE rcvd: 405
Nerds don't go out into the sun.
Ben
Work Safe Porn
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.
It will reduce spam because of two reasons.
1) since it effectively kills sender forgeries, it's a LOT easier to maintain white/blacklists
2) a domain needs to be purchased, and the registration takes time; this increases the cost of spam and hopefully might also make spammers more traceable (credit card transactions for registration)
I am totally convinced this will make the spam problem manageable. I'll probably add my own SPF this weekend.
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
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.
Actually, when you set the default search domain to the ISP you are dialling in to and fix the SMTP server to "smtp", this usually works.
Setting the search domain is easy when you get your address using DHCP, and could be done in an ip-up script in other situations.
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
Spammers can just use their own domain
Yes, they can. And all I need to do is to let the domain be one feature to do adaptive filtering on. Two mails on penile enlargement, and no non-spam email from one domain, and that domain will be a pretty clear signal to throw stuff away. Time for the spammer to get a new domain.
Many will not implement this!
Well, whether everybody implements it or not, it does give me another factor to filter on. If the mail comes from a domain that does not implement it, that's grounds enough for a big, fat -5 spamassassin rule right there.
Oh, and as more and more people implement this, those who do not can be more and more severely punished by spam filters (as the exceptions for any one person becomes few enough to whitelist and so on).
But if you blacklist any domain without it, some people won't be able to send stuff to you anymore!
Cry me a river.
Trust the Computer. The Computer is your friend.
My own experience:
I happen to be hosting a few domain names that attract a lot of joe jobs, if this method helps me reduce the amount of joe jobs by 5%, it was worth it. The amount is simply HUGE.
The Deterring factor:
If the Spammers are smart enough to check my domain for SPF records before doing a joe job on it, they might not select it for their joe job, simply because they will know their campaign might not be as effective as it would be if they used another domain that does not publish SPF records. So the deterring factor is important here!
Conclusion:
Every effort counts. And let's not forget that sometimes, all it takes for an idea to catch on is some large corporation using the technology or technique, and it will catch like wildfire. I'm also publishing SPF records for my own domains, and checking for them as well (with the help of qpsmtpd which has a nice SPF plugin).
All those moments will be lost in time, like tears in rain... time... to... die...
> 2) Spammers tend to use made up domains anyways.
This is true, but combined with domain checking AND SPF I can see it being more powerful than both.
for ex.
spammer makes up umergeh.drewhs.com
email gets canned because the domain is fake. lose for spammers
spammer sends faked address from aol.com
SPF shows its a fake sender (rteal IP not match aol.com spf list). lose for spammers
spammer at aol sends real spam from aol.com
aol come down and bite spammers head off, spammer goes to jail. lose for spammers!
SPF is only one tool, and there are many combine them together and you have strength
mac desktops, dare to be nude
You seem to complaining that this might not work because everyone on the planet would need to use it and even then spammers could use their own domains.
Certainly it's true that nearly everyone will need to get on board for this to work. Fortunately, it should be an easy update on both the MTA and DNS ends.
The real advantage here, I think, is that it will make filtering and blacklisting much easier. Instead of trying to filter on 18 zillion weird rules and scads of IP addresses, some of which may have some valid users, you just need to filter on domain names.
For this to work, we will need one or more trustworthy registries of bad domain names. And it should probably be distributed, with a way to continually update it by automatically propagating the list of bad domains to all clients. There should be a way to get a domain into the blacklist very quickly if anyone receives spam from that domain.
Alternatively, a system could be in place to treat all new domains as bad by default. That has obvious problems though -- how would you get your domain trusted? Would it require a VeriSign like identification process? I would oppose that -- I think people should be able to buy domains and freely run email servers on them without paying some central "authority."
My biggest concern with this idea is that I run a domain where I give out POP email addresses to people. I'm still trying to figure out how that will affect me.
For more info, see here
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.
It may not reduce spam, but it may very well reduce the possibility or severity of joe-jobbing for my own domain. That's enough reason for owners of domains to put an SPF line in.
It may not be very long until so many domains have it that it is useful for MTA applications to take notice of them so there's incentive to do it I think
mac desktops, dare to be nude
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.
Working right now, you will have your proof later.
For now on, I will ask you to read a bit.
Enjoy the follow-ups.
And please stop confusing real users and fucking lamers that take the name of people they will at last try to put Yoda Grease doll in.
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
The spam is still coming down your pipeline, wasting your bandwidth. If you are checking these lists, you add waste more bandwidth (not a lot, if you cache the spf records). You will waste more cycles trying to kill the incoming spam. If your servers are prone to dying when faced with a lot of spam, this won't solve anything as far as I can tell.
stuff
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
Nice trolling
stuff
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.
AOL (and Hotmail, and other large ISPs) are frequently joe-jobbed - it's therefore worth it for them. If I can tell SpamAssassin to score anything above the threshold that purports to come from AOL, but not from their SPF IP allocation, it helps. Better still, now I can tell for certain that @aol.com mail really DID come from AOL, I can assign a negative score to AOL addresses since I know it's likely to be ham.
Oolite: Elite-like game. For Mac, Linux and Windows
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.
You are doing a reall good job at copy and pasting past comments for karma whoring.
I bet your parents are proud!
stuff
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
I call cut-and-paste karma whore. The "preventing joe-jobs [catb.org]" is a giveaway - there's no link.
This appears to be a straight copy/paste from this comment in one of the linked articles...
for example employees not being able to send company email while on the road without hassle
Boo hoo a mail admin will have to take the hour or two it takes to properly implement SASL and you will have to roll out a change to the corporate email client that defaults it to talking SASL. Besides most remote users use VPN these days anyways. Also if all the big guys implement it and implement serious negative scoring for those not using it then it will quickly be adopted by those with a clue, those without a clue I do not care to recieve email from =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Heh, three people saying it's a cut and paste at exactly the same time...
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
Bandwidth is not my problem. Not choking inboxes and mail clients with unwanted "herbal viagra" come-ons is. This will help solve that.
And, as others already mentioned, there will be a pretty powerful dicincentive to try to send any spam through enabled servers. If I at some point simply do not allow connections from unenabled servers (and yes, caching this info is not a bad idea - adding a IP filter rule upon a hit from a non-enabled SMTP server is even better), then bandwidth will be saved as well.
Trust the Computer. The Computer is your friend.
If your mail servers are going down because of the ammount of mail you recieve, spam or otherwise then you need to upgrade your mail servers, simple as that.
Take care - RL
Microsoft Originating Grammer
Pollocks Screwing Lightbulbs Discovered
An email with -5 in spamassassin will likely never be tagged as spam or discarded.
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.
And maybe I'm missing something too...
So you can spoof domain names, you can spoof sender IP's. What's to stop someone from just looking up a valid SPF domain and IP and spoofing both at the same time?
My new catch phrase is: "I NEED A NEW CATCH PHRASE, BABY!"
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
As to your first point DNS is great because lookups are generally fast and they are cached. I don't think even every host on the internet looking up the TXT records for aol.com every couple of hours at the most frequent is going to tax the kinds of bandwidth and DNS servers AOL employs. Besides the amount of email traffic that they will be able to dump before the session even begins will outweigh the DNS lookups probably a million to one in bandwidth.
As to the second point that is already easily dealt with by most intelligent MTA's, heck my ISP's email servers already flag any message which has a different sending IP and host identifier, and they have informed us that they plan to dump the connection on this condition "real soon now". SPF just makes this easier since it can be used to eliminate false positives from semi-clued admins.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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.
Ticking the 'do not want to moderate box' right now. It's of no use with so many ignorant people.
Thanks for your vigilance.
jdif
Let's overcome our weakness.
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!
what is really sad is that he'd still be getting mod points probably if they didn't cap at 5. and the fact that if you check the guy's posting history you'll see that this is all he does, and racking up karma.
1) Email worms
2) Zombie virus-infected mail relay clients
etc
If an experiment works, something has gone wrong.
Nonsense, the message body doesn't come down the pipe as the checking would be done before the data part ever starts.
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.
; > DiG 9.2.2 > aol.com txt
[...]
A perfect example of why dig is inappropriate for pretty much any task other than debugging BIND. Using host would get you the data you need in a much more sane format:
"The invisible and the non-existent look very much alike." -- Delos B. McKown
...?
Ceci n'est pas une signature
Hey, so you're going to switch to it even though you don't think it'll reduce spam in any way, shape or form... Amazing!
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.
for example employees not being able to send company email while on the road without hassle.
Unless they have an IT department knowing smtp auth.
It's not too difficult, is it?
What do you think costs AOL more...?
1) Bandwidth & CPU for additional DNS lookups when people forge mail from their domain.
2) Bandwidth & CPU & staff costs for emails to their customer support desk complaining about the spam. (Bear in mind that the vast majority of users are not savvy enough to know not to complain to AOL.)
Keep calling them out and I'll keep adding them to my foes list, good call!
Sapere aude!
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.
As for people on the road, they should have access to a VPN setup or to connect to a password protected corporate smarthost if they want to send e-mail with the corporate from address. It's not as if it's hard to do.
But anyway, just slightly reducing the risk of being on the receiving end of a few hundred thousand bounces or complaints because of spammers using a real or fake address on your domain in the from field makes it worth it to add SPF records to your own domain...
Thr trouble with verbal cotnracts is that they aren't worth the paper they're written on.
You can't spoof sender IPs - not for a TCP session like that required for SMTP anyway.
(Well okay, it's not quite true. You could just about manage to spoof IPs for machines on the same ethernet segment as you. However, if you're on the same segment as an outbound mail server, you're probably allowed to send via that server anyway.)
As for 2, are you really complaining that delivery of spam would be delayed? It's not as if MTA's usually try to deliver only one message at a time. Also, it isn't the mail server that should be responding to these requests, but a DNS server, which for any reasonably sized ISP will be on separate hardware. A purely authorative DNS server can easily reply in the roundtrip time + The thing is, this could add a tremendous amount of DNS traffic before it would become even a fraction of the traffic currently caused by bounces because of spam to invalid addresses being repeatedly attempted delivered to unavailable servers, or to innocent third parties.
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...
We need a new mod, "-1 cutpaste" that way the mods will understand why it has been marked down and hopefully do the same.
Dups in comments, eh? That too from the article link given in the current posting!
Original post Or may be I should just say earlier post?
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?
The lookup will be cached by your dns resolver and by your ISP's dns servers so there will be very little additional load on AOLs servers. And once people start using this it should free up a lot of people in their abuse department to deal with people *actually* sending spam from aol. It's a good thing !
Sig is taking a break!
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
For those like me who have no idea what a joe job is, here's the definition.
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.
And from djbdns tools:
$ dnstxt aol.com
v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/24 ip4:205.188.157.0/24 ip4:205.188.159.0/24 ip4:64.12.136.0/24 ip4:64.12.137.0/24 ip4:64.12.138.0/24 ptr:mx.aol.com -all
Its pretty sad when a commercial OS ships a debugger with their system but no compiler.
>"Well, what am I supposted to tell everyone in the office? No email for ... an
>unknown amount of time?"
You say "Guys, we need a new ISP - our current one is shit".
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.
I'm only using windows reluctantly but this is ridiculous. You can do the exact same thing with nslookup, supplied with windows:
G:\>nslookup
> set q=txt
> aol.com
Server: XXXXXXXXXXXXXXX
Address: XXXXXXXXXXXXXXX
Non-authoritative answer:
aol.com text =
"v=spf1 ip4:152.163.225.0/24 ip4:20....
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.
Actually, that wouldn't work -- other SMTP servers have no way of knowing which port your SMTP server will be on, so it is hardwired to port 25. You wouldn't be able to receive any e-mail.
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.
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.
Anybody know why I just get this:
[dossen@horse09:~]$ dig aol.com txt
; <<>> DiG 9.2.1 <<>> aol.com txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39946
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;aol.com. IN TXT
;; AUTHORITY SECTION:
aol.com. 20 IN SOA dns-01.ns.aol.com. hostmaster.aol.net. 2004010902 1800 300 604800 600
;; Query time: 3 msec
;; SERVER: 130.225.16.40#53(130.225.16.40)
;; WHEN: Fri Jan 9 16:39:20 2004
;; MSG SIZE rcvd: 89
And if I ask AOL themselves:
[dossen@horse09:~]$ dig aol.com txt @dns-01.ns.aol.com
; <<>> DiG 9.2.1 <<>> aol.com txt @dns-01.ns.aol.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1932
;; 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: 119 msec
;; SERVER: 152.163.159.232#53(dns-01.ns.aol.com)
;; WHEN: Fri Jan 9 16:40:45 2004
;; MSG SIZE rcvd: 89
Kills 'em dead. Also works on snails, slugs and leeches.
Need Mercedes parts ?
I get this too, perhaps it is a propogation thing?
Great, just what I needed - AOL to regulate my sunscreen!
Must-not-watch TV!
I was going to say exactly this, but if you read the responses to it, you'll see that it's cut-and-pasted from someone else's response in a previous story.
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.
It will probably not reduce spam quantity at all. (It does make domain-oriented white/black lists more reliable.)
Instead, it allows domain mail admins to have more control over how e-mail purporting to be from their domain flows. Just like mail admins control how inbound mail flows, this gives them the ability in reverse. Which makes it more difficult to get joe-job'd.
It does make it more difficult to the spammer, which is a nice bonus - but its purpose is to stop domain forgery.
OTOH, a single dig command gives you a nice snapshot of your DNS information. Suitable for saving off as an archive e-mail for future reference.
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
Same here, even worse. Earthlink (my access provider) blocks access to non-earthlink name servers, so i can't query AOL's dns. ;-(
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
Seems strange if AOL's own nameserver doesn't know about it. Note that the second time around I'm asking dns-01.ns.aol.com, which is mentioned in the SOA entry of aol.com. And just to add, I've also tried the other AOL nameservers. Where is this fantastic SPF entry?
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?"