RBL

Level 1

The RBL event functions the same as the SURBL event does. Incoming messages are checked to see if any sending server(s) are included on the list of the RBL servers listed. If a match is found, the service specified will be performed, (block, notify, quarantine). The RBL event may be limited to certain lines in the message. The default is to scan the entire header of a message. (It is not recommended to have more than two RBL list servers active at the same time as it may extend the scanning time with extra lookups.)

If you are using an SMTP scanner you have the option to use the RBL connection drop event. IP Reputation, RBL, and SPF drop at connection settings are recommended as default. This dumps any incoming message that fails these initial incoming tests, saving bandwidth and performance.

Level 2

The two free RBL servers that are recommended to use in GWAVA are:

  bl.spamcop.net
  sbl-xbl.spamhaus.org

If the RBL look ups are taking a long time to return, then most likely there is a DNS issue. Try using a different DNS server to see if that speeds things up.

One Symptom of this is getting duplicate email. If multiple copies of some emails are being received, we need to check the log files to find out why. One common cause of this is due to the sending server disconnecting while waiting for a response from GWAVA. This can be seen in the gwvsmtp log by following one of the instances of the received email through the log files (preferably one of the first mails received). The email will be received, scanned, and passed along to the GWIA, at which point GWAVA communicates with the sending email server to close the session so the email is received. If this scan process takes too long, some email servers will disconnect. This is evidenced in the log with the message "Socket read error: TCP session closed". In this case, GWIA has successfully received the email and will send it to the recipient, however, the sending email server has disconnected and so will try again later. This can happen multiple times for the same email.

Since we cannot change the time out on the sending server, we need to discover what is causing the scan to take so long. By speeding up the scan, we will prevent the server from disconnecting before verifying that it has successfully sent the mail. This shouldn't be necessary in most cases, as message scans happen in seconds. However, there are some problems that can cause scans to take 30 or more seconds. For example, GWAVA could be trying to do a SURBL or RBL lookup on the message, and that lookup may be failing. Careful review of the GWAVA log files will show what part of the message scan is taking so long. If an RBL lookup through one particular server is always causing this delay, then that server may not be functional anymore. Remove this RBL or SURBL server from the list of servers used, and this will speed up message scanning significantly, preventing duplicate copies of a message from being received.

Since the log files can be rather difficult to look through, support can help you find the reason for the scanning delay, and come up with a solution to speed things up.

If an email address exception isn't working for RBL, then you are most likely using the connection drop event. This will need to be disabled and then make sure 'enable message header scan' and 'block the message' are checked. If you'd rather leave the connection drop event checked then you can use an IP address exception instead.

If all email is being blocked because of RBL, make sure you are not using the RBL server "relays.ordb.org".

Hands On

1) Log into the GWAVA Management Web Page and go to Scanner/Policy Mangement | policy | scanning configuration | RBL

2) Make sure 'Enable RBL test', 'Enable message header scan' and 'Block the message' is checked.

3) Make sure 'Enable connection drop' is unchecked.

4) Make sure you have the two recommended free RBL server's in the server list, which are: bl.spamcop.net and sbl-xbl.spamhaus.org.

5) Send a test message via telnet to make it look like it was from an IP address that is on an RBL black list. 6) After the message has been sent, check the GWAVA/support log (/opt/beginfinite/gwava/services/logs/gwava/support) to ensure the RBL event fired.