Welcome to WebmasterWorld Guest from 18.104.22.168
I have been methodically going through the top email clients searching for a replacement for my email system. My current system is this wild Rube Goldberg like contraption that involves numerous programs to accomplish.
I use a smtp/pop client/server program called Hamster. It collects all pop email from the web and sends all email out. It is always running and some of my sites send direct email to the server. The really nice part is that it also pulls Usenet from multiple servers and makes it all appear seamless. That means I pull from 5 Usenet servers and they all get merged into one. Hamster knows from the group name which server to use when posting outbound messages. It's a pretty slick system actually, but it isn't all that user friendly.
I have been using a Dos email and news program for eons called YARN (Yet Another Read News). Yarn is super fast, bullet proof, uses stock message formats, has many "programmable hook points", you can use your own text editor, and can handle everything from threaded email lists to unlimited folders. It's extremely safe in that all attachments must be confirmed before decoding and it will _never_ launch an attachment (you manually have to go dig for the attachment via a file manager).
The biggest draw back to Yarn, is it's limited address book capabilities and folders can not be nested. The program is just starting to show it's age. So, I've been searching for a replacement for several years.
Some how I need to get email from Hamster into Yarn. Most email clients have some sort of email downloader - Yarn does not. Yarn imports messages and news in SOUP packet format. Soup is a fairly old message standard that was used during the hay day of Fido Net and other BBS packet networks as an offline reader format.
To grab email and create "soup" packets for Yarn to import, I use Souper 95. It's a pop and news client that connects on localhost to Hamster and creates packets for Yarn to import.
At each point in that system, I can do something with the messages. This is where it leads to the Rube Goldberg like setup:
-> Hamster client/server grabs pop email from a few dozen email boxes on the web.
-> small perl program parses the Hamster database of messages adding or removing headers - and/or spam.
-> Souper connects to Hamster and downloads new messages like any email download. It also sends any new messages.
-> Souper creates the SOUP format packet for Yarn to import.
-> There is another hook here to call a program with the Soup packets if I choose.
-> Call Yarn import routine to import and filter email and news into the Yarn database.
-> There is another program hook here.
-> Finally, Yarn starts and I'm in my email program.
Depending on the number of messages and the number of Usenet servers connected too, the above process takes about 30 seconds for an email run. I usually run hamster on a scheduler to grab pop email off the net every 15 mins.
What's nifty about Yarn, is when it comes time to reply to any message. Yarn does not have a text editor in it. You configure an external text editor yourself. I use my favorite DOS editor (Boxer).
-> choose reply in Yarn.
-> yarn passes the message file to an external program. Usually that is a text editor, but you can point at a utility if you want to do something with the message before passing it to a editor.
-> call your editor and compose the message.
-> Since it is dos, Yarn happily suspends until it comes back from the external call to your editor.
-> finish your compose and the file is passed back to Yarn. That is another hook point I use to manipulate the headers and ad sig files, change the "from" line. etc.
-> As you exit Yarn altogether, the last thing it does is create a soup packet for souper 95 to send out.
I didn't even mention the decoding of messages that takes another external program, or a encryption program like PGP support. Whew. Now you see why I call it my Rube Goldberg email system.
-> Check what files need to be compiled
-> Compile the .cc code
-> Assembly the resultant .s code
-> Link the resultant .o code against a) system provided or b) user provided libraries.
Only that everything happens transparently to the user, thanks to utilities like make and the scriptable shell.
What you're doing classifies, from my point of view, as the "Right Thing"; write some batch files and you'll be happier, then you'll wish to be using Bash...