Well, that was precisely what I was looking for. Can't believe I
overlooked it in the config....
But now that I have found it, I enabled it, and now I can't get the
WhiteListManager mailet to do anything. It created a new table in the
database. But all mail going through it is apparently ignored. I've
set the log levels to 'debug'. IIn the log, I see the "servicing.... by
White List Manager Mailet" for outbound emails. But nothing ever goes
into the database. Also, I set an email address to do the
display/insert/etc. commands. All mail sent to that address pass right
through it and end up undeliverable on the spool.
So it looks like the mailet is there and is definitely getting called
based on log entries, but it is completely inactive. Is there some
trick to waking it up? (I simply enabled the block that was there. So
the automaticInsert is definitely enabled. Are there any other flags
that can be set to make it be a little more verbose in the logs? I'm a
Java programmer. I can debug. I was just hoping to not have to get
into the source to figure this out.
Thanks.
Jerry
David Legg wrote:
Hi Jerry,
I too have been using James 2.3.0 for just over a week now. As I
mentioned in another email I've been very impressed with it.
I figure this isn't going to be rocket science to write both the
outbound mailet that stores in the db and the inbound matcher that
matches against the entries in the table. But I would like some
comments on a) if this has already been done with existing
matchers/mailets already available, and b) if there are horribly bad
issues with doing something like this that I haven't thought about?
I believe this has already been thought of. Have a look for the
following text in the config.xml file: -
<!-- Whitelist Management -->
<!-- Manages for each local user a "white list" of remote addresses
whose messages -->
<!-- should never be blocked as spam. -->
<!-- -->
<!-- If <automaticInsert> is true, it will check, for a local sender,
if a remote recipient -->
<!-- is already in the list: if not, it will be automatically
inserted. -->
<!-- This is under the interpretation that if a local sender X sends
a message to a -->
<!-- remote recipient Y, then later on if a message is sent by Y to X
it should be -->
<!-- considered always valid and never blocked; hence Y should be in
the white list -->
<!-- of X. -->
I considered enabling this section when I did my configuration but
decided not to in the end. Why? Because so many spam emails today
have spoofed sender addresses that it is bound to happen that a spam
pretending to be from the person in the white list will be sent.
Perhaps the chances of this are small... I don't know. But I thought
I'd see how effective the Bayesian filter was first.
- David.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
