On 11/13/20 11:03 AM, Mikko Rantalainen wrote:
Keith Moore (2020-11-13 17:26 Europe/Helsinki):
To the extent email delivery is reliable, it is because of persistence
in relaying traffic. Many mail user agents are not in a good position
to do that. It is generally better to submit the message to a service
that is well-connected and well-provisioned for relaying.
Nowadays, email seems pretty unreliable already. This happens with the
relaying because email is lost due blackholing assumed spam. I agree
that this is caused by NOT FOLLOWING existing RFCs but you really cannot
bounce spam either because there's no way to figure out *true* origin of
any given email due untrusted relaying network. Basically the problem is
that relay network cannot be trusted and any info in the email can be
forged by the spammer or attacker.
Do you think that I'm wrong and current relaying network is trustworthy?
I'd very much like to see relaying move to SMTP-over-TLS authenticated
by client certificates, but we're a long way from that point. Moving
to direct submission would only make that more difficult though because
it's much easier to build a PKI for several thousand trusted relays than
one that works for several billion mail submitters.
Mail submission should be a distinct service from mail relaying, and
done on separate ports so that they're easily distinguishable.
Combining the two services, as was once common, results in more damage
to messages in transit.
Could you elaborate why do you believe this? What difference does it
make for transmitting the email from moment of time of accepting it to
relay server?
We had long experience with port 25 used for both submission and
relaying. Pragmatically mail submission often required messages to be
"fixed", whereas relayed messages should not be altered except for
adding (mostly) received headers because every additional alteration
increases the chance that the message will be damaged beyond
usability. (sigh, there's way too much header pollution added by
relays, but at least these days it seems mostly confined to headers).
Another reason it made sense to separate the two was authentication.
It's reasonable for MSAs to require authentication say by
password-over-TLS, and that wasn't terribly hard to get deployed. It's
much harder for SMTP relays to require authentication, but mail
exchangers can quite reasonably bounce or drop traffic not bound for one
of their client domains.
I'm sympathetic to the idea that multihop mail relaying produces more
opportunities for surveillance of message content, but the right
solution to that problem is e2e encryption.
It seems that end users are not willing to take responsibility of key
handling required for real e2e so we should have next best option
available. TLS with server sertificates and clients without any
certificates seems to scale for banks, news sites and social media. It
should scale pretty well for email, too.
You could use TLS with client certificates, but good luck getting it
deployed. Imagine every email user needing to generate a key pair and
get and safeguard a client cert, securely distributing their private
keys to all of their devices that send/read mail. Imagine the difficulty
of keeping those devices from compromising their private keys. Really
you need HSMs for that; PCs are grossly inadequate and mobiles aren't
much better. Saying that "end users are not willing to take
responsibility" seems unfair at best, when it's not easy to understand,
not easy to do, and the tools are primitive and very much lacking.
As much as I dislike port blocking as any kind of general strategy, I
strongly suspect that port 25 blocking is helpful even if it doesn't
eliminate all spam. (The spam situation would be even worse without it.)
I agree that with the current system where relay servers blindly trust
anybody talking to port 25, the port blocking is better than nothing.
However, the correct fix is to stop this blind trust because it seems
obvious that spammers already have control of too many servers with
ability to connect to "trusted" port 25. I'm not suggesting that we
should raise the block before we have something better. However,
pretending that this blocking is effective and not doing anything does
not look good option either. [Insert "This is fine" meme here.]
Are you against the idea of point-to-point mail delivery or the idea of
using port 465 for that?
I'm against both. Neither one is remotely workable.
However, I'm all for promoting authenticated/encrypted relaying, and
also all for promoting e2e encryption. But direct mail delivery is, I
believe, a step in the opposite direction.
Keith
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
