FTC Email Authentication Summit

gal1264 writes "The FTC is hosting an email authentication summit today and tomorrow in Washington, DC conveniently happening at the same time as the IETF meeting in the same town. Today mainily was comprised of an overview of the various outstanding proposals. It was interesting to see the whole crowd cheer as the Yahoo representative reiterated that their proposal was full open, much unlike the recent Sender-ID proposal which caused great furor in the IETF MARID working group as well as the open source community. It does seem however, that all of the participants were excited to be testing various techniques (personally I found the Bounce Address Tag Validation very compelling) and were communally comitted to converging on the most effective solutions without anything other than defensive patent structure."

Comments

lunchtime

[BortQ]

I hope they served SPAM for lunch.

Re:lunchtime

[Anonymous Coward]

I hope they served yeast. A feast of yeast.

Re:lunchtime

[Anonymous Coward]

I demand that moderator's accounts be revealed if you click on their moderations, so I can see the moron who thought that was offtopic.

Re:lunchtime

[BortQ]

I second that motion.

Re:lunchtime

[Anonymous Coward]

I demand that moderators' accounts be revealed if you click on their moderations, so I can see the moron who thought that was at all funny or even worth reading.
Really, had nobody made the connection between SPAM the product and spam the junk email before? Ooh, it sure would be funny if they served a food that carries the name of something they all surely despise. *post*

Re:lunchtime

[Anonymous Coward]

I hope they served SPAM for lunch.

With worms and a virus.

Too many possibilities?

[Rikus]

I see at least five proposed systems on that page, and I'm sure there are others in existence. It's usually good to have a variety of things to choose from, but it seems like it will be difficult to get any one system fully accepted when there are various different advantages and disadvantages associated with each, especially since some people have already decided on SPF, Domainkeys, or other options.
It's quite convenient that almost any mailserver speaks SMTP, but I wonder how long it will take before every mailserver uses the adopted sender authentication system.

Re:Too many possibilities?

[Anonymous Coward]

already decided on SPF

That is where I am at. If you look at the proposals, it does not include SPF which is a real surprise. It makes the think look like an IETF love'in. Maybe they should put trojans on the side of the plate of spam for lunch?

SPF is at http://spf.pobox.com/. It has several advantages, most big ISPs now support it, you can verify this by doing an nslookup on the domain.

nslookup -query=TXT aol.com

aol.com text = "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"
aol.com text = "spf2.0/pra 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"
d

Re:Too many possibilities?

[james_couzens]

I'm from the SPF project. There is a forwarding problem. SRS was developed. I wrote a library for it. SRS failed (ugly, but working solution, not very popular). So I got together with some friends and developed SES (http://ses.codeshare.ca) which operates fully independantly of SPF or any other technology, does NOT publish information in DNS (but can make use of an SPF modifier to facilitate such) and provides better protection than DK and IIM combined. We will be releasing an RFC Draft through the IETF-CLEAR working group headed up by Dave Crocker who is pushing BATV which is literally what SES was 6 months ago amusingly enough.

DK might be open, but its the wrong way to go, it puts the burden upon the recipient. This is a DoS attack waiting to happen. I hope to prove this via a "controlled experiment ;-)" just to make a point.

The more choices there are, the better, and it means that there is a healthy amount of attention being placed on this important issue. Unfortunately the greedy want to rush... SES is already deployed by two members of the development team and I finished the C implementation with qmail and sendmail patches today and I hope to release soon. Give it a look if this floats your boat.

For the last time...

[wan-fu]

... the parts comprise the whole and the whole is composed of parts. There is never a reason to use "comprised of."

Meeting summary, Part 1:Wired-style.

[elvey]

I was there. My take: SenderID was a meme on the decline - several large entities and several small entities gave it the thumbs down; several large entities (all D.M.A. members, I think) gave it the thumbs up. Rikus: the place was abuzz with SPF discussion: it got several thumbs up and several thumbs down. CSV, SES, BATV were new and on the rise - no thumbs down. AOL committed to using CSV. (In the sense that they're 'using' SPF today) and got several other thumbs up. BATV got several thumbs up, SES got a few thumbs way, way up.
A lot of folks expressed serious concerns about deployment complexity. It was pointed out that the different proposals have vastly different footprints and initial and ongoing support costs and motivations driving early adoption, which will dramatically effect effectiveness and deployment trajectories and costs. Most of the proposals will require millions of end users be walked through changes by their support staff, and this dwarfs all the other costs being considered, including even the cpu costs of crypto and the cost of record creations. However, this isn't an issue that affects most of the entities represented. It worried the small biz reps a lot.
I'll post more details soon!