A couple of weeks ago, I published my first Internet Draft to the Internet Engineering Task Force (IETF). Today, I updated it, making it version 2 (but named version 01.txt). It is titled Recommendations for the use of whitelists for email senders transmitting email over IPv6.
Here’s a quick synopsis:
That’s my Internet Draft in a nutshell. The Internet Draft contains a few more details but this hits the main points. I’ll also be talking about this plan at the Virus Bulletin conference in Dallas later this year.
But for now, please feel free to read my Internet Draft and send me feedback. The email community has been pitching this topic for a while now, this Internet Draft (and hopefully future RFC!) formalizes it.
Whitelisting could be part of acceptance though there are security concerns.
Last year we blogged about our (Halon Security) approach and ideas, http://www.halon.se/node/261 .
We have many customers using IPv6 and try to push Virus Bulletin to bring up focus around IPv6.
Thanks for your comment, Jonas.
Most email receiver aren't thrilled about receiving email over IPv6 for the reasons you mention in that link, and most also have the attitude of "Create a list and hope for the best." I don't that scales because it will work for some spammers, but not the really clever ones. I'm more confident in our ability to create a better spammer than I am in achieving the best results I am hoping for.
Wouldn't it be better to have some form of SPF/DNS based txt record type scheme to allow senders to stipulate which IP6 addresses will be used to send email from their domain? That way the "whitelisting request" is done dynamically in realtime with no recourse to phone/regular mail. If you trust their domain then you can trust their IP6 address just as you can trust their IP4 address to send from their domain. All you need is a new text record to specify the IP6 addresses allowed to send from a given domain. In this way people wanting to move to IP6 can just accept email from those domains they trust with an SPF record. So the receiver just specifies all the domains they already communicate with as requiring SPF (IP6) records. The sender can then manage their IP6 addresses themselves without having to notify anyone explicitly.
The alternative results in a strange new email ecosystem where the big senders/cloud based email systems can send to each other over IP6 whilst any smaller businesses can never move to IP6 as they will never be able to contact everyone they need to in order to be get whitelisted.
Personally I still don't understand why SPF isn't compulsory for sending email. At least it allows domain and IPs to be tied together in some way, and allows trust to be managed on the domain level instead of the IP level, which is way too technical for most users/sys admins and results in the problems you describe with larger and larger lists of IPs being required.
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(X) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(X) It will stop spam for two weeks and then we'll be stuck with it
(X) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
(X) Many email users cannot afford to lose business or alienate potential employers
(X) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
(X) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
(X) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
(X) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
(X) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your