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 <jch(_at_)honig(_dot_)net>
http://www.honig.net/jch
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers