On Thu, Aug 20, 2020 at 9:39 PM Caveman Al Toraboran <toraboracave...@protonmail.com> wrote: > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Thursday, August 20, 2020 11:41 AM, antlists <antli...@youngman.org.uk> > wrote: > > > Will that python script allow for the situation that the message is > > received, but the message was NOT safely stored for onwards transmission > > before the receiver crashed, and as such the message has not been > > SUCCESSFULLY received? > > > > SMTP has lots of things specifically meant to ensure messages survive > > the internet jungle on their journey ... > > thanks for the point. would it suffice if we have > these notifications: > > 1. receipt by final mail server (mandatory). > 2. receipt by end user(s) (optional). > 3. opening by end user(s) (optional). >
I don't really want to get into the gory details and have only skimmed the discussion, but my sense is that you're talking about a new way to deliver mail that makes two sorts of changes: 1. Modernizing the actual data exchange using http/etc. 2. Changing the model around email moving to something more PKI-based/etc and redefining what an email address is. This stuff can be interesting to discuss, but email is SO entrenched that I don't see any of this changing because of all the legacy issues. You would need to offer something that is both easier and better to use to such a degree that people are willing to change. However, I'll comment on both of these issues: 1. Modernizing the actual data exchange using http/etc. I don't think you'll get much argument that SMTP isn't the way somebody would do things if they were designing everything from scratch. I'm not an API expert but I imagine that just about any of the modern alternatives would be an improvement. http would be a pretty likely protocol to handle the transportation, likely with something like JSON/xml/etc carrying the payload. You might want to tweak things slightly so that recipient validity can be tested prior to transferring data. A mail server doesn't want to accept a 20MB encrypted payload if it can bounce the whole message based on the recipient or a non-authenticated sender or whatever. However, in principle there are plenty of modern ways to build a transport protocol that would be an improvement on SMTP and use more standard libraries/etc. I think this is actually the part of your proposal that might be more likely to take off. You could have a new type of MX field in DNS and if it is set then it defines servers that will use the new protocol, and you could have backup SMTP servers for legacy transition. You could change the transport side of things without redefining how email works, so the same messages are interoperable with both systems. On the flip side, while I think this is an easier change to make, I don't think it necessarily offers huge improvements. SMTP still gets the job done, and the new system wouldn't really be a major improvement from a sysadmin standpoint, so I don't see everybody running out to change. Just changing the transport protocols doesn't provide any anti-spam/etc benefits. SMTP already supports TLS so it isn't any more secure. No doubt if we were starting from scratch this is how it would be done, but it isn't enough of a reason to change. That said, if there were even modest benefits for large mail providers I could see it taking off simply because it could leverage a lot of existing libraries and standards, and could have legacy compatibility. 2. Changing the model around email moving to something more PKI-based/etc and redefining what an email address is. This is where you could have revolutionary improvements for privacy/spam/etc. However, it completely breaks everything that exists with email today, so it is a hard change. Most of the benefits only accrue if you adopt PKI as well, which is a problem that is hard to scale out to the masses. If somebody comes up with a way to make PKI take off in a real way, then I could see something like this taking off eventually. Otherwise, this stuff is only going to be of interest to the sorts who use gpg to sign their email, and nobody else. -- Rich
