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


Reply via email to