Slashdot Mirror

SPF. Several proposals have been rolled up in this, under ASRG, including SPF, RMX, DMP, and related proprosals.

http://spf.pobox.com/

This is exactly why SPF is being created.

They are not creating a whitelist of everyone who sends email to AT&T Customers - You are right that would be a mess

They are whitelisting their customers SMTP servers so no one can send spam FROM AT&T's network.

They are implementing a Sender Permitted From type of system

dave
--> stuff

This should reduce spam as it will be easier to track the spammers and hassle them with legal threats or at least get their ISP to shut them down. (Or black list the ISP) See the link above for the full details

dave
--> stuff

Check out SPF. Was posted on Slashdot a couple of weeks ago.

Sender Permitted From, a handy little concept whereby DNS servers for domains publish lists of what servers are vouched for, so to speak. By only accepting email from servers which implement SPF, you reduce spam a lot. With SPF, if anyone is doing spam, it's very traceable and prosecuteable. You also cut down on people trying to fake identities.

If everyone implements SPF, it'd solve this problem in a fairer way.

There are several initiatives underway to use DNS to authenticate SMTP transactions: this seems like a good way to avoid the nastiness described by the parent poster...

• http://spf.pobox.com/draft-mengwong-spf-01.txt

• http://www.pan-am.ca/draft-ietf-asrg-dsprotocol-00 .txt

• http://www.ietf.org/internet-drafts/draft-danisch- dns-rr-smtp-03.txt

Pixie

Yes, we do desparately need sender authentication.

But before you go calling strong crypto-based authentication "realistic", consider the resistance that even simple IP based authentication has met. I'm talking about SPF (covered recently by slashdot), and similar RMX and DMP which are basically the same idea implemented slightly different.

A massive number of very vocal people (though likely not a majority of all users) forge their headers, for legitimate reasons. Common is someone with several email addresses, who wants to be able to send "From" any of them, using their ISP's SMTP server. Many organizations also have not properly set up SMTP servers for their members, and instead simply have them send email through an ISP or some other server. There's plenty of other cases where the Sender/From info is forged for legitimate reasons, usually because "it works" and was easier than setting up proper outgoing SMTP.

A transition to even these weak yet very compatible proposals is a daunting task, because spammers aren't the only ones taking advantage of the easy forgability of email headers... on a grand scale.

