Internet Mail 2000

[link2xt]

We want to be able to accept mails from .onion domain. We cannot have DKIM authentication as there is no support for DNS (see https://forum.torproject.org/t/mock-dns-records-for-onion-services/4671 and https://media.ccc.de/v/gpn22-469-self-authenticating-tls-certificates-for-tor-onion-services for some work on this due to the need to have TLSA records). However, we can authenticate by pulling from the .onion domain. We need an HTTP service that is mounted to /im2000/... with a webhook on /im2000/push that listens to POST requests saying "pull mail from http://foobarbaz.onion/im2000/<blake3 hash of the message> and then the service pulls the mail over HTTP with a GET request, checks that From field in all mails corresponds to the foobarbaz.onion and drops the mails into Postfix pickup queue. Then should issue a DELETE request for delivery. If delivery is not picked up for some time, the service will remove it eventually.

To discover if we can deliver over HTTP we can do what MTA-STS daemon does and have a separate transport policy daemon that checks .well-known or just /im2000 URL (over HTTPS for non-onion or HTTP over .onion) to check if pull-based delivery protocol is supported.

See Internet Mail 2000 for previous discussion of a similar concept.

The end goal of this is to allow chatmail servers which have no real domain but only .onion domain to federate with each other and with non-onion chatmail servers.

DMTP proposal from 2006 is more complicated that we need, differentiating between spammers and non-spammers and allowing to use both SMTP for mails that pass the filter and DMTP (pull) for other mails. We are not really interested in spam filtering and just allow SMTP. We need pull-based delivery for authentication of onion services and delivery without port 25 rather than anti-spam measure.

Stubmail (by Meng Wong, author of SPF) is the most interesting proposal, it uses HTTP for delivery, but for notifications it uses "stub" mails that are just normal mails that notify about messages. Such messages need to be delivered over SMTP, but we will use HTTP instead.
Have not looked too deep, but here is a PDF of some talk: http://www.mengwong.com/rssemail/200607260-oscon-lightningtalk.pdf
Talk "Turning Email Upside Down: RSS/Email and IM2000" is at https://www.youtube.com/watch?v=egHGwitIC1Q

There is some research from 2010 on pull-based delivery:

• An article Advantages and vulnerabilities of pull-based email-delivery (2010)
• Master's Thesis General Delivery - Receiver Driven Email Delivery

It proposes extending SMTP with GDEL (notification about new mail, similar to the webhook POST request) and RETR (downloading a mail, similar to GET request).

The main problem is avoiding the possibility to trigger arbitrary HTTP GET requests, so we should probably only allow URLs of some form and remember if it does not return expected answer so request to the same domain cannot be triggered again, at least for a day.

We should also make sure that HTTP cannot be used to host arbitrary files, it should serve files with an email MIME type. Matrix had similar problem with the possibility to abuse the servers as a CDN: https://matrix.org/docs/spec-guides/authed-media-servers/
GET request should require a special header, e.g. Authorization, which cannot be easily sent from a browser requesting images.

[rakoo]

Another disadvantage of pull-based email is that it acts as a forced read receipt, ie more data for data harvesters

[link2xt]

Another disadvantage of pull-based email is that it acts as a forced read receipt, ie more data for data harvesters

@rakoo The idea is not to pull from the sender server on the client like in original Internet Mail 2000, but for the receiver MTA to pull the message from the sender MTA. So it is just a delivery notification.

[rakoo]

I might have read too quickly from your link but it seemed that the retrieval happens when the user retrieves content in their mailbox, typically over imap (and then the content would be filled in by the mta retrieving at the source)

[rakoo]

Sorry about the comments I was fixated on the antispam part and bypassed the onion part.

Could chatmail fetch DKIM and SPF records over DNS-over-HTTPS-over-tor ? I don't know how to turn this out but it wouldn't be a general resolution service, only for the current sender's mta

[missytake]

Sorry about the comments I was fixated on the antispam part and bypassed the onion part.

Could chatmail fetch DKIM and SPF records over DNS-over-HTTPS-over-tor ? I don't know how to turn this out but it wouldn't be a general resolution service, only for the current sender's mta

not for .onion domains, because .onion domains can't have DNS records

[rakoo]

not for .onion domains, because .onion domains can't have DNS records

They can have DNS records, they just can't be served by the ietf-based hierarchy. But they are totally able to serve them themselves: according to RFC 8484 all you need is a http server that replies to GET and POST, and consumes/replies DNS frames. With a basic server hosteo on the side of the onion service that only resolves that onion service you can get its records

[link2xt]

You can as well run a nameserver on port 53 as an .onion service, but nobody will query it.

[rakoo]

You probably don't want to run a standard nameserver because tor can't wrap UDP, hence the DNS-over-HTTPs(-over-tor)

[link2xt]

DNS on port 53 works over TCP as well, but I don't see how it matters because you cannot delegate the .onion domain to the nameserver running as an .onion server anyway. This requires publishing NS record.

[rakoo]

Oh I didn't know that, and it's useful.

You don't need to publish anything. The idea is:

• on sender side, have a very small DNS resolver that replies with relevant DNS records only for this onion service
• on receiver side, have a DNS proxy that forwards requests to not-onions to usual DNS resolver and requests to onions to the resolver at that specific address (because it expects that there is one)

[hpk42]

Its worthwhile to reduce usage and dependency on DNS and DKIM.
They are the primary pain/failure points when setting up a chatmail relay.

Reversing the flow for MTA-MTA delivery means that DKIM is not needed at all as http over TLS or onion requests provides authenticity better than DKIM does.