On Tue, 2009-09-08 at 12:08 -0700, John Hardin wrote: > On Tue, 8 Sep 2009, Clunk Werclick wrote: > > Sadly, no. As Fetchmail is polling a remote POP3 server, the only part > > of the system to see *all* of the information, is Spamassassin. The MTA > > only sees 'localhost' from Fetchmail. Postfix parses out some > > information, but the client IP is missing. If I could change the way > > Spamassassin logs and what it logs, I would be - how do you put it - > > 'cooking on gas'. > My system is fairly close to that: - fetchmail gets incoming mail from my ISP using pop3 - fetchmail passes it on by handing it to a script that is called by the 'mda' directive in .fetchmailrc - the script is a pipeline that is essentially "spamc | spamkiller -c sendmail" where spamkiller sends anything marked as spam to /dev/null and the rest are handed to postfix.sendmail to be passed to Postfix
In my low throughput mailing system I can trace messages through this fairly easily: - fetchmail reports reading the message, giving recipient and size - spamd reports the msgid and, because fetchmail is single threaded, this MUST be the msgid of the message fetchmail last read because its reported as spamd receives it from spamc - spamkiller reports what it will do with the message, logging the envelope sender. Again, this MUST be the message that spamd last released because its output immediately after spamd released the message. This can be linked back to the msgid reported by spamd by the spamd thread's pid. - postfix/pickup reports the envelope sender, providing a link back to spamkiller. - fetchmail reports flushing the message or reading the next one. In summary, it is possible to trace the message's progress through the chain even though the same identifier isn't used by all the processes in the chain. This is helped by the fact that all the processes in the pipeline are single threaded and their processing is constrained to be a single synchronised execution path by the pipeline. The effect of this is that fetchmail never reads the next message before the current one has been binned by spamkiller or passed to postfix. In checking this I followed through two sessions in which fetchmail picked up 2 and 13 messages. Martin