[nikkaelle]

The primary uses for procmail tend to be running a fixed set of rules to save mail to various directories or route it as input to scripts.

My use case needs to save it to a database and make various decisions depending on the sate of the database (e.g., send notifications to anyone watching the ticket and update due dates for the support SLA). Since this database access is more efficient if the process stays connected to the database, it's better to have a long-lived process which handles mail as it comes in than to launch a new script on every incoming email.

Lamson serves as both the procmail side and the script side. It's a long-running process that routes the incoming email to the appropriate business logic internally. And since it's in Python, it's easy to integrate with our existing Django database and business logic. It's not perfect, but it works well enough that I'm not actively looking for a replacement.

[greglindahl]

procmail+spamassassin is an example of a long-lived daemon and a client that talks to it, but indeed, spamassassin had to provide both parts because procmail doesn't directly do that.

I have 20 year old code that does the same client/server thing, by having procmail leave files in a directory that the daemon is watching for new files to appear in.

So I'd agree that it's a useful piece of sugar!

[nikkaelle]

I should have mentioned that I run lamson in maildir mode rather than listen on port 25. I have postfix configured to dump incoming email into a maildir, and my lamson process watches that directory.

So I guess the reason I don't use procmail (aside from it not having a release since 2001) is that postfix is sufficient :->