Gene Heskett a écrit : > On Thursday 09 February 2006 03:47, jdow wrote: > >>From: "Gene Heskett" <[EMAIL PROTECTED]> >> >>>>Procmail calls SpamAssasin and feeds the return off to the spool >>>>file. >>> >>>Ok, sub getmail for both fetchmail and procmail, since getmail can >>>handle the SA pipeing you are doing with procmail. Then run dovecot >>>on that box to serve kmail on this box? I have the kmail fetching >>>turned off on that box, so I'd assume I can give getmail a trial run >>>and see if what it fetches it shows up in kmail on that firewall box >>>as a new mail, if that works, then setup dovecot as a pop3 server to >>>serve the kmail requests from this box. Have I got it right? All >>>running as the user gene I'd assume? >> >>Only if getmail combines fetchmail and procmail including procmail's >>ability to write rules for redirecting mail or applying filtering to >>it. >> >>Kmail would simply read from the imap port you create. It's still >>write to your ISP's mail server. >> > > First, getmail is out as far as putting it on the FW box, the python > install there is several releases too old. > > Further reading on fetchmail tells me that it hands the incoming mail > off to sendmail via stuffing it into port 110. Datapoint as I try to > get my head around the mechanics of this. > > It is sendmail then that listens on port 110 and writes to > the /var/spool/mail/username file. Datapoint again. > > So there is a potential place to put a |spamc| is there not?, between > fetchmail and port 110? A hack to fetchmail maybe? Datapoint. > > Experimental results.. I grabbed a copy of /var/spool/mail/gene to > another file while it had some content, then did a 'cat filename|spamc > >>filename2' > > > This did properly scan & add the headers that it had done so to the > first of the 3 messages that were merged into filename, but did not > re-trigger itself on the next 2 messages also in that file, therefore > they were not scanned and marked up by spamc. > > So it appears that wherever spamc is inserted into the path, it must be > presented with a single message complete with an EOF indicator of come > kind. Looking at the src file, it doesn't appear there is a quick, > dirty, and 100% dependable way to filter the output of the cat command > and break it up into one stream per message. But I haven't ran a > tcpdump to see how its formatted on the network traffic yet. The only > thing I can see is linefeed,linefeed,From and since theres no way to > stop me from doing it in a message I send, it doesn't look that > reliable to me. > > From > > Is that treated as a new message? I think not. I'm going to go look at > the fetchmail code, maybe I can make a patch for it to do this. >
once fetchmail has read the message, it can: - put it in files. this is what you do. - run an MDA. so you could run procmail or maildrop or a (correct) script. In short, fetchmail runs a command (it pipes the message). - forward to an smtp server. This is the simplest to configure if you can afford to run an MTA. you'll need to choose which method is appropriate for your situation. if you don't feel yourself installing an MTA (this is not difficult, but requires some efforts to do it correctly), then go for the MDA method. reread fetchmail docs in both cases.
