mirage / colombe

Implementation of SMTP protocols in OCaml

Build Unikernels in OCaml

---

MirageOS is a library operating system that constructs secure, performant and resource-efficient unikernels.

About

MirageOS is a library operating system that constructs unikernels for secure, high-performance network applications across various cloud computing and mobile platforms. Developers can write code on a traditional OS such as Linux or macOS. They can then compile their code into a fully-standalone, specialised unikernel that runs under the Xen or KVM hypervisors and lightweight hypervisors like FreeBSD's BHyve, OpenBSD's VMM. These unikernels can deploy on public clouds, like Amazon's Elastic Compute Cloud and Google Compute Engine, or private deployments.

The most up-to-date documentation can be found at the homepage. The site is a self-hosted unikernel. Simpler skeleton applications are also available online. MirageOS unikernels repositories are also available here or there.

This repository

This repository contains the mirage command-line tool to create and deploy applications with MirageOS. This tool wraps the specialised configuration and build steps required to build MirageOS on all the supported targets.

Local install

You will need the following:

• a working OCaml compiler (4.08.0 or higher).
• the Opam source package manager (2.1.0 or higher).
• an x86_64 or armel Linux host to compile Xen kernels, or FreeBSD, OpenBSD or MacOS X for the solo5 and userlevel versions.

Then run:

$ opam install mirage
$ mirage --version

This should display at least version 4.0.0.

Using mirage

There are multiple stages to using mirage:

• write config.ml to describe the components of your applications;
• call mirage configure to generate the necessary code and metadata;
• optionally call make depends to install external dependencies and download Opam packages in the current dune workspace.
• call dune build to build a unikernel.

You can find documentation, walkthroughs and tutorials over on the MirageOS website. The install instructions are a good place to begin!

colombe's Issues

Spit the release cyle of `received` with `colombe`

Even if received is useful and is about SMTP, it seems better for it to follow its own release cycle instead to follow the release cycle of colombe. The next release of it will be done independently to colombe but the distribution keeps it as a part of the project.

Stack overflow exception when trying to connect with invalid credentials.

I've been testing an SMTP integration with Mailgun, using letters. I noticed that when I supply incorrect credentials, I get a stack overflow exception rather than an "Authentication Failed" exception. The program I'm using to run this test is here.

To reproduce this, I ran openssl s_client -connect smtp.mailgun.org:587 -starttls smtp, and then entered the command "AUTH PLAIN BADPASSWORD". I observed that Mailgun issues a 535 Authentication Failed, then immediately terminates the connection. I think this means that when Colombe tries to issue a QUIT here, it ends up hanging waiting for a 221 Bye that will never arrive, and a stack overflow results.

Would it be possible to make Colombe a bit more resilient to this behavior from Mailgun? I also tried testing against Sendgrid and observed similar behavior.

If I change the line linked above to use let instead of let*, I noticed that the problem goes away. Would that be an acceptable fix? I think that would mean in the event of an error Colombe should try to send a QUIT, but that shouldn't block producing Error err. (I'm still learning how this library works, so please let me know if this analysis is wrong.)

sendmail-with-tls (with lwt)

First, we should rename it sendmail-with-starttls where sendmail-lwt use TLS directly but the first one use STARTTLS. Then, we should provide a port of it to lwt and don't expose ('a, 's) io at this layer.

Missing ```rresult``` in dune file for ```sendmail``` lib

Hi!
As the title says, it seems that rresult library should be added in the dune file for sendmail lib.

Update `ocamlformat`

authentication fails when server reply is missing space after 334 code

Colombe throws after trying to start authentication when using ethereal.email service. The same authentication succeeds when using GMail or Mailtrap where you have something like:

main.exe: [DEBUG] Clean internal buffer to start TLS.
main.exe: [DEBUG] Start TLS.
main.exe: [DEBUG] <= "EHLO inbox.mailtrap.io\r\n"
main.exe: [DEBUG] => "250-mailtrap.io\r\n250-SIZE 5242880\r\n250-PIPELINING\r\n250-ENHANCEDSTATUSCODES\r\n250-8BITMIME\r\n250-DSN\r\n250 AUTH PLAIN LOGIN CRAM-MD5\r\n"
main.exe: [DEBUG] <= "AUTH PLAIN\r\n"
main.exe: [DEBUG] => "334 \r\n"

In ethereal.email you have:

main.exe: [DEBUG] Clean internal buffer to start TLS.
main.exe: [DEBUG] Start TLS.
main.exe: [DEBUG] <= "EHLO ethereal.email\r\n"
main.exe: [DEBUG] => "250-smtp.ethereal.email Nice to meet you, 178-83-55-11.dynamic.hispeed.ch\r\n250-PIPELINING\r\n250-8BITMIME\r\n250-SMTPUTF8\r\n250 AUTH LOGIN PLAIN\r\n"
main.exe: [DEBUG] <= "AUTH PLAIN\r\n"
main.exe: [DEBUG] => "334\r\n"
email-test: internal error, uncaught exception:
            (Failure "Sending email failed, Unexpected char: 0d")

The issues seems to be that ethereal.email is missing space after 334 code that causes the code to fail as it receives \r (0d) while expecting space. Is this bug in Colombe when it fails, if that space is missing or is this bug in ethereal.email service not having it?

Allow `AUTH LOGIN` mechanism

Hello, from what I'm seeing currently, only the AUTH PLAIN mechanism is supported in sendmail. It would be very beneficial for us if AUTH LOGIN is also supported, as we are using Microsoft Exchange SMTP servers and they have disallowed AUTH PLAIN back in 2017 apparently.

Thank you!

Allow `AUTH NTLM` mechanism

In addition to PLAIN and LOGIN, NTLM is a widely-used protocol, most often by Microsoft services. It would be beneficial if this mechanism would also be supported.

Analogous to #60.

Thanks!

Update the README

May be add a write-barrier about dot character

Currently, colombe does not check if the user sends . or not - and finish on its way, the email. It can lead errors if the user does not care/are aware about that so we probably need to check and translate .\r\n to ..\r\n according RFC 5321 here:

colombe/sendmail/sendmail.ml

Line 236 in da2281a

rdwr.wr flow buf off len >>- mail >>- go

@Julow, I know that you got this issue one time, what do you think? Then, @Jerben gently asked me about that. Even if the documentation mentions that we send the given email as is:

colombe/sendmail/sendmail_lwt.mli

Lines 67 to 69 in da2281a

	not handle properly contents of mails as are. It just emits the stream to the
	pipeline directly without any changes. Again, this job can be done by
	[mrmime] - or yourself.

It's not clear and well understandable that error can occur if the user send .\r\n

Client for test_client is missing

There is no client for test_client to test (it should probably be this).

base64 dependency for sendmail doesn't have version specification

There is no version restriction on the dependency on base64 in sendmail.opam, so opam may attempt to use a 2.x version where Base64 was named B64 instead (which obviously breaks sendmail).