mirage / ptt Goto Github PK

Postes, Télégraphes et Téléphones

OCaml 100.00%

ptt's Introduction

PTT - Poste, Télégraphe et Téléphone

ptt is a suit of tools to deploy a full SMTP service. The current available design is:

                                         [ Primary DNS server ]
					           |
                                                   |
 *:465 [ Submission server ] -- TLS --> *:25 [ DKIM signer ] -.
                |                                             |
                ----------------------- [ SMTP relay ] *:25 <-'
       [ Git Database ]                    |  |
			 [ DNS Resolver ] -'  `-> *:25 [ Internet ]

3 unikernels (with [MirageOS][mirage]) exist:

a submission server (LIPAP) which must be synchronized with a database (such as [irmin][irmin] x [git][ocaml-git]) to authentify users
a DKIM signer (NEC) which requires a private RSA key and update the primary DNS server of the domain-name with the public RSA key. It signs incoming emails and pass them then to the SMTP relay
the SMTP relay (MTI-GF) which will resolves recipients via a specific DNS resolver and send incoming emails to destinations.

Even if we use the *:25 to communicate between each unikernels, all of them start a TLS session. Only yhe SMTP relay requires a DNS resolution process and the DKIM private key is never shared to anyone - only the public key is sended to the primary DNS server to let recipients to verify outcoming emails.

This is the usual design of an SMTP service to be able to send an email. The reception of an email does not exists - and it's not the purpose of ptt which does not (yet) implement IMAP.

How to use?

ptt provides these unikernels and they can be deployed as a simple MirageOS:

as a simple executable (see mirage configure -t unix)
as a full operating system

Currently, ptt is used as a full operating system with the hvt target. We deploy these unikernels via KVM & Solo5. DNS resolver and primary DNS server are unikernels too (see [robur.io][roburio] -- but, as far as we can say, this SMTP stack is usable with a simple DNS server (as far as it implements nsupdate).

Experimental

ptt is not yet stable or reliable but we currently try to deploy/use it and improve it. Don't use it!

Credits

ptt has received funding from the Next Generation Internet Initiative (NGI) within the framework of the DAPSI Project.

ptt's People

Contributors

Stargazers

Watchers

Forkers

nickbetteridge idkjs lyrm hannesm mtelvers

ptt's Issues

Decoupling sending and receiving emails

To get some space to really describe the failure politic when we send an email, it can be interesting to "decouple" the sending logic from the receiving logic. Currently, for any received emails, we do a Lwt.async send_the_incoming_email. But we probably should launch another fiber which waiting data for sending emails and do a Lwt.async notify_sender_fiber into our receiving loop.

By this way, we can handle properly a real policy to send emails (any emails) and when some of them fails.

A block-device which can store temporary emails can be useful too for some situations (like how we handle greylisting from recipients's servers?).

Handle `Return-Path`

If an email can not be transmitted to a recipient, we should report an error to the sender via the Return-Path mechanism.

Replace the `MAIL FROM` on the relay level

Currently, the relay keeps the same MAIL FROM as it receives. If we receives MAIL FROM <[email protected]>, we send back the email with the same MAIL FROM <[email protected]> even if our identity is not bar.com. If we can assert that the primary destination of the email is for us (like [email protected]), we should send back the email with MAIL FROM <[email protected]> to the real destination. In such situation, the real destination (let's say [email protected]) will be able to do a proper SPF check on the x25519.net domain instead of on the bar.com domain.

Spotted by @hannesm.

File "unikernel.ml", line 101, characters 8-18:
101 |     let postmaster =
              ^^^^^^^^^^
Warning 26 [unused-var]: unused variable postmaster.

when compiling unikernels. I'm not entirely sure whether this should be used somewhere?