I'm not sure what "not integrated into the IMail stream" might mean, in the context of "Using the 20000517-DM01 doc to integrate a process into IMail" as somehow different than what Declude does. It uses the same hooks, no?
Obviously, the spamc/spamd pair and multi threading will be necessary. Spamassassin scans can run multiple tens of seconds when the 'net is "acting out"<g>. I see no reason why I can't run several threads. Why the hell else lock the Q files (keeps them out of Q manager's hair)? I sure hope that's what Declude does! I couldn't really say, as I'm only a few thousand messages per day. As to integration with IMail, the Inbound Delivery rules detecting SA headers ought to do the trick (except for bounce, I imagine - But bounces contribute to the spoofed spam problem anyhow). I'd love to hear what I've overlooked. Remember, my goal is to distinguish between SPFNone, SPFUnknown and SPFSoftfail. As far as I know, nobody is returning that info, at least not to IMail. Dan Sanford Whiteman sez: <snip> Not only, as Bill noted, is SA not integrated into the IMail stream, running the Perl-per-process version of SA--forcing the Perl interpreter and the entire SA rulebase to be loaded on every incoming message--is resource suicide. </snip> To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
