fwiw: my team already has an automated-deployment rig setup for email servers (Ubuntu + Postfix + Dovecot) we routinely run for rebuilds of email servers for our teams internally (with NO external-SMTP/MX gateway in or out... which means it's an email server that serves internal-to-VPN-only connections... so we do not have to deal with security-attacks, spam, and the like).
Given this, we figure it's not terribly hard to add
Apache SpamAssassin to a test server, run my above emails through it (for a) spam and b) not-spam "programming"), export the resulting database info somehow into a Fastmail-compatible "data package"... and try to get Fastmail to "import" this into their stuff (the last part I anticiapte being the most-difficult osbtacle).
(We run lots of server apps that are new to us as development+test systems. It's part of our regular work projects. So we're not deterred, daunted, or "scared" by prospect of this. Especially for a one-off effort that we have no intention of running in production, and only for this one particular task.)
QUESTION:
Other than getting Fastmail to cooperate: does anyone see a problem with this line of thinking? And/or can anyone offer a better way/path to solve this overall issue (whether or not we generate our own bayesian spam/nonspam data)?
Quote:
Originally Posted by hydrostarr
The Spam/non-Spam processing going WAY too slow.
[...]
My current idea: run a bayesian-database-generating gizmo on one of my own machines/servers and given them the data and they insert said spam-bayes data into whatever mechanism they have. And I'll work to generate compatible data for the "import." However... I'll be surprised if I'll be able to get them to do this.
|