FTC Wants Comments on Email Authentication 208
An anonymous reader writes "Groklaw has the scoop. The Federal Trade Commission and National Institute of Standards and Technology (NIST) will co-host a two-day 'summit' November 9-10 to explore the development and deployment of technology that could reduce spam. The E-mail Authentication Summit will focus on challenges in the development, testing, evaluation, and deployment of domain-level authentication systems. The FTC will be accepting public comments until Sept. 30, 2004 via snail-mail or email (authenticationsummit at ftc.gov). The FTC has a list of 30 questions they would like answers/comments to. The list available in this PDF of the Federal Register Notice." In a related subject, reader Fortunato_NC submits this writeup of the sequence of events that led to Sender-ID's abandonment.
The Hardest Issue (Score:5, Interesting)
Why not go after the merchants? (Score:5, Interesting)
RFC1413 (Score:2, Interesting)
Yes, it would require immediate global adoption, but not if you just assign a higher score (towards spam) to messages that came from sites with no identd running.
Re:Why not go after the merchants? (Score:2, Interesting)
Spam is here to stay no matter how much fucking legislation is out there.
A stopgap measure (Score:5, Interesting)
This way, zombie'd machines wouldn't have a chance to spew their virus/spam emails to everyone, I could still run my home email server, and the ISPs would save on bandwidth.
I wonder why this ISN'T yet in place, to be honest.
Here's the system... (Score:3, Interesting)
I propose that we add a new layer called CMTP - the Complex Mail Transport Protocol.
CMTP simply takes an unconfirmed eMail (sent by SMTP) and sends a packet back to the sender. This packet asks for verification of the message. The packet includes a checksum, the length, to, from, subject, and the time/date that the eMail was sent.
The sending mail server receives this CMTP checks all of that information, and replies with a CTMP confirmed message or a CMTP not confirmed message.
There is no limit on the number of times that a mail server may be asked to confirm an eMail. There is a limit that messages should not be confirmed more than 24 hours after they are sent. This may pose a small problem in that SMTP does not place a time limit on mail messages.
CMTP does require that every mail server maintain a list of the eMail it has sent. That COULD be time consuming.
CMTP also adds 2 packets to every eMail sent. SMTP was designed to be dead simple. They thought that they could not afford 2 extra packets. In that time, eMail was 80% of all internet traffic. Today, eMail is such a small percentage of all traffic that trpilling it would not be noticed.
Andy Out!
Re:Why not go after the merchants? (Score:2, Interesting)
Enough with the rest of the world crap - it all starts here:
10097 Cleary Blvd, Suite 203, Plantation FL 33324
and here:
ESI, 5072 N. 300 W. Provo, UT 84604
and....you get the picture.
As if you didn't already know this was important.. (Score:4, Interesting)
Drat! I'm gonna get modded for flamebait but with a sig like mine, who'd notice?
No mention of sender pays (Score:4, Interesting)
Re:NOTHING but an open standard. (Score:5, Interesting)
And I get 1800 a day. That's because I am the public contact for several companies with some of my email addresses dating back over 10 years. In conjunction with theater groups and businesses, my email appears in press releases, on fliers, ancient usenet posts, and otherwise all over the place.
Individuals using their email account to talk to friends don't have as much a problem as people who use their email address publically for business and publicity.
My phone number and address are also published. I don't, however, get 1,800 unsolicited calls every day and my junk physical mail is quite reasonable.
--
Evan "I'm not even saying Spam is bad, I'm just saying it costs me serious time"
Re:No Free Software radicals allowed (Score:4, Interesting)
The only standard that will get accepted will be an open, patentfree one supported by the free software community.
Any closed or patented ones could only be used between the commercial mta's, so it would have little effect on the amount of spam.
Re:Publish SPF now, be the 126519th... (Score:5, Interesting)
I'd like to know how many of those domaines actually are applying effective policies.
In the survey of the .COM domains, I found the top ten SPF records to be:
159416 "v=spf1 mx -all"
147883 "v=spf1 -all"
51245 "v=spf1 ip4:10.0.0.0/24 ip4:10.0.0.0/24 ?all"
28206 "v=spf1 a:smtp.example.net -all"
21437 "v=spf1 mx ip4:10.0.0.0/19 ~all" ""
19733 "v=spf1 mx ~all"
15245 "v=spf1 a:smtp.example.com ~all"
9488 "v=spf1 ip4:10.0.0.0/24 mx -all"
6371 "v=spf1 ip:10.0.0.0/24 ip:10.0.0.0/27 ip:10.0.0.0/24 ip:10.0.0.0/27 ip:10.0.0.0/27 ip:10.0.0.0/27 ip:10.0.0.0/27 ip:10.0.0.0/27 ?all"
5842 "v=spf1 ip4:10.0.0.0/24 -all"
(I have munged the domain names and IP addresses for privacy reasons.)
As you can see, it is very common to define strict SPF record with the "-all" at the end. Those domains that use the softfail option of "~all" are somewhat more lax, but still moving in the right direction.
The complete survey results are available to people who follow the IETF MARID list and/or the SPF discuss list. I'm not going to post a link to them here 'cause I don't want to be slashdotted.
Re:Spam solution (Score:3, Interesting)
It works, but it makes using email more complicated, and it creates a situation where even MORE e-mail traffic is going to be flying all over the place, mostly to all those diabled temporary addresses.
What we really need is a single registry for email servers, similar to how DNS works now. If you want to run a mail server (and not have your mail rejected by other servers), you need to "register" it with some big, monolithic organization. If you're not on the authorized list, you get rejected.
Yeah, that kills the "openness" of email. You'll no longer be able to setup a usable mail server without jumping through some verification hoops. But so what.
Re:NOTHING but an open standard. (Score:3, Interesting)
And this, my friends, is the real cost of SPAM. It's not about the bandwidth, it's about the lost business.
In my business, the cost of a losing a customer because of miscommunication far outweighs the cost of the bandwidth SPAM uses on my server. If customers/reviewers/resellers get lost in the flood of SPAM it costs me money.
And then there's the cost of having someone spend time weeding through all the crap (SPAM identification tools help, but human intervention is still needed for false positives, etc.)
It's good to see that the FTC is getting involved -- this is a business/trade problem, not a communication problem.
-ch