why IPv6 isn't ready for prime time, SMTP edition

Laszlo Hanyecz laszlo at heliacal.net
Thu Mar 27 18:21:11 UTC 2014


Scott,

You are exactly right, in the current environment the things I'm suggesting seem unrealistic.  My point is that it doesn't have to work the way it does today, with the webmail providers, the mail originators and the spam warriors all scratching each others' backs.  There has been a LOT of work done to make webmail easy and everything else practically impossible, even if you do know how it works.  

What if Google, Apple, Sony or some other household brand, sold a TV with local mail capabilities, instead of pushing everyone to use their hosted services?  If it doesn't work because we are blocking it on purpose, customers would demand that we make it work.  Since this isn't a well known option today, casual (non tech) users don't know that they should be demanding it.

As far as why someone would want an MTA, it doesn't take long to explain the benefits of having control over your own email instead of having a third party reading it all.  The problem is that instead users are told they can't have it.  MTAs are built into every user operating system and they would work just fine if the email community wasn't going out of their way to exclude them.  The lack of rDNS is just one of the many ways to identify and discriminate against end users who haven't bought their way into the club.

Spam is not a big problem for everyone.  It's at a different scale for individuals and for large sites with many users.

-Laszlo


On Mar 26, 2014, at 2:58 PM, Scott Buettner <sbuettner at frii.net> wrote:

> This is totally ignoring a few facts.
> 
> A: That the overwhelming majority of users don't have the slightest idea what an MTA is, why they would want one, or how to install/configure one. ISP/ESP hosted email is prevalent only partially to do with technical reasons and a lot to do with technical apathy on the part of the user base at large. Web hosting is the same way. A dedicated mailbox appliance would be another cost to the user that they would not understand why they need, and thus would not want. In a hypothetical tech-utopia, where everyone was fluent in bash (or powershell, take your pick), and read RFCs over breakfast instead of the newspaper, this would be an excellent solution. Meanwhile, in reality, technology frightens most people, and they are more than happy to pay someone else to deal with it for them.
> 
> B: The relevant technical reason can be summarized as "good luck getting a residential internet connection with a static IP"
> 
> (If your response includes the words "dynamic DNS" then please see point A)
> 
> (Also I'm just going to briefly touch the fact that this doesn't address spam as a problem at all, and in fact would make that problem overwhelmingly worse, as MTAs would be expected to accept mail from everywhere, and we obviously can't trust end user devices or ISP CPE to be secure against intrusion)
> 
> Scott Buettner
> Front Range Internet Inc
> NOC Engineer
> 
> On 3/26/2014 8:33 AM, Laszlo Hanyecz wrote:
>> Maybe you should focus on delivering email instead of refusing it.  Or just keep refusing it and trying to bill people for it, until you make yourself irrelevant.  The ISP based email made more sense when most end users - the people that we serve - didn't have persistent internet connections.  Today, most users are always connected, and can receive email directly to our own computers, without a middle man.  With IPv6 it's totally feasible since unique addressing is no longer a problem - there's no reason why every user can't have their own MTA.  The problem is that there are many people who are making money off of email - whether it's the sending of mail or the blocking of it - and so they're very interested in breaking direct email to get 'the users' to rely on them.  It should be entirely possible to build 'webmail' into home user CPEs or dedicated mailbox appliances, and let everyone deal with their own email delivery.  The idea of having to pay other people to host email for you is as obsolete as NAT-for-security, and this IPv6 SMTP thread is basically covering the same ground.  It boils down to: we have an old crappy system that works, and we don't want to change, because we've come to rely on the flaws of it and don't want them fixed.  In the email case, people have figured out how to make money doing it, so they certainly want to keep their control over it.
>> 
>> -Laszlo
>> 
>> 
>> On Mar 26, 2014, at 2:07 PM, Lamar Owen <lowen at pari.edu> wrote:
>> 
>>> On 03/25/2014 10:51 PM, Jimmy Hess wrote:
>>>> [snip]
>>>> 
>>>> I would suggest the formation of an "IPv6 SMTP Server operator's club,"
>>>> with a system for enrolling certain IP address source ranges as  "Active
>>>> mail servers", active IP addresses and SMTP domain names under the
>>>> authority of a member.
>>>> 
>>> ...
>>> 
>>> As has been mentioned, this is old hat.
>>> 
>>> There is only one surefire way of doing away with spam for good, IMO.  No one is currently willing to do it, though.
>>> 
>>> That way?  Make e-mail cost; have e-postage.  No, I don't want it either.  But where is the pain point for spam where this becomes less painful?  If an enduser gets a bill for sending several thousand e-mails because they got owned by a botnet they're going to do something about it; get enough endusers with this problem and you'll get a class-action suit against OS vendors that allow the problem to remain a problem; you can get rid of the bots.  This will trim out a large part of spam, and those hosts that insist on sending unsolicited bulk e-mail will get billed for it.  That would also eliminate a lot of traffic on e-mail lists, too, if the subscribers had to pay the costs for each message sent to a list; I wonder what the cost would be for each post to a list the size of this one.  If spam ceases to be profitable, it will stop.
>>> 
>>> Of course, I reserve the right to be wrong, and this might all just be a pipe dream.  (and yes, I've thought about what sort of billing infrastructure nightmare this could be.....)
>>> 
>> 
> 
> 
> 





More information about the NANOG mailing list