Kyle Wheeler wrote:
On Wednesday, June 11 at 05:01 PM, quoth Hugo Monteiro:
Have you tried the plugin using the mailtrain backend?
The antispam plugin? No, I haven't... mostly because it looks like no matter which backend I use, I'd have to alter the user-visible interface to my training system (which I don't really want to do), and it still doesn't handle the "altered message" problem.
Basically it will forward the message, as attachment, to spam/notspam addresses that you define. That includes the use of a %u variable expansion, if you choose to use retrain addresses like like spam-username@domain.com or something. I've been pretty happy with with it and it scales a lot better than piping the message into a retrain command, since the mail system itself will handle the load in a more intelligent way.
Hmmm, load is something I hadn't thought about... (the system I'm working with at the moment has plenty of capacity to spare). That's a good point. Just thinking out loud here...
Couple possibilities:
- Have an SMTP server dedicated to spam re-processing. This dedicated function SMTP server could use your existing scripts to strip the unwanted headers and then pass it back to your standard server. This would be trivial with Postfix, either using domain mapping or dedicated IP/port listeners.
- If you're not using an SMTP server with Postfix's flexibility, use something like smtpprox to add it.
Bottom line is use a tool that works within the IMAP server (the anti-spam plugin) to detect mail changes and then pass the message on to a separate process for treatment.
Daniel