Based on a pre-existing fan-produced translation, I produced my own... if people are at all interested in reading it. I also talk about various translation issues I dealt with (or didn't deal with) in my "Notes and Reflections" page.

The hardest parts, for me, had less to do with cultural differences, but with linguistic differences where a Japanese expression was extremely compact and difficult to express in English, given the time constraint (one could argue that this is due to a cultural difference). One of my goals was to try and come up with something that could potentially be used for dubbing.

Of course, the opposite problem, where the Japanese phrase is longer, is not an issue, because it's always easy to make something more wordy.

Legal characters in domain names are letters, digits, and the hyphen ... rfc1035

From the site:

Apparently underscores are now okay. See RFC2181 section 11.

For one thing, these DNS entries are not A or CNAME entries and do not name hosts.

So now I (Joe Spammer) connect to your SMTP server and deliver you some SPAM dressed up as a helpful undeliverable notification (i.e. a bounce).

From the site:

SPF will not work for the null sender address <> which mailer-daemons use. This is easy, though: you just have to take apart the bounce message and extract the original message that bounced. If the Message-ID is known, the bounce message is valid. If it's not a bounce message, it's spam. MTAs can do this, and MUAs can do this.

gotcha - I didn't look at the research groups (never have actually - looks like good stuff there) The anti-spam research group should have more promanence on pobox's site

From the SPF Page
"I have someone coming from a certain IP address. They claim to be a certain sender. Are they for real?"

This at the top of the explanation page, and as far as I can tell, is already broken. This is because it assumes that you can tell where a message is coming from. This is true if the sender wants you to know where it's coming from. However, IP address spoofing is quite easy. Simply put an IP address other than your own in the source field of an IP packet header. In this case, you'd use an IP address that was on the "permitted" list.

Basically, RMX has to critical flaws. First, it requires a new DNS resource record type, which is going to require everyone to upgrade their name servers if they want to use it. Secondly, there is a limit to how many resource records can be sent in a UDP packet and many important ISPs such as AOL, MSN, Yahoo, etc., have far to many. If I recall correctly, there are several thousand(!) IP addresses that Yahoo will send email from.

RFTA

Section 6.1 of their RFC covers this.

Briefly:

RMX allows the recipient to look up information using a greater range of possible keys than just the sending IP address;

SPF reuses a pre-existing part of the DNS (TXT records) rather than adding a new RR type as RMX does;

the design of SPF lets the spoofed domain's admins know who's spoofing their address (because the spoofer's IP address is part of the lookup).

This type of approach doesn't sound totally rubbish - but I'd be happier if ISP's would ALL impliment anti-spoofing filters on their routers as in RFC2827.

Add a TXT record in your domain's DNS saying that senders are permitted from your ISP's SMTP server. See Setting up SPF.

The central idea behind reverse-DNS/MX proposals is to answer the following 2 questions:

1. Does a particular domain have a list of authorized IP addresses that are allowed to send out e-mail on behalf of the domain?

2. Is the IP address of the mail server that is attempting to talk to me on that authorized list?

The devil is, of course, in the details/implementation. (Can we do it without breaking older versions of BIND? What attacks is it suspectible to?)

Here's the (4) proposals that I know about (since I just went looking yesterday):

RMX proposal - No news on Mike Rubel's page since June 2003. Not much on the official home page either. The last published draft is June 2003.

DMP - Last IETF draft published Aug 2003 and expires at the end of Sep 2003. However, version 5 of the document has not yet been posted and the author(s) does not have seem to have a central site to check for news.

DRIP - Last draft was published July 2003, expires Dec 2003. I don't see anywhere a central home page to check for news.

SMTP+SPF - Last update was mid-July 2003. I'm not sure if there is an IETF draft being floated or not.

Just don't think that you will be able to eradicate spam without governmental help.

The problem isn't lack of government enforcement. The problem is lame standards for passing email.

We don't need a legislative solution, we need a technical one.

This is one I support.

I haven't seen SPF being mentioned yet.

It's a sistem whereby you, the domain-owner, via DNS records, explains what SMTP-servers (their IP adresses) are allowed to send email with your domain in the From: header.

To me it really does look like a way to kill spam, if it were adopted.

Here's the current list of the 4 proposals that I know about.

RMX proposal

SMTP+SPF proposal

DMP proposal

DRIP proposal

All (4) of those perform pretty much identically, with various trade-offs. The 2 key questions that an SMTP server needs answered are:

- does this domain have reverse-MX information?

- is the origin IP address authorized to send e-mail for the purported origin domain?

And possibly a 3rd question for farther down the road (although this is possibly over-kill):

- has the e-mail been properly signed by the sender of the e-mail

IIRC, NSLookups fail because it makes the assumption that everyone is in control of their reverse IP info and that people don't service multiple domains from a single IP address.

And how do you verify that the "FROM:" address is actually in the network being served?

SMTP+SPF

I WIN

My point was that naive implementations that rely on accurate From headers will occasionally break in the real world, not that you can never trust that header.

(I'm an SPF fan, though I do confess to yelling at "You sent me Sobig.f!" messages. If you know enough to identify Sobig, how did you fail to discover that it spoofs the From header?)

There are currently (at least) 4 different proposals that I know about to end the process of domain spoofing (which is part of the battle).

RMX proposal

SMTP+SPF proposal

DMP proposal

DRIP proposal

What that hell is this?!?!

These exactly disclosures were available on the day of the G5 launch. The link with the raw data is here:

Veritest PDF

And you can find a thorough debunking of the whole thing on my site here

This is very, very old news.

Developing a way to be able to trust the origin of email is the way to end the spam crisis.

In another recent thread, a suggested enhancement is for DNS to publish "allowed sender IP" addresses. The structure for this information is already there.

What is needed is for more people to opt in, in protecting their domains in this way, and for people to unilaterally start using that information. If any one of yahoo, aol or netscape opted into this approach I could well imagine it would cascade to comprehensive success overnight, forcing spammers to more obscure domains (such as my own - currently victim to a 12 month "Joe Job").

Because this is distributed information, it is not easily modifiable by spammers. Ultimately this sort of approach is the only one that can work.

Ultimately, I would be able to set spamassassin to add +5 for any e-mail coming from a domain that didn't publish this information, or -5 for any one that did.

And I would not be receiving 1000's of bounce messages for messages from spammers using my domain name.

Yes please. I want it.

Isn't that exactly what SPF is supposed to control?

the site explains quite clearly it is to avoid spammers (from unknown IP adresses) from claiming that "From" (or "ReternTo: ") adresses are inside your domain.

I was actually thinking about this today after my boss got nailed by SoBig.F and started sending out all sorts of spoofed email. After digging through previous slashdot stories, I think the first step to make things a hell of a lot saner can be found here.

SMTP+SPF is an idea long overdue in production. The owner of a domain should have the right to dictate which IPs are allowed to send mail its name, and blacklisting becomes a lot more meaningful with that right IMHO. If servers maintained & endorsed by a domain are spam havens, just do away with the domain. No more banning entire subnets with all sorts of collateral damage on lots of different parties. And given the substantial control that can be exerted over a mail server, I believe there is a far slimmer chance a responsible domain would get blacklisted on the account of a few bad apples.

Granted, spammers will still be moving targets, and domain registrars will have their pockets lined by them, but I rather sully a jibberish domain than useful & easily transferred IP addresses.

I was actually thinking about this today after my boss got nailed by SoBig.F and started sending out all sorts of spoofed email. After digging through previous slashdot stories, I think the first step to make things a hell of a lot saner can be found here.

SMTP+SPF is an idea long overdue in production. The owner of a domain should have the right to dictate which IPs are allowed to send mail its name, and blacklisting becomes a lot more meaningful with that right IMHO. If servers maintained & endorsed by a domain are spam havens, just do away with the domain. No more banning entire subnets with all sorts of collateral damage on lots of different parties. And given the substantial control that can be exerted over a mail server, I believe there is a far slimmer chance a responsible domain would get blacklisted on the account of a few bad apples.

Granted, spammers will still be moving targets, and domain registrars will have their pockets lined by them, but I rather sully a jibberish domain than useful & easily transferred IP addresses.

See http://spf.pobox.com You can publish your DNS now, indicating which legitimate IPs are in use for mail from your domain.

C/R also suffers when it comes to mail lists... the response is usually that we can just whitelist the mailing list domains.

Except that spammers can forge their domain to match that of a domain that is on the whitelist.

SPAM is a multi-facted issue... one of the first facets that I hope gets taken care of before we all grow old is that the IETF approves one of the RMX / SMTP+SPF style proposals and eliminates "joe jobs" and forged domains.

>> ISPs' incoming servers accept mail only if the "sender:" matches the domain of the server that is sending the message

Which is exactly what proposals like RMX / SPF and others are attempting to do. Since the DNS system is already used to designate which IPs will accept inbound e-mail for a particular domain - why can't DNS be queried to find out if a given IP is authorized to send e-mail for a particular domain.

Explanation of RMX
SMTP+SPF proposal

As a side-effect of the RMX/SPF style systems that a given e-mail comes from an authenticated IP for the purported domain is that e-mail worms will find it more difficult to spread directly from infected systems straight to target SMTP hosts. Instead, those worms will have to spread by passing through the user's official SMTP server.

Try publishing SPF data in your zone(s) and hope the rest of the world starts using it. If that happens, your forgeries should go way down, since they'll be coming from systems that are not authorized to send mail as your domain.

Note: I set this up on my domain about two weeks ago, and a fair amount of mail goes out from here to various mailing list subscribers. So far I haven't logged so much as one query for the SPF data. It's still very much in larval stage.

• cuts spam and
• stops email address forgery
• when domain owners designate sending mail exchangers in DNS, so that
• SMTP servers can distinguish legitimate mail from spam
• by verifying sender domain against client IP
• before any message data is transmitted.

Well, people are not working on it, you can download it now already! :-)

See http://www.pobox.com/~berend/emc/ for more details.

If you want a Bayesian tool that works for an IMAP server, try emc: http://www.pobox.com/~berend/emc/.

This tool builds your spam token list by scanning IMAP folders. It's a command-line tool, binaries for Windows and Linux.

You will download the first release, so it might have undesirable properties. A new release is expected soon.

You will find both methods, and other spam related things, described on a web page on the subject I created in 1997.

Fastmail.fm has a nice tagged email feature using subdomains - not only can you get mail at username+tag@fastmail.fm, but tag@username.fastmail.fm translates to the same thing, so you can give everybody an email address like that and trash any addresses used by spammers. Like many of the newer web mail systems, they also let you retrieve mail from them with IMAP, and can fetch mail from other systems with POP or IMAP.

I haven't actually gotten rid of the Netcom->Mindspring->Earthlink dialup account I used back when I got the pobox.com account, though with broadband and work-provided dialup for my laptop it's about time to.

Its just like the Raeleans told us. They are monitoring us in flying saucers piloted by clone babies.

Gooooogle girl!

That page is old, and not kept up to date. Try this one for some more exotic, well explained and up to date stuff.

Here you go

• PC's do not have correct color output, and never will. No matter high end the PC, the colors never look "right" or balenced on the screen.

I still get spam addressed to my old company's two old obsolete domains (I can't persuade them to turn that off!), plus my old company's current, my current company's current address (I transferred from a subsiduary company, so get to see both email servers) and now both companies are in the processes of changing their domain names again, so it looks like another two servings of spam for me.

Fortunately, I use filters which catch 90% of the 25 or so daily spams.

As comparative data points, my home email (freely used in Usenet, etc) gets about 50+ spam per day, but as I use POBox.com, they kill 75% at the server, and another 20% gets forwarded with a spam tag, to get binned at my home PC.

Oh, and my Hotmail address (an obvious [firstname]_[lastname]) gets almost zero spam, filtered or unfiltered - I think I get more messages from M$ than junk (well, non-M$ junk anyway!)

Eiffel is a language with an minimal instruction set (sometimes refered to as RISC language), which is used mostly in environments that emphasize reliability and dependability. It's small instruction set (e.g. there is only one type of loop) make it easy to learn and understand but is taking away some of the fun of coding. Most of the work you put into an eiffel project is to find the right approache, because you don't have too many ways to implement stuff. Here in Europe it's used in mostly academic environments that like the grace of its simplistic approace and its 100% object oriented design.

Tradeoffs of this language are its high compilation time, as Eiffel source gets translated to C and then into a native form, the scarcity of available system libraries and the lack of dynamic features as shared objects and stuff.

If your going to invest some time in this language, a look at those open source projects might be worthwhile:
eposix - POSIX bindings for eiffel
gobo - a collection of tools and libraries to unify the development of applications on diffrent Eiffel compilers
mico/e - a CORBA ORB in Eiffel (DISCLAIMER: I am involved in the development of this project)

The damn thing doesn't work. I am an artist of reasonable skill (see?) and so tried it out. I attempted the following:

1. A hand with index finger extended.
2. An upright pyramid.
3. A cylinder.
4. A sphere.
5. A skull.

I also put the obvious thing into the text field. It failed to find any match for any of these. The hand and skull, I understand. Missing the pyramid was disappointing, but not matching either the cylinder or sphere?!?! Forget it -- this thing is garbage.

Hi, I have the source you're looking for, but I'm not sure I have successfully demunged your address as per your instructions. Please confirm (I have listed it several times in case a portion of your browser screen is garbled, should you have a bug in your video card driver):

Once again, please confirm that your address is zeugma@pobox.com and I'll send the source to you right away. Thanks!

Hi, I have the source you're looking for, but I'm not sure I have successfully demunged your address as per your instructions. Please confirm (I have listed it several times in case a portion of your browser screen is garbled, should you have a bug in your video card driver):

Once again, please confirm that your address is zeugma@pobox.com and I'll send the source to you right away. Thanks!