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 <sbuett...@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 <lo...@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.....)
>>> 
>> 
> 
> 
> 


Reply via email to