> The problem I found with simply using the RemoteAddrNotInNetwork
> is that while it does not relay spam, it does accept it and store
> it in the spam folder. There is no mechanism reporting back to the
> spam sender
Have you looked at the <processor name="spam"> section? You can reply to
the sender, notify the postmaster, save or discard the e-mail, etc.
> spam folder with 10s of thousands of files.
As an aside, for systems this large, eventually you'll want to switch to a
database.
> if your users go to another machine and setup a new mail client,
> when they send a new email there is no report back to them that
> because of their new ip address, the email was rejected.
Again, check the configuration file. You CAN notify your user.
In my earlier scenario, this should not be a problem for me. Authorized
users would use SSH tunneling to access the mail server. Using SSH tunnels
is an advanced technique, but it completely eliminates the open relay issue,
while permitting arbitrary roaming.
As for spam directed to your users, have you enabled the various spam
filters already in the config file?
Matchers and Mailets are the key to using JAMES. You can write custom
matchers to eliminate additional classes of e-mail. I'm be tempted to write
one that reads regex expressions from a database table (or file), and
eliminates messages that match. Take a look at NESSpamCheck for some ideas.
You might want to recognize e-mails claiming to be from your own users and
reject them differently from how you reject other spam. For example, in the
spam processor you could check to see if the sender is one of your users,
and pass it to a different processor if it matches.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
