nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] inc, slocal, procmail, ...


From: Jeffrey Honig
Subject: [Nmh-workers] inc, slocal, procmail, ...
Date: Fri, 4 Jan 2013 23:22:58 -0500

Here is my rant/ramble about fetching mail into MH/nmh follows.  I'm not sure when I switched to nmh, so I'll just use MH. 

When I first started using MH in 1985 or so, I was happy using slocal.  I had looked at procmail and decided that it's syntax was too cryptic.

Then I started getting more and more mail, which sendmail would try to deliver concurrently, causing  my unseen sequence to get messed up, among other things.

So, I looked at how I could implement something with inc to fetch and filter mail.  But that did not seem to do what I wanted.  I could have it put things in folders and then move them around, but I did not have much luck with that and the reason escapes me.

At some point I got fed up with all this.  At that point TCL was the new shinny, so I wrote a bunch of code to grab mail via POP in TCL/Expect which filtered it into folders. I believe I was using APOP to Qpopper, which worked adequately.  I might have had some C code do handle the low level I/O, it's been a while and I don't feel like searching a bunch of CM archives.

The heart of this was some TCL code that called functions to do filtering on the e-mail calling some functions to search the subject, body, to, from, cc, dest (to and cc), ...  I used mhl to pull this information out of the message.  I implemented this because I thought slocal's syntax was too primitive.  My UI is the native programming language that I'm using.  I'm a programmer, a programming language is my preferred UI.

Somewhat later, either APOP wasn't cutting it, or I had to switch to IMAP for work.  So I split the backend out and implemented a front-end around fetchmail that called my backend.  Now I am no longer dependent on a specific transport, I can use whatever fetchmail supports.

Somewhat later, in the last couple years, I realized how bad a choice TCL was and re-implemented everything in python.  I'm much happier with the code.  However, reading the recent e-mails I kick myself for not looking into sieve libraries.  That is something I'll need to look into. 

I do duplicate suppression via msgid in my scripts.  With TCL I wrote libraries that created files with a munged MSGID.  In python I use a DB database. 

I have routines to call bogofilter for analysis of the messages and can take action based on the three possible outcomes (SPAM, NOT SPAM and UNSURE).

My lessons learned from all this is:

1) Inc is very restrictive in that it only supports mail drops and POP.  That is a no-show for work where they use M$ products and disable POP.

2) Inc doesn't allow scripting to control what is fetched and where it is stored.

3) Fetching mail from the local maildrop or via local host delivery is much less prevalent that it was.

4) slocal is dated.  Procmail doesn't have a UI.

5) Fetchmail is great.

What nmh needs is some generic tools that can be used to fetch mail via:

1) Local delivery from the MTA
2) Fetch mail from the local maildrop
3) Fetch mail from POP, IMAP and all the other methods supported by fetchmail
4) Accept mail from a third party program (i.e. be an mda for fetchmail)

And then it should be able to provide powerful filtering rules in a consistent many when mail is obtained via any of those methods.

To me this means that the mail fetching function should be separated from the filtering/storing function.  The filtering/storing function could be used as a backend to inc, or called from the MTA's delivery agent, or from fetchmail running in the background.

Inc could be made more modular and invoke a function to fetch mail (from the local maildrop, or invoking another program, such as fetchmail), then run the filtering function.  We could at that point decide to stop directly supporting flavors of POP and rely on an external program such as fetchmail.

Hmm, maybe this was more like a manifesto.

Thanks

Jeff

--
Jeffrey C. Honig <address@hidden>
http://www.honig.net/jch
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]