SpamWall Operations Manual

Recipient Verification

All SpamWall systems with the exception of the base SpamWall Lite edition are able to be configured with two main "recipient verification" methods which will allow the system to reject messages for unknown, invalid or unspecified recipient addresses at the initial MTA (mail transfer agent) connection level.

This is beneficial in particular on high traffic systems as rejection of messages for invalid email addresses immediately on connection to the system can substantially reduce overall processing load and improve email processing and transit time performance.

This feature can also provide solid protection against dictionary attacks and other similar types of abuse.

If the Recipient Verification feature is available on your SpamWall you will see a button named "Recipient Verification" in the left hand side menu.

SpamWall Recipient Verification Menu

The default setting for Recipient Verification on the SpamWall systems is "Disabled - No Recipient Verification" however this can be changed by the SpamWall admin as required to either the "Dynamic Recipient Verification" or "Specify Allowed Recipients" options.

SpamWall Recipient Verification Screen

Dynamic Recipient Verification

The Dynamic Recipient Verification method of recipient verification is an "auto-discover" type method which if enabled enabled the SpamWall system will first query the receiving email server(s) to see if an email user or account exists before accepting the message. With this method each query is cached by the SpamWall system so ordinarily only one query per email address is required to be made on the receiving email server(s) every 30 days. Due to what in some cases may be a significant volume of queries having to be made on the destination email server(s) the Dynamic Recipient Verification method is sometimes not suitable for SpamWall systems which will be handling higher email traffic volumes and as such the alternative Specify Allowed Recipients option may be better suited due to this method allowing your SpamWall to be "natively aware" of the recipient addresses it should accept email for without the need to make queries on an offsite source for this information.

Specify Allowed Recipients

The Specify Allowed Recipients method of recipient verification allows your SpamWall to be natively aware of the domains and email addresses which it should be accepting email for without having to query any external source for this information allowing it to reject email for unspecified and therefore unknown or invalid recipient addresses and domains. This is the most robust and reliable recipient verification method although it does require some degree of maintenance on the part of the main SpamWall admin and the Domain Admin users if enabled.

It's possible that unless your SpamWall system needs to handle a high traffic load you will not have to use any form of recipient verification as the SpamWall systems are designed to handle reasonably high email traffic loads up to and including moderate "dictionary attack" type activity without the need for unknown or invalid recipient addresses to be rejected at the MTA connection stage.

However aside from email traffic volume another reason to set up recipient verification on your system would be if any of your destination email servers are set up to issue post-delivery NDR reports. If so, this can result in what is known as "backscatter" when messages to unknown recipient email addresses are forwarded to a destination email server and this email server has been set up to reject email for unknown or invalid recipients.

In general, a properly configured SMTP server rejects unknown recipients prior to accepting the message and should not generate post-delivery NDRs so ordinarily it would not be an issue if a destination email server rejects email for unknown recipients at the initial connection stage returning a "User unknown" type response along with a 5xx code which would inform the SpamWall of the rejection and then the SpamWall itself would not issue or otherwise bounce back any notification to the sender.

However some email servers are configured to issue NDR's "post delivery" (after a message has been accepted) and then bounce back some or all of the message to the sender, which in the case of a Spam message is likely to be the email address of an innocent or uninvolved party whose email address has been used as a "forged" sender address by a Spammer. This again is what is known as "backscatter".

In summary, ordinarily the default "No Recipient Verification" setting is suitable for most applications unless the SpamWall needs to handle a high traffic volume or unless any of the destination email servers is set up to issue post delivery NDR type messages which could result in backscatter.


Setting up a Valid User/Recipients List

To enable the Specify Allowed Recipients method of recipient verification and set up a valid user/recipients list for all or some of the domains supported on your SpamWall first select this option in the Recipient Verification screen and then use the "Save Changes" button to update the setting.

SpamWall Enable Recipient Verification

After enabling the Specify Allowed Recipients option the system will automatically add all domains that have been set up in the IP/Domain Setup screen to the recipients list with an entry the in the "@domain.com" type "wild card" format so that email for all addresses at the domains will be accepted by default until such a time as the SpamWall admin implements a recipient list for any of the domains.

SpamWall Enable Recipient Verification 2

Once the Specify Allowed Recipients method of recipient verification has been enabled and all the domains being serviced by the SpamWall are implemented in the recipients list with a wild card type entry so that email for all addresses will be accepted by default the admin can then set up a list of specified email addresses (a "valid user/recipient list") for a domain at any time.

To set up a valid user/recipient list for a domain the admin would first enter all of the email addresses at a domain which the SpamWall should accept email for, these would be known as the "valid users". These would be entered into the box provided in the "name@domain.com" type format, one entry per line in the following manner:

user1@domain.com
user2@domain.com
user3@domain2.com
etc

SpamWall Recipient Verification 3

After adding the recipients address you would select the "Add Recipients" button to update the recipients database on the system.

The system will still accept email for all addresses at the domain you have added the recipient list for at this stage until the "@domain.com" type wild card entry has been removed so the next step in implementing the recipients list would be to remove the @domain.com wild card entry for the domain which you have added the recipients list for. This would be done by selecting the @domain.com entry from the list by checking the selection box next to it and using the "Delete" button.

This will fully implement the recipients list and result in all email for any addresses not specified in the list for that domain to be rejected as "User unknown" by the SpamWall at the initial connection stage.


After setting up a recipients list for any domains on your SpamWall using the Specify Allowed Recipients method you will then need to ensure that all new user/recipient addresses at the domain(s) are updated when a new email user account or alias is set up on the destination email server accepting email for the domain in question.

Adding new valid user/recipient addresses is done via the Recipient Verification screen in the manner described previously by adding the addresses in the "name@domain.com" type format one per line in the box provided and then selecting the "Add Recipients" button to update the list.

If you have first added user accounts for addresses in the Manage User Accounts screen you can "sync" the user accounts with the valid user/recipient list by selecting the "Import/Update User Accounts" button in the Recipient Verification screen. This will result in the email addresses associated with any user accounts set up on the system and associated with a domain that has a recipient list set up to be "synced" with the valid user/recipient list for that domain.

Specifically, the system will automatically add entries for any user accounts which do not already have an existing entry in the recipients list. The feature is mainly intended for convenience if for instance the SpamWall admin adds a number of user account via the Manage User Accounts screen, and in particular when the "Bulk Add" feature is used, then instead of having to manually add the email addresses associated with these user accounts all that would be necessary to import them into the valid user list for the domain (assuming that the domain has a valid user set up instead of the @domain wild card) would be to select the "Import/Update User Accounts" button and this will result in the accounts being automatically added to the valid user/recipient list on the system.

The valid/user recipient related data be maintained via the Recipient Verification screen which incorporates search and deletion functions as well as the ability to export the valid user/recipient related data to CSV format if desired.

SpamWall Recipient Verification Search

One other maintenance task associated with the Specify Allowed Recipients method of Recipient Verification is likely to be the removal of the email addresses associated with accounts and aliases which no longer exist on the destination email server.

Note that the SpamWall will automatically add or remove the "@domain.com" type wild card entry for any domains either set up or deleted in the IP/Domain Setup screen.

Other Recipient Verification Methods

The SpamWall API

The SpamWall API is available on all systems with the exception of the base SpamWall Lite edition.The API can be used for most regular management functions of the SpamWall system including the addition and deletion of valid user/recipient addresses. If you are able to carry out the necessary programming on your end to facilitate integration of the API with your existing user account etc databases this may be a method worth considering.

For more information on this consult the SpamWall API section of this guide.

Automatic FTP Update Method

The SpamWall systems also provide support for the automatic updating of valid user lists via FTP or SFTP.

The system can be set up to automatically retrieve a list of valid email users at any specified interval either from an FTP account on one of your servers or an account we can set up for you for this purpose on our network.

In order to use this method of updating the valid user/recipient list on your SpamWall you would simply need to provide FTP access to a file where the email user account and/or @domain.com type information would be placed. containing the basic values required by the system for maintaining the valid user list information. The valid user list data should be in a plain text file with addresses in the "name@domain.com" type format with one entry per line in the following manner:

user1@domain.com
user2@domain.com
user3@domain2.com
etc
EOF

The bottom of the valid user file must contain the "EOF" reference as in the above example. This will tell the system that the file is complete and intact. As a safeguard, the system will not update the valid user configuration unless this reference is detected.


The SpamWall system would be set up to retrieve and update the valid user data on your system at any specified interval (every 5, 10, 30 minutes, hourly, daily etc as required). SpamWall technical support would set up and configure the automatic valid user update system and you would then maintain the valid email user configuration as required from your end.

It is not necessary to maintain a list of valid users for all of your domains so for instance if you have domains which either do not receive a significant amount of email traffic or that are not likely to be the subject of dictionary attack or other similar abusive activity instead of specifying a list of valid users for these domains a "wild card" value can be specified in the "@domain.com" format with no need for a list of each and every user or account at that domain.
An example of this "wild card" setup in the valid user/recipient list would be as follows:

@example.com
@anotherdomain.com

The automatic FTP valid user update system is engineered to be fault tolerant in that if there is any interruption of the process the transfer and update of the valid user/recipient list will be halted and the existing configuration will remain unchanged.

The system can be set up to notify you via email if there is a problem so that you can attend to and resolve any issues on your end which may be preventing the update process from happening.

In order to use this method of automatically updating the valid user/recipient configuration on your SpamWall a function that will write your valid user list details to a text file every time you set up or remove an email user from the the email account or aliases database on your destination email server(s) should be reasonably simple to implement. This valid user update system is one of the easiest methods to implement and can provide the high level of control needed to automatically update and maintain this particular aspect of your SpamWall system.

Protecting Against Dictionary Attacks

The SpamWall systems are designed to handle a certain amount of low level "dictionary attack" type activity without the need for any special configuration.

A dictionary attack is when thousands of messages are sent to random and largely non-existent addresses at a given domain, either in an effort to get through to a few valid mailboxes, to carry out directory harvesting in order to determine what email addresses might be valid, or otherwise to overwhelm a mail server and effect a "denial of service" type attack.

With basically all of these messages being addressed to unknown users or invalid addresses being Spam/UCE etc the SpamWall system will usually block most of them so only a fraction will end up at the destination email server anyway. As a result unless there is some reasonably high level of dictionary attack type abuse happening with the domains being serviced by a particular system and this results in slowness with processing and delivery then most SpamWall systems will not require any type of valid user/recipient verification method to be set up.

The use of Recipient Verification can be of significant benefit when the destination email server is a Microsoft Exchange server. This is because Exchange is normally set up to protect against dictionary and "directory harvesting" type attacks by accepting messages for all recipients rather than rejecting invalid recipients and letting Spam senders know which accounts are valid. This behavior often results in very high Exchange server loads so the implementation of a valid user/recipient list on the SpamWall using one of the available methods can provide effective protection for Microsoft Exchange destination email servers.

Directory Harvest Attacks

A Directory Harvest Attack is a technique used by Spammers in an attempt to find valid email addresses at a domain by using brute force. The attack is usually carried out similar to a dictionary attack, where valid email addresses are attempted to be determined by sending thousands of messages to random variants of common usernames in an effort to find out which ones may be valid under the assumption that the receiving email server will issue a "user unknown" type response or otherwise respond with a non-delivery report (NDR) effectively telling the Spammer that the addresses where where were not rejected or otherwise notified as being unknown must be valid addresses on the domain. As detailed in the Protecting Against Dictionary Attacks section of this document Microsoft Exchange servers are normally configured to accept email for all recipient addresses whether valid or not in an attempt to protect against giving away information on possible valid user accounts during a Directory Harvest Attacks type incident.

 

next topic Advanced Settings