Slashdot Mirror

Who are you or that priest to say that God created the world?

The fuss is that if your morality starts with a wacky 2000-year-old book, and that the benefits of moral behavior accrue in an undetectable and unfalsifiable realm, then you can end up with a perverse morality that causes overpopulation, poverty, disease, suffering and death, to say nothing of raped children.

There is no evidence that there is a god. New evidence, like that which started this conversation, keeps arriving in support of god-free scientific explanations of things formerly attributed to one god or other. We all need to open up our eyes to the obvious truth and let morality start and stop, on this planet, with each other.

It's perfectly possible to build authentication on top of SMTP without introducing needless compatibility problems. What's more, it already exists! All that's needed is for people to start using it.

Now if it takes this long for people to consider using authentication at all (and apparently even longer for the Slashdot mods to get a clue), what in the bleep are people thinking to suggest SMTP could realistically be replaced overnight?

They really can't do this until something like SRS is widely adopted. Otherwise, hard-enforced SPF breaks forwarding. (Soft-enforcing -- a warning message, which could be disabled by someone who knows they're forwarding their messages through a non-SRS-aware server -- is an interim step.)

• SPF
• SenderID
• DomainKeys

is already stupid enough without adding a fourth option into the list.

The whole things smacks of "not invented here" right now, they all do the same thing, they all do it in the same way, and yet everyone says theirs is best.

What's more interesting is the lack of awareness from developers for this. There are a lot of systems out there right now that will, for example, send invites to join their web site to your nominated friends using your from address. So as someone who has SPF and SenderID entries I see a lot of bounces because of this. It's not just a matter of making all mail servers support it developers also have to actually think and keep up and stop spoofing themselves.

DomainKeys protects the from From field. SPF does not.

Clear down the counter every so often at Spam Gourmet or adjust the anti-spam behaviour with a Pobox account.

Or get your ISP do hold the domain on your behalf

I found this post in the mailing list about the closing of the working group interesting.

A lot of the blame seems to go to MS. Strange that the article here didn't attract more MS bashing comments. Maybe most slashdotters don't know what has been going on and didn't realize this was a good opportunity for anti-MS karma whoring? :-)

Anyway, I'm glad MS didn't manage to sneak patents into a standard. As a previous poster said: "Long live SPF".

For those with acronym overload, that's SPF (Sender Policy Framework) + SRS (Sender Rewriting Scheme).

For those with acronym overload, that's SPF (Sender Policy Framework) + SRS (Sender Rewriting Scheme).

Does this mean that they are just not researching it anymore because SPF is awesome? Or does this mean that they are not going to certify anything that deals with DNS based TXT records showing who should be able to send mail from certain domains?

This is very vague. I looked at the FA but it's extremely boring and fixed width font and it kept making me fall asleep. I scanned it for comprehension, but I was unable to figure out what is going on.

Chris

Another point... the reverse-dns name for your ISP's mail server makes no difference to the SPF mechanism. When a mail server checks an SPF record as part of receiving an incoming message, and that SPF record contains an "a" tag, the mail server does a forward dns query on the domain name and compares the answer with the IP address at the other end of the socket.

The only time reverse-dns becomes part of the process is with the "ptr" tag- and even then it's only a part of the process. The description of the ptr mechanism says that a server should take the PTR result and verify that it forward-resolves back to the same IP address. This prevents a spammer who has control over their IP's reverse DNS from forging a PTR record with your domain's name and "allowing" themselves to send mail claiming to be from your domain.

SPF isn't an AOL technology - it's an open project. The core of the protocol seems to be adding some extended information in your DNS records.

SPF website

Regards,
Denny

I've just been using the SPF setup wizard to generate the SPF TXT addition, and it occured to me that this isn't necessarily going to stop Joe Jobs on small companies.

My domain and mail is handled by my host, with one mail server sending mail for multiple domains (mine and other people who have an account with the host). The reverse DNS lookup for the mail server give the server's name (myhost.com) and not my domain's (mydomain.com) as it's shared, so mail from mydomain.com only has to come from myhost.com to be vailidated. It would therefore be trivial for someone to set up an account with my web host, and they would then be able to Joe Job me.

I know it's only cheapo hosting, but the small one man bands who are vulnerable to Joe Jobbing may be using this exact setup. And yes, it would cost you money to set up the account, but if you were setting out to deliberately harm a competitor it's negligible. Or have I misunderstood something somewhere?

