On Donnerstag, 7. Juni 2007 Tom Allison wrote: > If you want to make dbmail capable of doing spam filtering... > wouldn't it make more sense to simply pipe the spam filtering in > front of the dbmail interface like procmail does today? I'm stuck on > this one. I don't know where there is much advantage here.
It should never *do* spam filtering, but *support* it. The idea is this: - there are distributed checksums like DCC, pyzor, razor - they are reported by thousands of mailservers, which calculate checksums on every e-mail they receive - once a certain checksum gets a lot of hits, the probability that it's spam increases - the disadvantage is, that if you're the first who gets hit by a new spam wave, no checksums will exist - so if you can, by the end of the day for example, later reprocess those e-mails with a high probability of being spam, and filter them, your system works better - this is especially true for Sunday night, you can reprocess those spams that arrived during the weekend, so people on monday morning will have even less spam than before It could well be that soon e-mails with pictures will be delayed by an hour or so before giving them to the users, just to recheck them for spam checksums later. It sounds strange now, but when spam rates grow, things have to be done. Another option would be to reject e-mails containing inline pictures that are highly probable spam, and only allow attached pictures. 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
