On Dienstag, 8. Mai 2007 11:40 Aleksander wrote: > > But instead of (or in addition to) this INSERT, one could > > call an external script, which marks or de-marks this message (I > > mean a true rewrite), so the content of the message is overwritten > > with the result. > > Example: the subject "penis enlargement" would become "[SPAM] penis > > enlargement", etc. > > If you did that, you would lose the message itself, spamassasin/dspam > wouldn't have the information for relearning. Well it might be a > problem. I would prefer to keep the message with it's headers > pristine, X-DBMail-PhysMessage-ID being the last modification.
No, SpamAssassin keeps the original message in rfc822 format as a separate MIME attachment, with all headers. This part can be extracted an learned, reported, whatever. > You actually rescan all messages daily for viruses and spam, all of > them? Nope. Just for some special users. If that would be for all messages, the script would have to keep an eye on cpu usage, and only run when the server is bored anyway. > > dbmail-rewritemessage(message_idnr) > It wouldn't be too hard to do I guess. And would be a big advantage over other mail servers, much easier for SPAM processing. > > I totally agree here: When we insert new columns into > > dbmail_messages, the SPAM state of the message could be saved. It > > should contain points (like from SpamAssassin) and the timestamp > > from when it was checked: // for postgres: > > points NUMERIC(5,2) > > checktime TIMESTAMP DEFAULT current_timestamp NOT NULL > > I'm not sure if points etc should be there too, sounds like > duplicating the dspam database to me. With sa it might help, I'm not > too familiar with it. But you can't get the points easily, or even search for it. If you want to re-scan all messages within the range of 4-8 points (just an example), you can do a simple SELECT messages WHERE checktime=today AND 4<points<8 (just metacode of course). When the points are not there, you must call dspam or whatever -> more cpu usage, slower in searching. The points are within SA's headers in the mail, but that's also quite slow to find. I believe storing SPAM probability within a mail server directly is a) better for SPAM processing b) a cool and hot feature that nobody else has c) something that more products will have in the future. On windows, there are integrated platforms that work together, while on Linux we sometimes suffer from the "one tool for one thing" idea. Nobody runs a mail server without SPAM checks nowadays, so why not integrate them a bit? I don't want to melt them together, but a little help is always nice :-) mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0676/846 914 666 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: EA39 8918 EDFF 0A68 ACFB 11B7 BA2D 060F 1C6F E6B0 // Keyserver: www.keyserver.net Key-ID: 1C6FE6B0
pgp6O43eke0W4.pgp
Description: PGP signature
_______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
