Neat! Congrats on releasing it and thanks for sharing.
The one minor nitpick I have is the use of HTTP GET to create an inbox. It just rubs me the wrong way.
I raised an eyebrow at that too, but it does let you quickly create a mailbox from your browser by simply typing a URI.
Thanks for the feedback. I guess its about the fact that RESTful APIs became the norm, right? I should maybe read up on that way more - did not quite get the concept completely. Do you have a recommendation for a good read on REST?
The short (and relevant) part here is that GET requests should not mutate the state of the resource. If you mean to create some new thing, it should be a POST request.
Consider this: what happens if a search engine starts crawling the site? Should that change the state of your database? Probably not.
See this pertinent anecdote for more: https://mobile.twitter.com/rombulow/status/990684453734203392
I refer back to this frequently:
I’d love to see IPv6 support. :-)
Is it JMAP conpatible or it’s just ad-hoc serialization of email and mailboxes?
This is an interesting idea. I was not aware of JMAP - thanks.
Currently, the code is just finding the “To”, “From”, and “Subject” lines, and adds the the raw mail data with all the fields as received by the SMTP. The whole email “parser” is here: https://github.com/ptek/api.unverified.email/blob/112a1f002bc7bf22651603523de414452be89612/src/Model/Email.hs#L19-L30
EDIT: Is there any particular application you have in mind with JMAP? Dies it somehow help with testing?
Compared to IMAP, JMAP is a much simpler spec that more closely matches how people typically use email.
Also, using https as the transport means you get a very widely understood / supported TLS stack vs the compatibility mess that is StartTLS et al.
Having more open source software is always good, so congrats on putting something out there.
I’m very curious why this takes the approach it appears to take: running two docker containers with opensmtpd in one of them, and then scanning the maildir for message content; compared to what the numerous existing solutions (mailcatcher, mailtrap, mailhog, maildump) all do: run an in-process SMTP server.
I agree that the current deployment method is somewhat overkill. The idea was to be able to scale api independently of smtpd containers, extending both to use external storage instead of a docker volume if the need arises. It noticeably fell short of the original plan, as I wanted to do a release and prove its usefulness before doing more.
I’m more referring to the general approach (smtp > maildir > scanning) as opposed to the approach taken by other tools in this space (a single process with an smtp server embedded), than the specifics of using two docker containers (although I always question why a project uses docker as its only supported deployment method).
I see. I haven’t really found an up-to-date SMTP server library for haskell, and did not want to roll my own, so I decided to go for a well-proven tool instead, and composed it like the other unix tools would. It has proven successful and I really like how simple the API code turned out in the end doing one thing. Sorry for not being able to compare unverified.email to the way other tools are doing it - I haven’t researched it that much. I guess I just started building it from a different angle and made different choices along the way.
That’s a completely reasonable approach, and (albeit hamstrung by the docker setup) it allows for updating the smtp component via system packages, in the case of e.g. a vulnerability or incompatibility.
Sorry if my comment came off as overly negative or aggressive!
neat idea, done well! :)
Nice! This is going to come handy while I’m testing out this mail client thing I’m writing.
Edit: I’m a bit new to lobsters: Shouldn’t this post have the “show” tag? Just trying to understand this community better.
That is probably true. I have not thought of it.
When this happens you can also suggest tags!
I don’t think I can do this (I have limited access to stuff since I’m new)