vfw

followed through from someone's link to http://spf.pobox.com/objections.htm,
I read about the IM2000 stuff @ http://homepages.tesco.net./~J.deBoynePollard/Prop osals/IM2000/

sounds tres sexy? I wonder if it would work?
somebody wanna rip it to shreds for our amusement (and further learning of course)...

Nice chart, but it's not very specific. In particular, I'm concerned about "an abuse reporting standard". Deploying any sort of standard in this area requires ISP cooperation, and I haven't seen much of that. As a complainant, I expect useful feedback from the ISP (Was it one of your users? What was done about it?) on every complaint, or I won't send any complaints at all. Why should I spend my time watching over someone else's customers, when I'm not even told whether my reports are read?

They ought to pay their own watchdogs, and leave me out of it (and sending me an autoreply with detailed instructions for how to send a complaint to their abuse desk, in response to me having just sent a complaint to their abuse desk, is plain rude).

And, sending a complaint to the ISP controlling the offending IP address in no way requires the envelope sender address to be authenticated by SPF or any other means. Authentication is nice, but botching forwarding in the process isn't a good compromise to me.

Just one question, has there been any work on a open standard yet?

Yes, it is substantially built on an open proposal, SPF. Sticking my finger to the wind, I am guessing that's what the IETF is going to go with anyway.

You can implement handling the setup of the DNS TXT records without touching anything Microsoft claims ownership of. You can implement the checking of the HELO/EHLO and MAIL FROM via SPF with no patent concerns. Will Apache, Debian, et al dismiss this, simply because the most popular implementations of SPF also support checking the header FROM field, which is supposedly Microsoft's idea?

The point of SPF was not to eliminate spam, but to eliminate spoofing

"What do the customers want? They want to communicate with their friends and family; and they want to not get spam. They do not particularly care if a few eggs are broken along the way."

DarkMan's got it right.

