rbl config question

[scottnelson]

Which module actually does the rbl processing?

I have entered the
zmprov mcf zimbraMtaRestriction "reject_rbl_client bl.spamcop.net"

command, but doesn't seem to stick for some reason.
When I do a: zmprov gacf | grep zimbraMtaRestriction
right after I add it, it comes up but after while, nothing appears.
Like I cleared it out somehow.
Would a Admin Console GUI change clear RBL's out?

Also, I need to whiltelist the RBL's by IP Address, which one of these files would the whilelist need to go in:

/opt/zimbra/conf/salocal.cf
/opt/zimbra/conf/salocal.cf.in
/opt/zimbra/conf/amavisd.conf
/opt/zimbra/conf/amavisd.conf.in
/opt/zimbra/conf/spamassassin/local.cf

??

Also, what's the difference between the ".in" files and files without the ".in" extension ?


Searching for whilelist stuff doesn't really turn up anything on zimbra forums search that relates to what I need.

Thanks in advance. :-)

Scotty

[phoenix]

Welcome to the forums.

You can use whitelist rules using rules_du_jour form link or create your own, have a look at this page.

The zmprov command for changing the RBL list should persist, what circumstances seem to make it change?

The .in files are the default configuration files for Zimbra it uses them to create the 'normal' files on a restart. You can modify the .in files but they will be overwritten on a Zimbra upgrade.

[scottnelson]

Thanks for the info on the ".in" stuff .
Makes sense.

I am not sure what causes the rbl's to not show up when I run the:
'zmprov gacf | grep zimbraMtaRestriction' command to check for what rbl's are being used. More than likely it's something I did but don't know what really. I suspect that when I do some global config change via the gui, it wacks it. <shrug>

So zimbra is OK with me mucking around in the:
/opt/zimbra/conf/spamassassin directory?
There are /conf directories everywhere so I just want to make sure that:
1. I am making the changes to the right config files
2. I don't hose something up that zimbra modifies or needs to modify which then overwrites what I just changed or worse, some feature stops working
Just wasn't sure if zimbra had it's own conf stuff for to configure spamassassin or spamassassin used the stuff in the /opt/zimbra/conf/spamassassin directory.

I have seen the"rules_du_hour" reference come up a couple of times but not quite ready to try that yet, though it looks real easy to setup.
Looking at some of the whitelist stuff, saw some stuff I wouldn't want to whitelist so would have to go over the rules before I made the jump.


Thanks again. :-)

Scotty

[scottnelson]

Figured out what is wiping out the RBL list from what I enter via the:
zmprov mcf zimbraMtaRestriction "reject_rbl_client bl.spamcop.net"
command.

I made a change in the GUI, via "Global Settings", "Anti-Virus" tab and changed from 2 hours to 5 hours and then did the 'zmprov gacf | grep zimbraMtaRestriction' command and Viola! No RBL's.
LDAP magic I suppose. ;-)

Don't see this as a show stopper or anything. Don't plan on making many "Global Settings" changes anyway.

More FYI than anything else. :-)

I'll submit this to Zimbra just so they know and all.

Scotty

[pacsteel]

Just for information, in case anybody else --like me-- runs into this issue, it is bug 8146, fixed as of 2008-02-21 (which probably puts it in version 5.03).

However, if you can't upgrade for some reason -- again like me-- here is a work-around that makes it persistant so you don't have to opening up a console and running zmprov to reset the settings all the time.

Edit the file /opt/zimbra/conf/postfix_recipient_restrictions.cf

and change (don't comment it out, actually change it) each line that has an RBL you want to use. For example, from this:

%%contains VAR:zimbraMtaRestriction reject_rbl_client cbl.abuseat.org%%

to this:

reject_rbl_client cbl.abuseat.org

Reload your postfix settings, by making a change in the GUI, via "Global Settings", "Anti-Virus" tab and changing from 2 hours to 5 hours for example, or zmcontrol stop & start.

The 'zmprov gcf zimbraMtaRestriction' command will not show it taking effect, but if you watch the appropriate log you should see it start rejecting messages. 'tail -f /var/log/zimbra.log | grep NOQUEUE' works on my version, other versions may log it to different places.