On Freitag, 27. April 2007 12:24 Aleksander wrote: > Michael Monnerie wrote: > You should now use the patch provided by Paul.
Yes, ASA there's the postgreSQL version. He only wrote about mysql/sqlite by now. > You can have different names for the spam folder, but then there's > the point, how do you know to which folder the spam message has to be > delivered then? The options include modifying the delivery method, so > that spamassasin or postfix queries dbmail tables, to find out which > of the user's folder is the spamfolder. Another approach is via sieve > scripts. Right. Until now, we didn't sort into user's folders - just marked the e-mail. Customers have to filter it personally. We should probably filter for those customers having dbmail, which would require modifications to SA/amavis to know where to deliver SPAM. This guarantees same names for SPAM folders. > Also, if you don't deliver spam to your users, that's not a problem > at all. One should never do that, except for very special requirements. > Also, you could give users a web interface, where they can choose the > spam folder from their folders. In terms of support it's easier to force a standard name for that box. > My users have only on spam folder. Spam mail arrives there. If spam > mail is not identified and arrives in Inbox, the user has to move it > to the spam folder. If the filter generates a false positive, the > user has to move the good mail out of the spam folder. Any > destination folder is good except the Trash folder, this one has to > also be marked manually, by setting the trash_flag. What comes to my mind now: When a user moves a message from SPAM to inbox, it would be nice to be able to do something directly. For example, insert a markup in a table with the message_idnr, so that we know we have to do this. Running a cron job every 5 minutes could then just search within that table and process everything. Or is searching for all marked messages cheap in terms of DB costs? I'd like this to be (near) real-time, so that a user can see the change quickly. > > -) We rewrite message subject, as well as the body, when a message > > is SPAM. Can this be done with your solution? > > You mean when a user moves spam message from Inbox to the spam > folder? Then the message is not changed, but the anti-spam agent is > told to update it's signatures. In case of false positives it's the > same case -- you really would end up with a message in your Inbox, > which has been tagged as spam, but your filter would have been > updated already and not repeat this mistake. As we tag a message (we do that full amavis "defang_spam"), I'd like to remove such markup from a "marked as clean" message, or add one when a message is marked as spam. I can think of two ways: 1) directly on user move or copy command, we immediately add/remove that markup, so that the destination folder receives the "new" message in the new form. This would be great. 2) Add/remove markup with a cron job. Not so convenient as 1), but still OK. > > -) I would like to be able to rescan messages that arrived today > > overnight. Like this, certain viruses could be detected when new > > antivirus signatures arrive, or whatever. Can we find out whether a > > message from today was marked as SPAM, but then altered by the > > client to HAM status? Such messages shouldn't be marked as SPAM > > afterwards again, of course. > > Yes, for me it's moving the message out of the spam folder to the > Inbox for example. I think I didn't explain it good: A message arrives, is recognized by SA as SPAM, and moved into the SPAM box. The user moves it to Inbox, via cron we learn the message as HAM. Overnight, another cron job re-scans all messages from today. Like this, it may find SPAM or a virus that wasn't found before. But we should know about messages that have been already manually changed by the user (eg. a SPAM that was moved to Inbox), because it can happen that even after re-learning it's still recognised as SPAM. That would move the message to the SPAM folder again, which must not happen. So we should be able to find out if a message was manually changed. If it was marked as HAM, but filters still think it's SPAM, we could then copy that e-mail to our SPAM department, who could have a look into it and improve filters. A very great opportunity to semi-automatically improve the filters, right? 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
pgp9ihlAHAWHP.pgp
Description: PGP signature
_______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
