Lamson The Python SMTP Server | Hacker News Reader

Lamson The Python SMTP Server

lamsonproject.org

65 pointsiamelgringo21 comments

I wouldn't touch this without first giving it a very thorough security audit. Zed is right that most MTAs in use today are Byzantine horrors, but he misses out on why they were written that way: security. A mail server needs to bind to a privileged port, aggregate every user's mail into a single outgoing queue (which must be stored on disk for reliability), setuid into arbitrary users for delivery, and sometimes execute arbitrary commands given by those users (procmail). This is not an easy thing to get right. The reason for the strange design of Postfix, qmail, et. al. is to allow them to implement privilege separation wherever they possibly can. The thought of throwing all that away, and substituting a lightly-tested, monolithic program written in a dynamic language that permits monkey-patching at runtime and doesn't have Perl's taint checking support, makes me nervous to say the least.

Mail servers, web servers, C compilers, libcs, and crypto libraries all seem to share the common property that their basic functionality seems enticingly easy to implement, inducing the naive to look at the mainstream implementations and think, "Look how stupidly bloated these are! I can do way better", and go on to produce nice elegant, minimalistic implementations that immediately fall over when put into production.

I wouldn't call the designs of Qmail or Postfix "strange", they're very well designed systems for what they do and given their age. I intimately know the workings of postfix, and while it's not nginx, it does everything it can to be modular and extensible: see how many ways it allows you to access the mail queue before a message is delivered, for example. Yep, THREE different, well documented ways, in increasing levels of ease/performance.

P.S. Is it just me or has Exim declined in popularity? 10 years ago it was hard to choose between Qmail and Exim, and Postfix was the hot new thing.

I don't know how it landed on my server (maybe it was apt-get install mail), but:

shephard@sbwc:~$ cat /etc/issue

Ubuntu 8.04.2 \n \l

shephard@sbwc:~$ sudo netstat -anp | egrep -i tcp.25

tcp 0 0 127.0.0.1:25 0.0.0.0: LISTEN 21313/exim4

Ubuntu seems to have an affinity for exim somewhere...

Fedora, too AFAIK.

I think Ubuntu prefers Postfix; perhaps you did something specific to end up with Exim.

"Postfix is the default Mail Transfer Agent (MTA) for Ubuntu." -- https://help.ubuntu.com/community/Postfix

Exim is the default on Debian

From the "about" page: http://lamsonproject.org/about.html

However, as great as Lamson is for processing email intelligently, it isn’t the best solution for delivering mail. There is 30+ years of SMTP lore and myth stored in the code of mail servers such as Postfix and Exim that would take years to replicate and make efficient. Being a practical project, Lamson defers to much more capable SMTP servers for the grunt work of getting the mail to the final recipient.

Also see this question in the FAQ: http://lamsonproject.org/docs/faq.html "What about security?! Shouldn’t Lamson be 20 processes?"

a lightly-tested, monolithic program written in a dynamic language that permits monkey-patching at runtime and doesn't have Perl's taint checking support, makes me nervous to say the least

lightly-tested - Objection valid. Testing should be heavy for a MTA.

monolithic program - Erlang-style process separation might be useful here, with each part running at different privilege levels.

dynamic language that permits monkey-patching - So what? Dynamic languages are not any less secure. Machine code injection often allowed by many C programs is the ultimate monkey-patching. If you want to make a Smalltalk image secure, you just expunge the Compiler objects and disable the various #perform: messages. No more compiling! No more dynamic evaluating or altering of Smalltalk code of any kind.

doesn't have Perl's taint checking support - Objection could be valid. Taint checking is a very good thing. However, it turns out that there is something along those lines for Python.

http://mail.python.org/pipermail/python-list/2007-February/5...

One thing that's nice about dynamic languages, is that many of them are immune to buffer-overflow code injection. That, plus taint checking actually makes me feel better about the security of properly architected and deployed applications in dynamic languages.

I do agree that the set of apps you mention are deceptively "enticingly easy." Caution is warranted!

sure most MTAs are byzantine horrors as you put it, but it's not like they need constant tweaking either. you set them up, and off they go (both exim, and postfix). we rarely need to touch their configuration once they're up and running. so why would i introduce yet another piece of infrastructure? what do i gain with this exactly?

Privileged ports are a mistake.

No, privileged ports are fine. The mistake is not having Linux capability-dropping in UNIX from day one.

Linux, there's another error

Having read the docs (and talked a bit to Zed at conferences while he was working on this), I think you've made a bad assumption here: Lamson isn't intended to be a general-purpose MTA.

In other words, don't think "sendmail/postfix replacement"; think "tool for building things like Posterous". Or, more clearly, it's not about delivering mail, it's about processing mail. And for that, it appears to be a huge improvement over the traditional state of the art.

Attacking sendmail at this point is a bit silly. There are numerous options available that don't require learning sendmail's configuration syntax.

While this project seems interesting, I'd be curious to see what its performance is like. High volumes of spam make performance a top concern.

is there similar software out there anywhere else? i am kind of stunned if this is the first attempt at solving this problem. it seems like a niche that might be dominated by an obscure commercial package but i didn't have much luck with google.

[later] i'm impressed so far, i haven't thought about email like this in a long time.

Qpsmtpd is similar (Perl instead of Python):

http://smtpd.develooper.com/

people have been using mta pipes to all sorts of scripting/dynamic/futuristic languages for years. that's what procmail is, except it has an ugly language. however it's not like one is using this 10 hours a day. you set it up, and you are done.

if this is 1970ish, then so is typing ls (forks and pipes galore) on a terminal, and i don't see anyone complaining about that. i'm not exaclty thrilled with the use of a SQL backing store either, more to install, more to monitor, more things that can go wrong.

  body = view('confirmation.msg’).render( list=list, [...]

Rebinding the list builtin in the snippet on your homepage? Is there a good reason for that?

No, there's no good reason for it. The binding doesn't "go" anywhere, so it's not that big a deal either, but it's "bad style".

That's not rebinding. That's a keyword argument.

Now, the 'list' in the argument list is rebinding.

Try this one in Awk

http://www.proweb.co.uk/~matt/awk/smtpd.awk

Reply on news.ycombinator.com