Feargal Reilly wrote:
Hi,
I'm looking for thoughts on ways that dbmail could interact with anti-spam
software?
*SNIP*
I am being called by turns a heretic or an idiot for this concept BUT:
=== begin heretical thoughts:
- as mail is stored in a DB, all I want to do is add a few new fields
(BOOLEAN) to the DB and let a trigger(s) invoke (an) asynchronous
process(es) to spam check, virus chack, reformime the message *or whatever*.
- inbound messages would go direclty into the DB, but be flagged as
'pending processing'. Thereafter the message would not move - only its
flags would change.
- a user-specific set of flags would determine which filters - if any -
were to be applied.
- a stored procedure / trigger would detect the presence of one or more
'pending' messages, call up a dispatcher that would:
- read the user's preference flags, resetting the 'pending' flag to
'processed' state (pending_NOT) if no filters were wanted,
- ELSE notify the filters of the location / ID of the pending message.
- each filter would run - probably against a batch of messages,
SELECTING what it needed (header, body, attachment, or all) from the
message in the DB, do its job, notify the dispatcher to reset their
flags to 'done' *for that filter* on the messages in question (or reset
them themselves). Optionally leave the original in place and write a
modified message...
- when all filters that were required had finished, the message would be
either marked 'available for read' or deleted / moved elesewhere /
delivered to a separate 'box' / given a new X-header - whatever....
IOW - I would want any and all filters to *stay out of* any queues or
pipelines between the message store and the incoming / outgoing smtp,
pop, or imap processes.
This *should* let I/O remain simple, fast, and unbalked, and allow a
high degree of independence w/r the mix of filter modules to be applied.
Any delays would affect how long a message already in the DB waited
processing / final 'availability' to the POP or IMAP - but would NOT
slow down the incoming or outgoing communications with corresponent servers.
OK - smacks of legacy 'batch processing' - but filters can be run in
parallel, and that can be quite efficient on a DB-resident body of data.
-so batching here removes obstacles on the I/O and 'raw' mail is going
to get *into* the DB faster....
A goal would be that the 'pending' state did not last any longer than it
might under the traditional serial-process approach..
*BUT* - even if it DID, it would not choke the traffic on/off the box.
*While we are at it**
I want a message for a client flagged as an IMAP USER to have a 'isIMAP'
flag set. This sez that the message is 'persistant' in the DB, i.e not
deleted *just* because it has been read by a POP client. Another field
ID's which IMAP folder number (default null = INBOX) the user has moved
the IMAP message into.
Display to the IMAP client is then a SELECT <whatever> WHERE isIMAP=true
order by folder-number date ... or something like that.
Again, the message per se doesn't move, only the flags change.
If we have a RDBMS and don't *use* it as an RDBMS, we won't gain the
advantages of an RDBMS....
======
End heretical thoughts..
Bill Hacker
