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 user...@gmail.com, 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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
