-
1. Re: Request for help... integrate jASEN (anti-spam)
Andy,
It seems like implementing this as a regular mail listener would be a bad idea. The flow would (I think) look like this:
1.) Message comes in via SMTP, and is streamed to the DBase.
2.) JASEN mail listener is called, with the header info and the blob id of the message.
3.) JASEN decides that it needs more than just the headers to figure out if the message is spam.
4.) The entire message is loaded from the dbase and turned into a JavaMail (so that JASEN can do something with it).
This would most likely happen for EVERY message that comes in via SMTP, which means that if we ever turn spam filtering on, well....we'll have a db write-read-messageinmemory (probably in tandem) for every message.
Seems like this defeats the purpose of streaming the message to the database, as per the JBCS artchitectural design (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=83822)
I don't mean to hash through what's going on in that post in this post, as I'm more interested in figuring out a good spam-filter for JBCS in its current form.
That said, do you have any thoughts on how SPAM filtering should look (perhaps in a world where JASEN or a JASEN-like spam filter could be designed however you like)?
Thanks!
David -
2. Re: Request for help... integrate jASEN (anti-spam)
I agree with you that JASEN loading the whole thing with JavaMail is BAD. I just think that having a BAD one that is understand to reduce scale is better than nothing.
Ideally:
0. Mail object should have properties that can only be set by maillisteners (simple to add)
1. JASENJMSMailListener catches incoming LocalDeliveryQueue. Notices that the "JASENRating" is not set.
2. JASENJMSMailListener sends the mail to a spamrate queue
3. a DeliveryMDB instance is assigned to the spamrate queue
4. the DeliveryMDB delegates to a Jasen MailListenerChain
5. the mail listener chain contains JASENRatingListener
6. the JASENRatingListener reads the mail a chunk or two at a time from the DB (NOT using JavaMail) and then sets a rating in the mail headers and on the mail object properties (because we don't want incoming forged spam headers).
7. the JMSMailListener (next in chain) puts the mail back on the incoming queue (which delegates back to to the Local delivery chain).
8. The local delivery chain now sees the flag is set
9. on the local delivery chain a listener should (be configurable) and set Junk on the mail properties (added above) if the mail's spam rating is above a particular number.
10. eventually we'll have a mail listener that allows user configurable filters but for now the main local delivery mail listener should read the properties and one of the props should be "Flags' {'Junk'} which should be set.
However it would NEVER be incoming to DB and in memory in tandem even with the crappy version because we have to get the mail in the DB before sending a 250 code or we're lying (meaning 250 == some guarantee of reliability). This is explicitly why spam rating should NEVER be done on an incoming filter (make the SMTP client wait for spam processing is dangerous to say the least). For now I say "do the crappy version and peeps who want spam rating will just have to take their 20mb mails in memory and like it'... We'll work with the JASEN guys or fix JavaMail later.
-Andy