SPF adds a list to the domain's DNS records that specifies what servers are allowed to send mail with that domain name. You can specify by name, IP address, or even include other domains' info (mycustomdomain.com could be configured to include all of myactualisp.net's SPF info).

This prevents spoofing by stating the valid source(s) of email claiming to be from a domain. It doesn't affect people with their own domain names, it affects people who want to use an email address in that domain, but through some other server. Like if you gave your buddy a custom email address at your domain, and he wanted to use his ISP's mail settings. You'd have to include otherisp.net's SPF info too, so that the email he sent out (from his ISP, with your domain name) would be considered from a valid source.

This would affect you if you were doing the opposite, and wanted to send out mail from your own SMTP server using your ISP's email address. When you sent the email from joeschmoe@myisp.net, it would check with myisp.net's SPF settings. Your own personal server would not be listed in their DNS record, so it would be considered coming from an invalid source.

Even that doesn't necessarily mean the email won't get delivered. It could just be used to crank up the SpamAssassin rating. It could move the mail to a gray area. Or it could go to the extreme and completely reject the mail.

SPF is just a way to say that email claiming to be from a domain can only come from certain places. There's a lot more involved before the recipient that determines how the failed SPF test is handled. Play with the SPF record wizard and you'll get a better idea of what it does.

Since the SMTP protocol doesn't have any authentication of the sender (except within an ISP/Domain with SMTP-AUTH), it's easy for a spammer/virus to send mail pretending to be you. That's called a 'joe-job' after one of the early occurrences of it.
A recently proposed solution (though not without it's problems) is SPF (Sender Policy Framework) http://spf.pobox.com/ where a domain owner can publish the list of servers which are authorized to send mail as being from a user of their domain.
Until it's widely deployed, not just on the publishing side, but on the checking side, it won't be real useful. However it's nearly trivial for the DNS owner to publish the records and since big ISPs like AOL and Yahoo are starting to check them it does protect you from being Joe-Jobbed to a large number of mailboxes.

As long as Microsoft is incorporating SPF into their solution, then it doesn't really matter if few providers use SenderID (as long SPF is widely adopted).

SPF provides the means to eliminate the most egregious spammers by eliminating all emails with forged headers and providing a means to ensure that the sender is complying with the rules set by their ISP. It is simple to implement because it uses already existing features of SMTP and DNS to operate, and it does not need to be adopted "all at once" by every ISP, as it does not interupt mail being sent to/from non-participating ISPs until the provider using it makes that decision themselves. It is also possible for a user (of a participating ISP) to incorporate SPF response into their filters in such a way that it would not eliminate any legitimate mails, and it would still be effective at helping the user to identify spam.

It will help ISPs verify that their users are violating policy by sending spam. It will help make blacklists more accurate by identifying ISPs that permit or encourage spammers to use their services.

Read the FAQ.

As long there is progress toward wide adoption of SPF, there is little reason to argue over Microsoft's SenderID licensing scheme. If their protocol cannot be used with qmail, sendmail, and other high reliability/security servers, it will not be adopted. As long as Microsoft has followed its stated intention to adopt SPF as part of SenderID, then SPF will work for everyone, including those using SenderID.

As long as Microsoft is incorporating SPF into their solution, then it doesn't really matter if few providers use SenderID (as long SPF is widely adopted).

SPF provides the means to eliminate the most egregious spammers by eliminating all emails with forged headers and providing a means to ensure that the sender is complying with the rules set by their ISP. It is simple to implement because it uses already existing features of SMTP and DNS to operate, and it does not need to be adopted "all at once" by every ISP, as it does not interupt mail being sent to/from non-participating ISPs until the provider using it makes that decision themselves. It is also possible for a user (of a participating ISP) to incorporate SPF response into their filters in such a way that it would not eliminate any legitimate mails, and it would still be effective at helping the user to identify spam.

It will help ISPs verify that their users are violating policy by sending spam. It will help make blacklists more accurate by identifying ISPs that permit or encourage spammers to use their services.

Read the FAQ.

As long there is progress toward wide adoption of SPF, there is little reason to argue over Microsoft's SenderID licensing scheme. If their protocol cannot be used with qmail, sendmail, and other high reliability/security servers, it will not be adopted. As long as Microsoft has followed its stated intention to adopt SPF as part of SenderID, then SPF will work for everyone, including those using SenderID.

The SPF/SenderID group understands exactly what it is doing. It is not making the claims you are asserting

• "Second, to handle bounces, I propose a rewriting scheme as follows" -- as Vernon points out, this scheme is terribly broken. It is not a generic solution, and is definitely not going to work globally.
• "Domains that refuse to publish SPF or publish global-allow SPF out of political principle, malice, or incompetence will simply have to accept the penalty of a higher spam score." -- but many domains are simply unsuitable for using with SPF! What about a provider who provides a mail forwarding service, even universities, etc. They want their addresses to be used as return paths outside their own systems. The SPF people are saying that these domains must be punished for their unwillingness to adopt SPF. Internet email is a flexible thing, and there are a zillion instances in which SPF is unworkable.
• "What do the customers want? They want to communicate with their friends and family; and they want to not get spam. They do not particularly care if a few eggs are broken along the way." -- this shows a severe misunderstanding of their own system. SPF does not prevent spam, but rather provides a domain owner with the power to prevent their return paths from being forged. This is very different from addressing a spam issue. It's not a bad goal, but it's not addressing spam.

Your definition is a good one. But it still doesn't make this product the first - or revolutionary. Sendmail created the 'milter' interface many years ago precisely to make this kind of rejection of unwanted mail possible. There are many sendmail milters written in many languages. The most popular being C, Perl, Python in that order. I run a Python milter which removes Windows executables (except DOC and XLS), checks SPF, and checks content with DSPAM wrapped for Python. Of the 40000 spams a day we get, nearly all are rejected before SMTP DATA. Those flunking content check are rejected before the connection closes - except when addressed to a 'screener', in which case it goes to a spam mailbox. Screeners have the task of providing feedback to the Bayesian filter - relieving others in the company of the burden.

All this means is that, as well as the net connection being slow, the processor will be running overtime calculating the checksums. The spammers will send as many emails as ever.

SPF has to be one of the easiest measures we can take to reduce spam. Spamassassin is about to hit 3.0 RC1 and many more of us will be able to easily associate scores with SPF records. As soon as mail has to originate from the correct domain we get better spam checking and a paper trail for the authorities to follow. If you don't have SPF records for your domain, head on over here or here and set them up.

What about using something similar to the Sender Policy Framework (SPF) for web sites. Create a list of known good websites for your company, and if the browser attempts to access something say eBay related, it will look at eBay's SPF list and see wether it's an authorized server or not.

One of the biggest failings of EJB 1.x and 2.x was that there was no standardization around deployment descriptors. This made a mockery of "write once deploy anywhere", because every different combination of application server and EJB container required a different mess of XML files before it would accept your EAR file and deploy your application. Naturally, all these files had completely different tools for generating them, and sometimes the tools weren't driveable from standard build tools like ANT.

Now with EJB 3.x they're promising to make a half-assed attempt at solving the problem. Now you'll annotate your Java code, and the vendors will supply tools to turn the standard annotations into their proprietary deployment files.

So, you'll still have to deal with a mess of different tools, and you still won't be able to deploy the same application EAR anywhere, but at least you'll only have one set of syntax to learn to specify the deployment information, and you'll be able to keep the info in the same place as the actual code. So, a minor improvement.

Other stuff looks to be just as muddle-headed as before. Yay, a new syntax for EJB QL, to make it almost exactly the same as the SQL it was supposed to be a simple alternative to. Of course, nobody in their right minds uses entity beans anyway...

I'm concerned that there is no way to cut all of the SMTP servers out there over to a new mail protocol, even if one is invented. As an example, how easily did the transition from individual hosts files to the DNS system proceed back in the day?

In the mean time, I have been looking at implementing SPF http://spf.pobox.com/. Has anyone else tried that, and has it worked well? I'm wondering if it's going to work very well until more folks start adding SPF records to their DNS servers. I guess as long as the big guns (AOL, etc.) have started doing so, that might reduce the amount of forged messages to a manageable level. Thoughts?

People running mail servers need to put SPF in place and give it a soft-fail until 01/01/2006. That gives everyone over a year to get it ready.

http://spf.pobox.com/

So, the license RMS is ranting about doesn't apply, and there doesn't appear to be another license on the Microsoft site. Having said that the Microsoft license does not stop the distribution of source, in fact there's a specific clause allowing it (2.2), you just have to include a paragraph in the source code. Nor does RMS say what his problem is, aside from "Grrr, it's Microsoft".

Of course the SPF implementation is still "non-licensed", there's no mention of restrictions, although they do point out there are patents all over the anti-spam arena.

But hey, we don't expect people to look at this stuff, lets just add yet another protocol.

So, the license RMS is ranting about doesn't apply, and there doesn't appear to be another license on the Microsoft site. Having said that the Microsoft license does not stop the distribution of source, in fact there's a specific clause allowing it (2.2), you just have to include a paragraph in the source code. Nor does RMS say what his problem is, aside from "Grrr, it's Microsoft".

Of course the SPF implementation is still "non-licensed", there's no mention of restrictions, although they do point out there are patents all over the anti-spam arena.

But hey, we don't expect people to look at this stuff, lets just add yet another protocol.

For this you should ask whoever supports your filtering software. The introduction to SPF mentions that SpamAssassin can query DNS for SPF records.

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/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

earthlink.net. 694 IN TXT "v=spf1 ip4:207.217.120.0/23 ip4:207.69.200.0/24 ip4:209.86.89.0/24 ?all

google.com. 300 IN TXT "v=spf1 ptr ?all"

?all

+all

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/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

earthlink.net. 694 IN TXT "v=spf1 ip4:207.217.120.0/23 ip4:207.69.200.0/24 ip4:209.86.89.0/24 ?all

google.com. 300 IN TXT "v=spf1 ptr ?all"

?all

+all

Not if you control the DNS for example.com.

You need to add a TXT record to your example.com domain's DNS. It should look like this (or similar in some fashion):

"v=spf1 include:earthlink.com a:your smtpserver.earthlink.com -all"

See, when a SPF-enabled receiver reads the DNS record, it's reading the DNS record for example.com. Since you control that, you can allow anything to send mail in the name of example.com that you want. The "include:" bit just tells it to use earthlink's SPF records (if they exist), and the "a:" bit tells it that anything from smtpserver.earthlink.com is allowed as well. The "-all" at the end disallows the rest of the world to send mail in the name of example.com.

Simple. Take a read about it here: http://spf.pobox.com.

Lots of good, calm explanations there. It should be required reading before posting here. ;-)

Lots of good, calm explanations there. It should be required reading before posting here. ;-)

