Ubuntu 804lts - Admin GUI Error for RBL's - Workaround
commnad line work around for RBL's
verify RBL's and block settings in use
zmprov gacf | grep zimbraMtaRestriction
to verify in postfix use
su - zimbra -c 'postconf | grep smtpd_recipient_restrictions'
I Used this command to add Mine: just change rbl server name
zmprov mcf +zimbraMtaRestriction "reject_rbl_client zen.spamhaus.org"
here is my list...
zmprov mcf +zimbraMtaRestriction "reject_rbl_client bl.spamcop.net"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client dnsbl-1.uceprotect.net"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client ix.dnsbl.manitu.net"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client dyna.spamrats.com"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client noptr.spamrats.com"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client all.rbl.jp"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client safe.dnsbl.sorbs.net"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client b.barracudacentral.org"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client psb.surriel.com"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client dnsbl.ahbl.org"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client dnsbl.njabl.org"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client bhnc.njabl.org"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client dnsbl.dronebl.org"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client rabl.nuclearelephant.com"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client multi.uribl.com"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client 0spam.fusionzero.com"
zmprov mcf +zimbraMtaRestriction "reject_rbl_client 0spam-killlist.fusionzero.com"
Guys.. CBL is part of spamhaus.. See the sites i have listed to check RBL's
I would look at these sites... every environment is different..
I don't have spamhaus in my list here because my untangle F/W box runs it as an DNSRBL...
Black list compared... this should be helpful for you :)
Blacklist Monitor » Statistics of accuracy and failure rates
Blacklists Compared, 22-Aug-09
DNSBL Resource: Statistics Center
DNSBL Information - Spam Database Lookup
drbcheck: dr. Jrgen Mash's DNS database list checker
Originally Posted by bbarrons
My MTA Postfix SPAM settings and explanation for each.
POSTFIX MTA Spam Settings
Hostname in greeting violates RFC - Reject Invalid or Missing Hostnames – on by default
This setting allows you to reject email from senders that provide invalid information about the hostname from which they are being sent.
When a sending server connects our mail servers, the first thing we require it to do is identify itself. The sending server announces its hostname with a "HELO" or "EHLO" command. Most legitimate email servers include in this command their complete domain name. This domain name is in a very specific format. Spammers often use buggy or hastily written software that does not bother to send a proper EHLO. Often, they send a single name (e.g. "server1") or a random number. This setting allows you to block email sent from servers that do not announce their hostname properly when they identify themselves.
Enabling this option is very effective at catching spam generated by computer viruses. It is not particularly effective at blocking spam overall, and can block a fair amount of legitimate email.
reject_invalid_helo_hostname (with Postfix < 2.3: reject_invalid_hostname)
Reject the request when the HELO or EHLO hostname syntax is invalid.
Client must greet with fully qualified hostname - Reject Non-FQDN Hostnames – In Use
This setting allows you to block email that does not appear to be coming from a specific server at a particular hostname.
When a sending server announces its hostname, it is supposed to send the entire address of the email server, not just the domain name (e.g. mail.example.com rather than just example.com). RFC compliant email servers will send this information in a specific format. This is called a "Fully Qualified Domain Name" (FQDN). Many spammers do not provide complete or correct information; they just use the top level domain name. This setting allows you to block email from a sender that does not provide an FQDN.
This option can block a fair amount of legitimate email, but it also blocks a fair amount of spam that would otherwise get through.
reject_non_fqdn_helo_hostname (with Postfix < 2.3: reject_non_fqdn_hostname)
Reject the request when the HELO or EHLO hostname is not in fully-qualified domain form, as required by the RFC.
The non_fqdn_reject_code parameter specifies the response code for rejected requests (default: 504).
Sender Address must be fully qualified – Reject non fqdn sender – on by default
Reject the request when the MAIL FROM address is not in fully-qualified domain form, as required by the RFC.
Client’s Ip address - Reject Unknown Clients
This setting allows you to reject email from senders that do not have a proper name tied to the IP address of their outgoing email server.
Every computer on the Internet has a unique address known as its IP address. Any server that is sending legitimate email should have its IP address tied to a domain name. This is done via a service called DNS, or Domain Name Service. Many spammers do not have any DNS information attached to their IP address, or the information is misleading.
When a server sends mail to you, we perform a reverse lookup of its IP address to see if it has valid DNS information. You can use this setting to block email sent from servers that either do not have DNS information available or have misleading DNS entries.
More information on reverse DNS checks can be found at Wikipedia.
We estimate that enabling this option may block around 1% of legitimate email but could also be effective in blocking more spam from reaching your email INBOX. This can add up to a lot of legitimate email, especially from mail servers using unreliable DNS servers or that refuse to put their reverse DNS in place correctly.
reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client)
Reject the request when 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address.
This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above.
The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address->name or name->address lookup failed due to a temporary problem.
Hostname in greeting - Reject Unknown Hostnames – Don’t Use
This setting allows you to reject email from servers that use hostnames that don't exist.
When a sending server announces its hostname, our server checks to see if that hostname has DNS information. Many spammers know that servers will block mail from people that do not use a proper EHLO (discussed above). They try to trick those servers by sending a hostname that's formatted correctly, but doesn't actually exist (e.g. "thisisafakehostname.com"). You can use this setting to block email from servers that use fake or incorrect hostnames when they identify themselves.
This option can block a lot of legitimate email, and is not particularly effective at blocking spam. It's not recommended.
reject_unknown_helo_hostname (with Postfix < 2.3: reject_unknown_hostname)
Reject the request when the HELO or EHLO hostname has no DNS A or MX record.
The unknown_hostname_reject_code parameter specifies the numerical response code for rejected requests (default: 450).
The unknown_helo_hostname_tempfail_action parameter specifies the action after a temporary DNS error (default: defer_if_permit).
Senders Domain - Reject Unknown Sender Domains – In USE
This setting allows you to reject email from email addresses that aren't properly set up to receive email.
Anyone can send email from a legitimate server using any email address as their FROM address. Spam can come from a legitimate email server and from a valid user of that server, but it can have a deceptive or fake FROM address. This spam would bypass any of the above checks although it would be traceable back to a specific user at an Internet Service Provider (ISP). We check the domain name after the @ sign given in the FROM email address to see if that domain has proper DNS information.
First, our email server checks the DNS "root name servers" to see if the domain in question exists.
If the Domain does, then our server asks that domain's DNS server for its information.
If the root name servers return an error that the domain does not exist, the email will be rejected as the domain is not known.
If the root name servers state that the domain exists, and there is a problem with the server that handles DNS for that domain, our mail server will ask the sending server to resend the message at a later date. The email will not be rejected, it will only be delayed until that DNS server starts working. This is to keep legitimate mail from being stopped due to a malfunctioning DNS server.
You can enable this option to reject email from domains that do not actually exist.
This can cause a small number of false positives because someone may send an email out using a new email address before their domain has been set up properly in DNS. It is, however, very effective at blocking spam. Because we are an ISP, and are constantly adding new domains, we do not turn it on by default.
Reject the request when Postfix is not final destination for the sender address, and the MAIL FROM address has no DNS A or MX record, or when it has a malformed MX record such as a record with a zero-length MX hostname (Postfix version 2.3 and later).
Installed yes via command line
Reject the request when mail to the MAIL FROM address is known to bounce, or when the sender address destination is not reachable. Address verification information is managed by the verify(8) server; see the ADDRESS_VERIFICATION_README file for details.