TMTP over HTTPS (nec for AppEngine?)

[krolaw]

Most stuff I write today runs on AppEngine, but I'm looking favourably at Cloud Run or AWS Droplet. These systems favour short connections and cost nothing when inactive. Presuming a mail system ran over https, and didn't use long connections, almost anyone could setup their own server for next to no cost (or simply fit within free tier) and utilising any available storage system.

TMTP seems comparatively complicated (firewalls, database...) and costly, needing to be active all the time.

I also imagined that users would pass providers/other users a token (through something like OAuth), giving (revocable) permission to send them email. It's not clear to me how this is done - apologies if I've missed critical document portions.

[krolaw]

Oh and having it https based would simplify automated systems sending mail as they could do a simple https request (with verifed token of course) direct to the end server. No mailgun, sendgrid etc, or risk of ending up in spam.

[networkimprov]

Hi, thanks for writing!

A user registers an account on a TMTP server, using a credential verified by a third party (e.g. LDAP). That account can receive email from anyone else on that server who knows its ID (which is not guessable). That account can also block anyone who's received the ID. Users know each other by one or more aliases tied to their ID.

Can you provide references re favoring short connections? I have the impression that cost is driven by MBs transferred. Also aren't long-lived websockets relatively common?

One could run the server on the std TLS port, to avoid opening a non-std port in the firewall.

mnm requires no database; it uses the filesystem for storage.

[krolaw]

On appengine for example web requests aren't passed to the app until the entire request is received and responses aren't transmitted until the entire response is generated.

App Engine is optimized for applications with short-lived requests, typically those that take a few hundred milliseconds. An efficient app responds quickly for the majority of requests. An app that doesn't will not scale well with App Engine's infrastructure.

https://cloud.google.com/appengine/docs/standard/python/how-requests-are-handled

Cloud run: https://cloud.google.com/run

Only pay when your code is running, billed to the nearest 100 milliseconds.

Oh, and the above only accepts web requests. No other ports. Both are really popular, because unless you're getting millions of requests per month, it's part of the free tier.

I believe AWS droplets are similar. Hope that helps.

[krolaw]

Appengine std, doesn't do websockets. Appengine flexible does but costs significantly more and didn't auto scale as well. Don't know about others.

[networkimprov]

I'd guess "when your code is running" means when it's using CPU time, so not when it's blocked on I/O.

I run the mnm server on a low-end DigitalOcean droplet, flat rate (under a bandwidth max). I believe AWS has many similar options; I recall looking at them before I set it up.

If supporting AppEngine requires tunneling TMTP over HTTPS, that can be considered down the road. Of course, it's not clear that AppEngine will exist down the road ;-)

[krolaw]

I'd guess "when your code is running" means when it's using CPU time, so not when it's blocked on I/O.

No, it means how long before a response is generated. If requests aren't coming in, service is spun down and spun up on the next request (milliseconds). This "only exist when there's something to do" is becoming more and more popular.

[networkimprov]

I see. Thanks for raising this!