IETF Approves SPF and Sender-ID

NW writes "According to the records in the IETF's database (here and here), both the SPF and Sender-ID anti-spam proposals were tentatively approved by the IESG (the approval board of the IETF) as experimental standards. It remains to be seen whether any of them will actually put a dent into spam." At the same time, the FTC has opened a central site about email authentication.

Comments

Did IETF change their mind?

[ravenspear]

I thought the IETF had already rejected Sender-ID because it was MS proprietary.

Zombies anyone?

[dancpsu]

What's to stop the spammers from using a zombie to fake the sender id? It's a good step forward (you would know where the zombie was), but the bigger challenge would be to have some kind of capability to restrict mail servers to authenticated ones rather than some kind of recipient call-back mechanism. Otherwise the future of email will be "sender ID from mail server ZOMBIE294346.earthlink.net"

Microsoft related?

[john_is_war]

Hmm... Microsoft announces hotmail will be restricted to user-ID and now it's been passed as an experimental phase. Coincedince? I think not.

It's one SMALL step

[realmolo]

Both SPF and Sender-ID solve only one problem: faked sender domains.

That's a problem that needs to be solved, but it doesn't account for a lot of spam, and spammers will just stop faking domains in their mass emails.

What we need, and what will NEVER happen, is a central database of mailservers. If you aren't in the "registry" of legit mailservers, then other mailservers won't accept your mail. To get in the registry, you'd have to pay a fee, and prove that your server are secure, and that you aren't a spammer. Obviously, each "legit" server would have to append some kind of digital signature to outgoing emails, so that the verification coudl take place.

In other words, a total revamp of the mail system protocols. ;) We can dream.

Re:It's one SMALL step

[tolkienfan]

How do you figure you can prove you're not a spammer?
Better is to allow your approval to be revoked, if you are initiating spam.
Plus, the cost of such a system would be prohibitive to say the least.
Who would be resposible? A US company? And I assume all the other countries are just dying to subscribe to that system!

I think a protocol change is in order. Instead of sending the message via SMTP, only send a notification that an email is waiting to be picked up, and it's location. When your email is checked, it loads the email from the server.
This has the following benefits:

1. The cost is on the sender. It would be prohibitively expensive to send millions of messages - you'd have to host all the clients!
2. Zombies would be useless - systems are likely to be behind firewalls now (hardware and software), so incoming email clients would be rejected.
3. It could be rolled out based on current protocols. SMTP could be used for notifications. 1 notification per email, max of 1 notification per 20mins - reset on check? Check email via POP3. Not IMAP since you want to actually retrieve the message.

There are some kinks, but I think it's workable.

Re:It's one SMALL step

[Wesley Felter]

In bonded sender systems, you would put up a large (>$1,000) bond (like a deposit). If any spam comes from your server, you'd lose the bond and your certificate would be revoked, so you couldn't send any more mail.

Exploiting the weaknesses of such a scheme is left as an excercise for the reader.

SPF in the real world

[SamMichaels]

I honor spf entries on my mail server. It stops about 1000 emails/day. So far no legit mail being bounced.

Re:I'd love to see an Apache Project mailserver.

[finse]

Postfix, a truely awesome mailserver

Postfix is fast, flexable and easy to use. In my mind, there is no better mail server for Unix and Unix like platforms.

Re:Not about spam, it's about joe-jobs.

[xstonedogx]

Except you don't have any control over it. I can set up an SPF record for a domain, but if they don't look at the record on the other end, it does me no good. As you suggest, my server may still have to deal with "the mass of bounces and spam reports from clueless admins." Not to mention, servers that just mark this as "spam" and send it on to the end user aren't doing me any favors. The end user doesn't know I'm not the one spamming them.

I think this is about spam. I block spam using SPF all the time. SpamAssassin includes SPF support. It's just about a specific type of spam. If SPF became widely implemented, you could block anyone without a valid record. Folks still spamming get blacklisted, because you know it's coming from their domain. It wouldn't stop spam completely; spammers can always create new domains or use legitimate email accounts via zombie machines. But it would help.

On the client end, SPF can be used to detect phishing. Thunderbird has an extension for just that purpose.

Re:Um, no.

[taustin]

You are completely, totally, and entirely incorrect, and know nothing about the situation.

We are 100% SPF compliant. Tested and everything. The server we send through is on the only IP address allowed in our SPF record.

The address we send to is a virtual domain that does not offer POP3 mailboxes, only forwarding service. This is not under our control. It forwards to a third domain, also not under our control, that rejects based on SPF, because the second server - the forwarding service - does not rewrite the MAIL FROM address (and is not supposed to, so far as I know, under the RFCS).

All three machines are 100% compliant wit the RFCs, and the two using aspects of SPF are 100% compliant with those specs. And yet, legitimate email is being rejected.

And the only way around it is to misconfigure the server not using any aspect of SPF to violate the RFCs regarding how email is supposed to work.

Or, even better, use -all on our SPF, and thus explicitly enable precisely the kind of forgery that SPF is supposed to prevent.

That is the very definition of a broken system.