Michael Monnerie wrote:
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.
Agreed, but it's up to the implementation.
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.
That's what I've done.
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 think you've misunderstood how the patch works. We do not mark
messages in dbmail_messages or elsewhere. When a message is moved from
or to a spam folder, a row indicating the message_idnr and direction
(moved "from" or "to" the spamfolder) is added to an additional table
called dbmail_cplogs.
That's all what dbmail does, everything else including keeping this
table clean is up to an external script.
I'd like this to be (near) real-time, so that a user can see the change
quickly.
I run my script every 15 minutes, but it's really up to you. You also
depend on the time the messages are processed.
-) 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.
Same story, the patch does not mark messages, it logs which messages
where copied only.
-) 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?
Well it's possible to do that with the current patch I guess. Btw, how
do currently feed messages to antispam/virus agents, via IMAP or do
export them, get the message via sql directly?
To sum up, your idea is to mark messages as spam in dbmail (not only in
message headers), while this patch simply logs which messages were moves
and in which direction. Correct?
I have to admit that tagging messages in dbmail as spam etc is
interesting, it does open up a few more possibilities.
Alex
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
