Now why would a user delete mail from the spam folder if the script is
going to do it for you?
My entire setup requires very little training of users. They move spam
into folder. If it is a message that was marked as posible spam they
copy it into the notspam folder. Thats it. They continue with their
work. If they look in the spam folder they will see at most 29 minutes
of spam that has been put in the folder, otherwise it's gone.
Now consider this. Lets say you wake up in the morning and move 100
messages all at once into the spam folder. A trigger is going to launch
your external script/application 100 times and probably at a rate in
which your mail server is going to get load from the application being
run without it actually doing anything. A cron script will let you run a
batch of spams through and potential reduce the call to the application
doing the work down to once or twice. Each instance of a program is
going to suck up memory and other system resources. Do you really want
100 concurrent instances of dspamc running? Or would it make more sense
to keep the mail server happy and run the dspamc's serially, keeping
system resources free for the database server or dbmail-imapd.
This is just for things like spam training. Imagine if somebody setups
up a script to do some other inspection of the email. Perhaps a simple
thing such as a support mailbox that recieves emails in a certain format
that wants to mark a paticular item as responed to in another database.
Then the midnight tech support guy responds to 30 emails all at once
because his DVD just finished and them moves them off in bulk. This
script then is going to read the message, extract the ticket #, open a
connection to the database and update the record. Now all of a sudden
you have 30 queries hitting up your db at the same time. Not a big deal,
but for scalabillity this isn't going to work well.
Not to mention that each trigger would have to be defined somewhere and
know what script/application to execute. For a spam thing to work with
each user having his own spam folder, thats one trigger per user. Thus
creating a lot of overhead for the mail administrator when he wants to
set it up and change it.
This is also going to give dbmail-imap more work to do on every move
checking if the message was in a folder that has a trigger that runs
when a message is moved out and checking if the dst folder has a trigger
for a message moved in.
Triggers may work good for an installation where you have a small number
of users, but on a large scale in a corperate enviroment, programs
running on the machine where dbmail-imapd sits is going to cause
problems. It would be much simpler to have a timestamp field on the
mailbox it self as to when the last write activity took place in the
mailbox. This would allow for an external machine to access the database
periodically to check whether it needs to open the mailbox and perform
tasks. The only draw back to this timestamp is that all activity in the
mailbox must be done with dbmail daemons or other triggers may not take
place. This method will result in an additional query to the db to
update the mailbox's last modified time on each transaction performed on
a message in it. I guess each dbmail daemon could have a tuneable as to
whether it is going to update this field and on what events.
-Jon
Magnus Sundberg wrote:
Aleksander wrote:
Jonathan Feally wrote:
<snip>
As far as getting what your want done, I would suggest using a
script driven via cron every half hour or so.
Yes, I know of such a possibility but there's always the chance, that
the user deletes the mails before the cron shedule. And you would
need another special folder for false positives. Cron+scripts is an
ugly workaround, IMHO.
<snip>
How do you know that the content of the deleted mail was spam?
I beleive you need the user to claim that it really is spam, or false
positive, you can not jump to any conclusions. cron is in my opinion
the simplest solution and it does not complicate dbmail either.
Magnus
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