I dont mean this as a flame or anything but, some of you really need to read on how SPF really works. The SPF Wizard should help you understand how it works.

Examples:

You only use the servers listed in your MX records to send mail. The SPF would look like: "v=spf1 mx -all".

A second example would be for people that have large numbers of servers. If they have an A record for every server that sends mail the spf record would look like this: "v=spf1 a mx -all" that allows all servers with an A record to send mail as well as servers with MX records.

Another example is if you use an ISP's e-mail server it would look like this: "v=spf1 a mx include:someISP.com -all" This then refers to the ISP's SPF record wile still allowing mail from any A or MX record for your domain.

My suggestion, play around with the wizard and read on SPF before you say it's not going to work. This implememtation will protect your domains from being spoofed. I think it will work.

Read the SPF FAQ.

It's amazingly easy. There's a little wizard here you can use to set up your DNS.

I did this for my domains in about 5 minutes.

Mine was pretty simple since I send and receive mail through the same hosts (the ones specified in my MX records:

blah.com IN TXT "v=spf1 mx -all"

Seriously just go to the SPF site and use the wizard to create your record.

Spam, like other forms of theft, will never be eliminated. SPF/Sender-ID helps solve one portion of the damage done by spammers and it allows you to safely whitelist domains.

And ultimately, it would only stop spam if every system on the planet adopted it. Otherwise a spammer will simply operate from a host that isn't SPF-compliant.

According to spamhaus.org, there are only a few hundred spamming organizations that account for the vast majority of spam. We don't need everyone in the world to adopt SPF, we only need enough to convince these few people to switch from forging legitimate domain names to using their own. Once that happens, the vast majority of bogus bounces will be eliminated.

Ultimately, this is bad. It makes the largest ISPs, who can afford to offer SMTP and all other services, easier to work with, and the smaller guys have more of an administrative overhead to keep up with DNS management.

I disagree. Most of the people involved in the SPF project are not major ISPs. Most of us think it is a good thing for everyone who uses email.

No, it's just not a solution for everyone.

If you don't publish SPF records, nothing changes. Mailservers are unlikely to reject mail from domains that don't have SPF records for a long time, maybe ever, depending on how broadly used it is.

If you do publish SPF records, you can indicate whether or not your the record describes all hosts that can send mail for your domain. Adding ~all means:

SPF queries that do not match any other mechanism will return "softfail". Messages that are not sent from an approved server should still be accepted but may be subjected to greater scrutiny.

SPF FAQ

How about all the folks that use forwarding addresses like...

See SPF FAQ or read about SRS

How about all the folks that use forwarding addresses like...

See SPF FAQ or read about SRS

It's like anything else, it's just a text record. Use the online SPF generator (it's called a wizard, which should make MCSEs happy), then add a TXT record by right clicking on your domain in the DNS admin, choose add new record, choose TXT and paste the wizard results in.

Three letters for you:

SPF.

This is in my opinion just another patch and not a true solution, but it stops people from claiming that they're from your domain and quite a few large ISPs observe SPF now (AOL being one of them)

But yeah, the parent poster was absoultely right. Coding in zillions of special cases and heuristics and different authentication protocols won't help. An internet with pervasive IP-level security and a federated set of PKI roots backed by an agreed on Internet Constitution drawn up by We The Fucking People (as opposed to In Disney We Trust) is the long term goal.

I'm not a DNS guru, so can someone use crayons with me -- how do I actually go about registering my domains to support SPF on outgoing mail? There's this webapp for creating the text of the SPF record, but then what? Would the registrar have to provide a mechanism for me to add the record? The web host?

I can only speak for sendmail, but none of the sendmail solutions link in any libraries to sendmail. Every solution uses a sendmail milter. The milter process is started independently of sendmail, and does not required access to any files or privileged network ports - so it runs as an isolated user id. The only I/O required by an SPF milter is TCP for the milter protocol, DNS queries, and perhaps a log file. No patches to sendmail are required.

You may be confusing SPF with SRS, which cannot be fully implemented in sendmail via a milter. However, SRS can be securely implemented for sendmail via a socket map in the latest versions. A patch to support socket maps in older sendmail versions is available - or you can use the (horribly innefficient but workable) solution of a program map.