FTC Wants Comments on Email Authentication
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.
Is to keep email easy to use. SPF is a nice idea, but doesn't cope with a couple issues. The first is that a lot of SPAM comes from trojan'd machines. SPF won't prevent or help mark email coming from these machines as SPAM. Secondly, its not expensive to register a domain and flood SPAM for a few days until that domain is blacklisted. Wash, rinse, repeat. I'm not saying a solution isn't out there, just nothing that I have seen really talks to these two issues.
You know, I can't figure out why we can't combat spam by making it illegal to send unsolicited ads via email (or maybe the can-spam act already does this), but then go after the companies who are actually trying to get customers. After all, they either provide valid contact information, or nobody can buy from them. If nobody can sell anything via spam any more, the reason for it would go away.
Have you read my blog lately?
Just use ident. Maybe return a little extra information, like an "@sitename" suffix.
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.
Assume I was drunk when I posted this.
An effective stop gap measure would be for ISPs to block port 25 ( along with a number of others ) outbound by default, and open it up only on customer requests.
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.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Every eMail that is sent (by SMTP - the Simple Mail Transport Protocol) should be considered "unconfirmed." This means that it may or may not be from the return address.
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!
Drat! I'm gonna get modded for flamebait but with a sig like mine, who'd notice?
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
There was no mention of sender pays postage as a solution. Anything that prevents anonymous email has an inherent central control which the internet doesn't need more of.
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"
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Seeing that about 75% of mail is handled by open source mta's, they can't afford to go with ip, moneygrabbing, patentfilled solutions.
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.
home
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.
SPF support for most open source mail servers can be found at libspf2.
Yeah, a few of the webmail providers do exactly what you're talking about. They generally call them "temporary addresses".
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.
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.
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