Subject: Re: [Uta] RFC 8314: Consider supporting point-to-point delivery

From: Keith Moore <[email-masked]>
Date: Fri, 13 Nov 2020 10:26:08 -0500

Short version: this is, in many cases, a Bad Idea.

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.

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.

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.

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.)

So I emphatically do not support the proposed changes.

Keith

---

From: [email-masked]
Date: Fri, 13 Nov 2020 07:46:30 -0800 (PST)

FWIW, you appear to have responded to a message that hasn't made it to
the list yet.

				Ned

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Nov 2020 11:26:58 -0500

On 11/13/20 11:03 AM, Mikko Rantalainen wrote:

> Keith Moore (2020-11-13 17:26 Europe/Helsinki):
> 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.

> 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.

> 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.

> 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

---

From: "Chris Newman" <[email-masked]>
Date: Fri, 13 Nov 2020 11:13:21 -0800

The basic issue is Email has two critically important properties that 
make it uniquely useful despite the age of the service and the cruft 
that has accumulated due to that age:
  1. decentralized control
  2. communication without introduction

If you don't preserve these two properties, then what you're describing 
is not email. Spam is, of course, an unavoidable problem when these two 
properties are preserved. There's plenty of literature on FUSSP that 
will explain why your proposal won't help the spam problem and will make 
it worse. No need to repeat that here.

For better or worse, we've evolved an email system where technologies 
like DKIM, SPF, DMARC, milter, block-lists, reputation, submission 
authentication, blocking port 25, etc. combine in complex ways to 
partially mitigate the spam problem and mostly preserve the critical 
properties of email.

I believe your proposal as described will make the spam problem worse 
and add no value to the email system. There have been some related 
proposals to add an extension to email where direct-delivery is 
sometimes permitted after an introduction (sender/recipient 
authentication/authorization agreement); I find those proposals 
interesting but the devil is in the details because such systems won't 
deploy unless a number of hard requirements are met (introduction 
mechanism is secure and painless, service is low-cost/low-risk for 
providers, a business motivation to deploy the service exists, etc). I 
think it may be possible to develop a feasible proposal along those 
lines, but have not yet seen one.

		- Chris

On 13 Nov 2020, at 5:15, Mikko Rantalainen wrote:
> Dear Sirs,
>
> RFC 8314 
> (https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8314__;!!GqivPVa7Brio!L5V6Esos894QM6Tl2eS0YIfPjBG44DUDCjtS1da_H1VjLwz2a4DfigxQ3PBUfUY4wA$ 
> ) recommends using port 465
> for all mail submissions with implicit TLS in the future. This is a
> request to consider supporting point-to-point delivery of email 
> directly
> to MX pointed server.
>
> Historically email has been delivered using port 25 by mail relays.
> During 1980s this was required because internet was not fully 
> connected.
>
> During later years submitting spam using port 25 caused big enough
> problems that port 25 is now disabled by many ISPs and cannot be used
> for client connections in foreseeable future.
>
> However, given the modern internet where every device is always online
> it would be much better to allow point-to-point delivery of email, 
> too.
>
> In practice, this could be implemented by allowing direct TLS
> connections to port 465 similar to HTTPS connections to web servers.
>
> As an example case, if I'm sending email to [email-masked], my mail
> user agent could do DNS query for gmail.com and receive MX record for
> gmail-smtp-in.l.google.com. After this my mail user agent could 
> connect
> directly to gmail-smtp-in.l.google.com:465 using TLS and directly send
> the email to the end user.
>
> As an automated fallback, if gmail-smtp-in.l.google.com doesn't listen
> to port 465 the email COULD be delivered using the historical relay
> delivery.
>
> Advantages:
>
> - If target server doesn't accept the mail (e.g. it's considered 
> spam),
> the sender gets direct response.
>
> - Any intermediate relay host cannot read the contents of the email.
>
> - There's no need for non-standard bounce messages for failed 
> delivery.
>
> - Final server can trace the connection of the incoming request if
> needed. This should allow avoiding spammers better than the current
> situation.
>
> - Point-to-point protocol could require sender to solve some 
> computation
> (e.g. solve sha256(??????d89314691c55ab8ce85c032ac7) ==
> 883b91ab839eeffb01a7b26ed48ef77614e1c5461a44285c9acf54195fe3fba7 and 
> the
> sender must brute force the solution to answer
> 8d104bd89314691c55ab8ce85c032ac7). This would cause spammers to have 
> to
> use much more CPU power to post more spam.
>
> - The final server could inspect e.g. recipient address book to verify
> if the sender is already known which could be used to estimate the
> probablity of incoming message being spam (if offered mail has DKIM
> signature this would be pretty safe method alone). This could be done
> online so that the original sender gets immediate response if message 
> is
> not accepted. The response message could include options such as
> "Payment required in Bitcoin for previously unknown senders.".
>
> Disadvantages:
>
> - Publicly visible email servers would need to be able to directly
> accept or decline the email. Some existing infrastructure may not be
> able to do this.
>
> - Requires new client software to allow direct delivery of email.
>
> Additional notes:
>
> - The hack to "prevent" spam by requiring spammers to have servers (to
> use port 25 which is denied by ISPs from normal clients) doesn't seem 
> to
> be working.
>
> - Attackers could already try to brute force existing installations 
> with
> port 465 open so the existing structure cannot prevent DoS or DDoS
> attacks against email servers.
>
> - Existing services (e.g. facebook.com, google.com) can obviously 
> scale
> to serving billions of users directly from one port with 
> point-to-point
> connection so the problem is not that point-to-point email delivery
> cannot scale.
>
> - This request is not about specifying the method for implementing
> details of such point-to-point protocol but request to change the
> wording of RFC to suggest that the same port would be used for
> point-to-point delivery in the future.
>
> -- 
> Sincerely,
> Mikko Rantalainen

---

From: "John Levine" <[email-masked]>
Date: 13 Nov 2020 15:14:54 -0500

>> directly to MX pointed server.

>and add no value to the email system. ...

We don't have to guess. This was a hot topic at MAAWG a long time ago
back before port 25 blocking was common on consumer networks. The vast
majority of direct-to-MX mail is spam from compromised hosts. When
networks blocked it they consistently found that their spam complaints
went way down with almost no collateral damage other than a tiny
handful of linux enthusiasts who'd set their mail software not to use
a normal relay. ("Don't do that.")

This history is well known among mail operators and there is no chance
the blocks will go away. Even where networks don't do their own port
25 blocks, popular DNSBLs like the Spamhaus PBL identify network
ranges that aren't expected to send mail directly so mail systems can
block them at the recipient end.

It is essentially the same reason that nobody relays mail for
strangers any more ("open relays".) Whatever benefit there might be is
swamped by spammer abuse.

R's,
John