Re: [ietf-smtp] why are we reinventing mta-sts ?

[Viruthagiri Thirumavalavan <[e-mail]>]

>
> 1) You're outsourcing the e-mail to a company. The added cost for the
> webserver
> will probably be close to zero, because if the proposal gets enough
> traction to matter,
> hosting companies will be able to do it at scale, and bundle it for free.


The future you are predicting would look something like this. "Buy our
hosting package and get $99 worth web server + $99 worth SSL certificate
for free for MTA-STS". When these hosting companies offer something for
free, it's "Free" as in "Freebie". Not "Free" as in "Freedom". We are not a
marketing team for these hosting companies. We are here to solve a problem
and we have to do it in the most efficient way.

A problem can be solved in many ways. Let's just say, a patient goes to see
a doctor with a rash on his leg. The doctor chops off patient's leg and
then give him a walking stick. Technically speaking, the doctor solved the
patient's problem. But, is it the right way to solve the patient's problem?
Maybe in 10,000 BC. But in the modern world, it makes sense only if the
rash was caused by a life threatening disease and it is the only way to
solve the problem.

When the doctor do this on a massive scale, he can definitely afford to
offer a free walking stick for each patient. So If you are going to
evaluate his solution based on the walking stick cost, then that's gonna
produce abnormal results. Without the leg, the patient has to depend on the
walking stick forever. That's a huge inconvenience and it is one of the
most notable variable to consider.

In the case of MTA-STS, SMTP has to depend on a web protocol forever and
that's the prima facie reason why MTA-STS is bad. Cost being prohibitive is
one of the secondary reasons. Speaking of cost, you are being subtle here.
"probably be close to zero" is not the same as "zero". We don't have
control over a company's business model and these hosting companies usually
find a way to increase their profits. e.g. Google recently increased their
G-Suite pricing by $1. So even if you put $1 as price tag for each MTA-STS
deployment, the world will be spending millions of dollars once it get
popular. That's not "close to zero". Most people in the world would like to
save their money even if it just a penny.

Bottomline is, MTA-STS should be used as a last resort when there is no
better alternatives possible. And that's just my humble opinion.

On Tue, Oct 8, 2019 at 7:36 PM Valdis Klētnieks <[e-mail]>
wrote:

> On Mon, 07 Oct 2019 15:10:29 -0400, "Stan Kalisch" said:
>
> > That may be, but I do not think, however, that this addresses
> Viruthagiri's
> > assertion about the cost being prohibitive for some in developing
> countries.
>
> The point is that there's 3 basic cases:
>
> 1) You're outsourcing the e-mail to a company. The added cost for the
> webserver
> will probably be close to zero, because if the proposal gets enough
> traction to matter,
> hosting companies will be able to do it at scale, and bundle it for free.
>
> 2) You're doing low-volume e-mail in-house. The added resources needed for
> the webserver will probably be close to zero, because somebody will write a
> "how-to" or even write an open-source program that you enter your domain
> name
> and host name, and it writes the config files for you.
>
> 3) You're doing in-house e-mail at a volume that the web server resources
> matter.
> At this point, you're *already* going to be fighting with scaling issues
> with  your SMTP
> system and the web server is the least of your worries....
>
> Yes, in some situations the cost of e-mail for an organization can be
> prohibitive.
> However, this isn't a proposal that doubles the cost of doing it. It's
> more likely
> going to add a half-percent or so - there's probably going to be a
> half-dozen things
> applying more economic pressure.
>
> And it's probably *far* too early in the protocol design process to be
> saying "oh,
> but this *might* be a problem for a very very small percentage of sites" -
> especially
> since we're talking about an *optional* extension.
>


-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.