XWall accepts the message, checks each selected methods and then triggers the action that is associated with the method that has the highest priority and a positive result.

You can select one of the following actions:

Discard message

The message is discarded. This means the message goes into a virtual wastebasket and no notification is sent to the sender or the recipient.

Encapsulate and forward to Postmaster

A new message is sent to Postmaster with information what method caused the blocking. Further the original messages is added as an attachment.

Forward to Postmaster

The original message is unchanged forwarded to Postmaster.

Forward to recipient

The original message is unchanged sent to the recipient. Basically this action does nothing and can be used in the ISP Edition to prevent blocking for a recipient.

Encapsulate and send to recipient

A new message is sent to the recipient with information what method caused the blocking. Further the original messages is added as an attachment.

Encapsulate and send to recipient without attachments

A new message is sent to the recipient with information what method caused the blocking. Further the original messages is added as an attachment, but the attachments of the original message are removed.

Send a non-delivery report to the sender

A non-delivery report is sent to the sender with information what method caused the blocking.

Mark subject

The subject is tagged with a short string identify the method that caused the blocking.

Here is a sample of the new subject line:

Drive yourself wild with a motor home... [surbl][heur][sls][bayes]

In this example [surbl] means SURBL, [heur] the heuristic method, [sls] means SLS/RBL and [bayes] means Bayes

Mark subject and move to Junk-E-Mail folder

The same as Mark subject but additionally the line X-XWALL-Spam: is added to the header of the message and can be used to trigger a rule in Outlook and move the messages to the Junk-E-Mail folder.

If you have an Exchange 2003/2007/2010 then you need to install XWALLFilter , which is an add-on to XWall, to automatically move the messages into the Junk-E-Mail folder or the recipient. See http://www.lakecomm.com/xwallfilter.html for more information on XWALLFilter.

XWall performs the selected checks based on the information that is available during the SMTP session. Basically this is the IP address and host name of the sending server and the envelope of the message.

If one of the checks fail, then the message is rejected during the SMTP session. This means that XWall does not accept the message. As a result the sending server is responsible for sending back a non-delivery report to the sender.

Because the message itself is not accepted, not every method can be used to reject during the SMTP session. For example, there is no reject because of a blocked subject, simply because the message with the subject never reaches XWall. And for the same reason it is not possible to exclude messages my such methods that require the message.

If the senders IP address is a internal IP address (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 169.254.0.0/16, 224.0.0.0/8) or the sender is allowed to relay or the sender is the Exchange or the sender is authenticated then XWall does not perform the selected checks.

XWall consist of a global exclude section, which is for all methods, a white list for known senders and a local exclusion for each method.

To let a message from michael@dataenter.co.at bypass all spam blockings add michael@dataenter.co.at to the to the list at Options->Exclude->E-Mail Address->Inbound MAIL FROM

To exclude someuser@aol.com from SLS/RBL only, you add someuser@aol.com to the list at Options->Spam->SLS->Exclude->MAIL FROM

The senders e-mail address (the MAIL FROM e-mail address) is may or may not, be the same as the e-mail address that Outlook shows you. So if your blocking or exclusion does not work, then the sender uses a different address than Outlook shows you.

The only way to find it out is to open the logfile of XWall (mb.log), search for the subject of the message and then you will find the e-mail address that you need to exclude or block.

Here is a sample from the logfile:

If you have Exchange 2000/2003 then you can get most of the information from the Internet header lines in Outlook. Open the message in Outlook and then select View->Options and here you find Internet header lines. Locate the line called ReturnPath: and this is the e-mail address that you need to block or exclude.

A sample looks like:

XWall use the following syntax when blocking or excluding elements

E-mail address

XWall compares an e-mail address case insensitive from right to left until a match is found.

This allows you to block a whole domain by typing @domain.com and as a result, bit@domain.com blocks rabbit@domain.com

If you add a space at the beginning, XWall interprets this as a full address and so bit@domain.com does not block rabbit@domain.com

File Name

XWall compares a file name case insensitive from right to left until a match is found.

This allows you to block all .exe by typing .exe and this will block notepad.exe

If you add a space at the beginning, XWall interprets this as a full name and so pad.exe does not block notepad.exe

Host Name

The host name is the name of the sending machine. Or more technically the name of the sending IP address (the DNS PTR). The host name has nothing to do with the senders domain.

For example if the sender is a customer of EarthLink, then the sending server may be something like asmtp-a063f35.pas.sa.earthlink.net, regardless of the domain of the sender.

XWall compares a host name case insensitive from right to left until a match is found.

To block all message originated from one of the many SMTP servers of EarthLink you type .earthlink.net

To block only this specific EarthLink server you type asmtp-a063f35.pas.sa.earthlink.net and add a space in front to make it an absolute name.

IP Address

XWall expects IP addresses in CIDR notation.

A single address is then either 10.0.0.1 or 10.0.0.1/32

For a range from 10.10.10.0 to 10.10.10.255 you need to use 10.10.10.0/24

Word/String

XWall scans for strings and not words.

To scan for words you need to add a space in front and at the end of the string.

If the string is cum (without the spaces that make it a word), then it would find the authors name which is Michael Kocum. Or if the string is sex then this would also find MSExchange.

However sex (with a space in front and at the end) find only sex and not MSExchange.

Wildcards

For words/strings, attachments and e-mail addresses XWall supports the following wildcards:

• ? matches one character
• * matches one or more characters
• # matches one or more digits

Note: Make sure the star * wildcard does not match more than you want. For example s*x would match sex, but also match the phrase See how exiting this is

Postmaster's e-mail address

E-mail address of the person who is responsible for maintaining XWall. XWall will send error messages to this address.

Notify postmaster when a new program version is available

XWall will periodically perform an online check for a program update and will send a notification to postmaster in the case a new program version is available.

Name or IP address of the Exchange server

Host name or IP address of the Exchange server. The default is localhost, which means that the Exchange server is on the same machine as XWall.

Exchange listens on port

This is the port that XWall uses when connecting to the Exchange server. If XWall and Exchange server are running on the same machine you may need to adjust the port that you have selected for the IMC. For Exchange 5.x you do this by changing the services file.

Refuse inbound connections on problems with outbound connections

If checked and if XWall is unable to establish a connection with the Exchange server, XWall will not accept incoming messages until it can communicate with the Exchange server.

Exchange needs authentication

Allows you to enter the user and password if your Exchange needs authentication before accepting an input.

Specify by e-mail-domain (ISP Edition only)

Allows you to define inbound e-mail domains that are on a different Exchange server.

If checked, XWall will write a logfile called MBYYMMDD.LOG, where YY is the year, MM is the month and DD is the day.

Directory

The directory where XWall will write the logfile.

If the Directory is empty, XWall writes the logfile into the directory 'where MBServer.EXE resides.

Note: This is a directory and not a filename. The filename will always be MBYYMMDD.LOG

Purge logfiles after x days

Purges the logfiles after the set number of days.

Verbose Logging

If checked, XWall displays and logs everything, whereas if unchecked only a minimal amount of information is logged.

Log Message Transfer

If checked, XWall displays and logs the communication of the message transfer.

Log Message Header

If checked, XWall displays the SMTP header of the message.

Keep a copy of every message

If checked, XWall keeps a copy of every message in the HIST-IN and HIST-OUT folder.

Make sure you have enough free disk space if you enable this option.

The message files are plain text files and contain exactly what was sent over the wire.

This means you can read the messages files in Notepad. If you want to extract an attachment from the messages then you can either rename the file to .eml and use Outlook Express or your rename the file to .uue and use WinZip to extract the attachment.

If you want to resend the messages then you can use SMTPSend with the -g option or you open them in Outlook Express and resent them from here.

If you want to resend more than one message, then either use CSVToEnv

Directory

The directory where XWall will write the HIST-IN and HIST-OUT folder.

If the Directory is empty, XWall writes the logfile into the directory where MBServer.EXE resides.

Purge message files after x days

Purges the message files after the set number of days.

General

Write Statistics File

If checked, XWall will write a statistics file called SRYYMMDD.CSV, where YY is the year, MM is the month and DD is the day. The files lists all inbound and outbound messages that XWall handled.

You can use Excel or any other program which imports delimited text files to run your statistics.

Directory

The directory where XWall will write the statistics file.

If the directory is empty, XWall writes the statistics file into the directory where MBServer.EXE resides.

Purge logfiles file after x days

Purges the statistics files after the set number of days.

Write SMTP blocking statistics file

If checked, XWall will write a statistics file called SPYYMMDD.CSV, where YY is the year, MM is the month and DD is the day. The file lists all messages that XWall rejected at the SMTP level.

Note: Due that the message are rejected before the sending server tells XWall to whom the messages is addressed, the CSV file does not show the e-mail address of the final recipient.

Write send statistics file

If checked, XWall will write a send file called SSYYMMDD.CSV, where YY is the year, MM is the month and DD is the day. The file lists all messages that are sent by XWall.

Write virus statistics file

If checked, XWall will write a statistics file called SVYYMMDD.CSV, where YY is the year, MM is the month and DD is the day. The file lists all messages that had a virus.

Options

Use long date in statistic file (yyyy-mm-dd vs. yy-mm-dd)

If checked, XWall will use a long date format in the statistic file.

If Excel has troubles showing the correct date, then enable this option.

Outbound Message Routing

Use DNS to send all messages direct to the recipients mail server

In this mode XWall queries the DNS server for the MX record of the recipient, connect to the recipient mail server and sends the message

Relay all messages through the smart host

In this mode XWall relays all messages to the smart host. Usually the smart host is the SMTP server of your ISP or some relay server in your DMZ

Use smart host only if direct connection fails

This is a combination of the two modes above. If XWall can not send direct, it relays to the smart host.

Smart host

The name or IP address of the smart host where XWall should relay to

DNS server

The IP address of the name server (DNS) which XWall should use to get the MX record(s) for the recipient domain.

Do not use a host name, because XWall can not resolve it to an IP address, because it does not have a name server (chicken-and-egg problem).

Note: If you use the word AutoDetect rather than an IP address, then the name server is read from the registry.

Refuse inbound connections on problems with outbound connections

If checked and if XWall is unable to establish a connection with the Exchange server, XWall will not accept incoming messages until it can communicate with the Exchange server

Specify by e-mail-domain

Allows you to define e-mail domain that need special routing, for example when a target server is behind a firewall or in a private LAN.

Enable outbound SMTP authentication against the Smart Host

User

Password

If your ISPs SMTP server needs an authentication before accepting an SMTP message, then you can define the user and password here.

Note: Do not use this unless your ISP requires it!

Connection Limits

Max concurrent inbound

Defines how many concurrent inbound connections XWall accepts. Setting this to zero allows unlimited connections.

Max concurrent outbound

Defines how many concurrent outbound connections XWall opens. Setting it to zero allows unlimited connections.

Concurrent outbound connections to a single host

Defines how many concurrent connections to a single host XWall opens

As a general rule you should not allow more than 8 connections for a 64kBit bandwidth or else you may have timeouts. If you have a 64K ISDN line, set inbound and outbound to 4.

Max recipients for an inbound message

Define the max amount of recipients in a single inbound message.

If the sending server sends more recipients, then remaining recipients are blocked using a
452 4.5.3 Too many recipients error

Allow Relay of SMTP Messages

If checked, XWall relays messages for recipients not defined on your Exchange, to the next SMTP host. This is either the relay host of your ISP or the final host, depending on your settings in Connections.

Relaying is only needed if you have POP3 clients in your LAN and you want to use XWall as the relay host for them.

Allow relay of SMTP message from reserved IP addresses
(10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 169.254.0.0/16, 224.0.0.0/8)

If checked, XWall allows s relaying for client from your local LAN.

Relaying is only needed if you have POP3 clients in your LAN and you want to use XWall as the relay host for them.

Allow relay only from host

Allow relay only from IP address

If you disable general relaying, then you can define which host (machine) or IP address relaying is allowed.

XWall compares host names from right to left. IP addresses are in CIDR notation.

If you want all the machines in the domain dataenter.com to be allowed, you need to add dataenter.com to the list. To allow all IP addresses from 10.10.10.0 to 10.10.10.255, you need to add 10.10.10.0/24 to the list of IP addresses.

Allow relay for authenticated users

If checked, XWall allows relaying for authenticated users, regardless of their IP address.

Note: You need to define which authentication method XWall should use in Authentication

Enable inbound SMTP authentication using User/Pass

If selected, XWall validates the SMTP client's user and password against the given user and password.

Enable inbound SMTP authentication using pass-through NTLM logon

If selected, XWall performs a network logon using the user and password that the SMTP client provided.

The user need to be in the format Domain\Useror User. If User is selected, then the validation goes against the local machine. If the local machine is a domain controller, Domain\User and User is equal.

Note: If XWall is running as a service using the LocalSystem account (this is the default), then Domain\User needs to be used, even when running on a domain controller. Using User alone will result in a logon error. As a workaround use either Domain\User or start the service using the Administrator account.

Note: Make sure the Guest account is locked or the logon of every user with every password will succeed.
See KB 251149 Guest Account Allows Relaying Regardless of Routing Restrictions

Enable inbound SMTP authentication using a SMTP query to Exchange

If selected, XWall queries Exchange with the user and password.

Enable inbound SMTP authentication using an external program

If selected, XWall calls the external program and passes the user and password as arguments. If the external program returns errorlevel zero, the user is valid.

Outbound SMTP options

Retry failed connection every xx Seconds

Defines how long XWall should wait until it retries a failed outbound SMTP connection.

The default is 1800 seconds, which is 30 minutes.

Retry for xx Seconds

Defines how long XWall should continue trying a failed outbound SMTP connection.

The default is 432000 seconds, which is 5 days.

Note: Set this to something between 4 - 24 hours, which makes more sense than the default of 5 days.

Retry non-delivery reports for xx Seconds

Defines how long XWall should continue trying a failed non-delivery report.

The default is 14400 seconds, which is 4 hours.

Outbound Exchange options

Retry failed connection every xx Seconds

Defines how long XWall should wait until it retries a failed outbound Exchange connection.

The default is 300 seconds, which is 5 minutes.

Retry for xx Seconds

Defines how long XWall should try a failed outbound Exchange connection.

The default is 604800 seconds, which is 7 days.

Check for an Exchange server before sending a message

If checked, XWall checks if the SMTP server announces the XEXCH50 ESMTP verb.

This will prevent XWall from accidentally sending a message to the wrong server.

In Exchange 5.5 / 2000 / 2003 the virtual SMTP server always announces the XEXCH50 ESMTP verb.

In Exchange 2007/2010 the Hub connector announces the XEXCH50 ESMTP verb only if Exchange Server authentication is enabled. Notes or GroupWise or any other SMTP server do not announce the XEXCH50 ESMTP verb.

Check for on-access virus scanner at startup

If checked, XWall checks for an on-access virus scanner at startup. XWall does this by writing out the Eicar Antivirus testfile (http://www.eicar.org), which is a harmless text file, and watches if some other program deletes or locks the file. If so, then an on-access scanner is running and the XWall directory is not excluded from scanning.

XWall then shows a warning and continues working, but the XWall directory should be excluded from scanning. When you don't exclude the XWall directory, the scanner will prevent XWall from accessing it's own files. Even worse, when you have enabled some kind of "cleaning" then you get absolute unpredictable results, but not what you might expect. More technically speaking the scanner can not clean a message, because it is a file scanner and has no idea how to handle a SMTP messages.

Even if it could clean the messages, then it locks the file to do so and XWall does not fight with the scanner for the file.

When a message comes in XWall saves the message in the MSG-IN directory and gives it an unique file name with a .tmp extension (MSG0117x.TMP for example).

Once the message download is finished, XWall renames the file from MSG0117x.TMP to MSG0117x.TXT. In the case a scanner is now scanning this file, the operating system does not allow the renaming and XWall considers this as a failure and tells the sending SMTP server about this.

If the renaming could be done the message will be place in the decoding queue and wait until the decoder handles it. If the scanner now scans the file, the decoder can not open it and so the message is lost. More worst, when the scanner deletes the file, then XWall is really happy about that fact, because it always really like it when someone deletes files behind it's back.

This all does not mean that you should not use a virus scanner at all. It only means that you should use the right way to scan your messages. Either enable the virus scanner in XWall, because then XWall has fill control over the scanner or use a SMTP based virus scanner.

Enable outbound message size limit

Enable inbound message size limit

Enables the inbound and/or outbound message size limit.

Inbound, Outbound

For inbound or outbound messages, XWall compares the list case insensitive with the name of the attachment from right to left, which means that .gif will block all gif files whereas picture.gif will only block a single file.

Note: Wildcards are allowed.

Action

List of Actions

Note: Microsoft defines the following file extensions as unsafe because they may have script or code associated with it.

Inbound, Outbound

XWall checks inbound and/or outbound attachments for common exploits that may harm the recipient.

Block all exploits

If enabled, XWall checks for all exploits.

Block attachments with a dot at the end (file.jpg.)

If checked, XWall will block files with a dot at the end like file.jpg.

Block attachments with a double extension (file.exe.jpg)

If checked, XWall will block files with a double extension like file.exe.jpg

Block attachments with a CLSID extension

If checked, XWall will block files with an extension of .{????????-????-????-????-????????????}

Block password protected archive files

If checked XWall will block password protected archive files

Block partial attachment (message/partial)

If checked, XWall will block files partial MIME attachments.

Block external attachment (message/external-body)

If checked, XWall will block files where the attachment itself is not in the message.

Block Windows and DOS executables

If checked, XWall blocks files that can be executed in DOS or Windows executable.

XWall detects such files by checking for the signature and does not care about the extension. This means that even when the file sample.scr is renamed to sample.txt it will be blocked.

Block Windows and DOS executables in archive files

If checked XWall blocks DOS and Windows executable files even when they are in a archive file. XWall detects the archive file and the executable by it's signature and this means that renaming a archive or exe file doesn't help to bypass this check.

Action

List of Actions

Inbound, Outbound

XWall scans the normalized subject case sensitive for the specific string.

In a normalized subject

• all tabs are replaced with a single space
• multiply spaces are replaced with a single space
• a space is added at the beginning and at the end,
  which allows to scan for words by adding a leading and/or trailing space to the string

Keep in mind that XWall scan for strings and not words. To scan for words you need to add a space in front and at the end of the string. If the string is cum (without the spaces that make it a word), then you block the authors name which is Michael Kocum. Or if the string is sex then this would also block MSExchange.

Note: Wildcards are allowed.

Scan case sensitive

If checked, XWall scans the subject case sensitive

Add Common

Adds strings and words to the list that are commonly used in spam messages

Action

List of Actions

Inbound, Outbound

XWall scans the normalized text and html part of the message case sensitive for the specific string and HTML tags are removed from the html part of the message before the scan.

In a normalized text part of the message:

• all tabs are replaced with a single space
• multiply spaces are replaced with a single space
• a space is added at the beginning and at the end,
  which allows to scan for words by adding a leading and/or trailing space to the string

Note: Wildcards are allowed.

Scan case sensitive

If checked, XWall scans the subject case sensitive

Add Common

Adds strings and words to the list that are commonly used in spam messages

Exclude

Allows you to exclude a message from this test by e-mail address, IP address or host

Action

List of Actions

Inbound, Outbound

XWall scans the normalized html part of the message case sensitive for the specific string and HTML tags are not removed before the scan.

In a normalized html part of the message:

• all tabs are replaced with a single space
• multiply spaces are replaced with a single space
• a space is added at the beginning and at the end,
  which allows to scan for words by adding a leading and/or trailing space to the string

To block messages with embedded scripts you can scan for the string "script".

Note: Wildcards are allowed.

Scan case sensitive

If checked, XWall scans the subject case sensitive

Add Common

Adds html tags to the list that are commonly used in spam messages

Exclude

Allows you to exclude a message from this test by e-mail address, IP address or host

Action

List of Actions

Inbound

XWall scans the list of headers of the message for the header keyword and then scans the header's additional information for the search value.

XWall scans by ignoring the case and wildcard are not necessary.

Example: Assume you want block all messages sent by FoxMail, which is a very common spam mailer in China.

The header line in the message looks something like: X-Mailer: FoxMail 3.11 Release [cn]

To block this mailer, you would add: x-mailer:foxmail

Add Common

Adds string and words to the list that are commonly used in spam messages

Exclude

Allows you to exclude a message from this test by e-mail address, IP address or host

Action

List of Actions

Block messages from the following countries

XWall gets the country from the IP address of the sending host and compares it with the list of blocked countries.

Examine the IP addresses in the message header

If this is checked, XWall will scan the Received:lines of the header of the message for the IP address.

Reject the message during the SMTP session

If checked, XWall will reject the message during the SMTP session and the message will not be accepted.

Action

List of Actions

Block messages with the following charset

XWall compares the charset of the subject, the body text and the HTML text against the list.

Add common for Eastern Europe

Add common for Russia

Add common for China

Add common for Korea

Adds the charset commonly used in this country to the list.

Action

List of Actions

Inbound Messages directly sent by a specific IP address or hostname

Examine the IP addresses in the message header

If this is checked, XWall will scan the Received: lines of the header of the message for the IP address (but not the host name)

Reject the message during the SMTP session

If checked, XWall will reject the message during the SMTP session and the message will not be accepted.

Reject the connection attempt (reset TCP)

If checked, XWall reject the connection before any data is exchanged. Also XWall does not perform an reverse lookup of the IP address (PTR), so no host information is available.

Note: The sending server usually reschedules the message and retries after some time until the message timeout is expired. In general it takes less CPU to accept the connection and send back a 5xx error rather than to drop the connection without any notice.

Action

List of Actions

Inbound MAIL FROM:, Inbound RCPT TO:, Outbound MAIL FROM:, Outbound RCPT TO:

Allows you to block a message by an e-mail address.

The e-mail address is case insensitive compared from right to left until a match is found.

This allows you to block a whole domain by typing @domain.com and as a result, bit@domain.com blocks rabbit@domain.com

If you add a space at the beginning, XWall interprets this as a full address and so bit@domain.com does not block rabbit@domain.com

Reject the message during the SMTP session

If checked, XWall will reject the message during the SMTP session and the message will not be accepted.

Action

List of Actions

Block system messages (Delivery Status Notifications / Non-Delivery Reports)

A system message is a message with either a null return-path (MAIL FROM: <>) or a MIME multipart/report message.

This includes Non-Delivery Reports (NDR), Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN) and read receipts.

Block only for the following e-mail address

You can define for which recipients e-mail address the messages should be blocked.

If no e-mail address is defined, then all system messages are blocked.

Reject the message during the SMTP session

If checked, XWall will reject the message during the SMTP session and the message will not be accepted.

Note: RFC 1123 Section 5.2.9 and RFC 5321 Section 4.5.5 require that a mail server accepts system messages and rejecting them during the SMTP session is not permitted. Some mail server check for this and refuse to accept messages from a server that rejects system messages.

Action

List of Actions

Block Microsoft Office document with a Visual Basic for Applications (VBA) macro

XWall checks if there is a macro in an Microsoft Office document and if so, the file is blocked.

Block password-protected Microsoft Office document

XWall checks if there is password-protected Microsoft Office document and if so, the file is blocked.

Block Microsoft Office document with an extension mismatch

By default Microsoft Office applications are associated with a lot of extensions like .doc or .xls or .docx. However, the applications don't use the file extension to detect the file type. Merely they detect the file type by the scanning the content.

For example, a file named test.doc may have a RTF or a HTML content and WinWord will handle it without any problem.

This give an attacker an advantage, by sending a .doc file, but include a MIME message with an XLM content and encrypted and compressed clipboard data, which results that WinWord runs macro without that anyone can stop that.

XWall checks is the extension matches the file content and if not, the file is blocked.

Action

List of Actions

Block messages with a Bitcoin address in the text

XWall checks if there is a Bitcoin address in the message text.

A Bitcoin address has length of 34 bytes, is Base58 encoded and has a SHA256 check sum.

Action

List of Actions

XWall scans the display name of the From: address case insensitive for the specific string and thereby detect the CEO's and other impersonated names in the display name

Keep in mind that XWall scan for strings and not words. To scan for words you need to add a space in front and at the end of the string.

Note: Wildcards are allowed, but not recommended, because they may detect more than intended.

Wizard

Queries for first name and last name and creates a list of common permitations.

Action

List of Actions

Note: In order to allow the real CEO to pass, e.g. send messages from his private GMail account, exclude his private e-mail address.

Automatically block IP addresses that send spam messages

XWall counts the messages from the same IP address that have triggered an action by any other method or are rejected during the SMTP session. Once the count has reached the threshold, the action is triggered on the sending IP address for the given seconds.

Message threshold

Defines after how many spam messages an IP address will be blocked, The default is 3 messages.

Trigger action all messages from the sending IP within the next xx seconds

Define how many seconds XWall should block the IP address. The default is for 8 hours.

Max ip addresses to gather

Defines how many IP addresses XWall should keep

Reject the message during the SMTP session

If checked, XWall will reject the message during the SMTP session and the message will not be accepted.

Reject the connection attempt (reset TCP)

If checked, XWall reject the connection before any data is exchanged. Also XWall does not perform an reverse lookup of the IP address (PTR), so no host information is available.

Note: The sending server usually reschedules the message and retries after some time until the message timeout is expired. In general it takes less CPU to accept the connection and send back a 5xx error rather than to drop the connection without any notice.

Action

List of Actions

Reject the connection attempt from the following IP address or host (reset TCP)

If enabled, it will help against connection flooding by a botnet. Connection flooding happends when XWall gets hundrets or even thousands connections, most of them with invalid sender or recipient addresses.

Usualy the sendign machine is a home PC which is part of a botnet. XWall will reject the connection attempt, e.g. immedeatly close the connection, if the sending IP address or hostname matches one of the defined masks.

However, XWall will remember the IP address and of this IP address is connection a second time within the Greylisting timeframe, it will accept the connection. The reason is that else a legal mails erver which matches the mask will never be able to send any mail.

IP Address and Hostname

Defines a mask/wildcard that XWall should reject.

Add common

Adds some common masks/wildcards to the list.

Reject IP address with a missing PTR

If checked, XWall will also reject connections from IP address that have no PTR (no reverse lookup)

Verify the sender and reject the message during the SMTP session

Verify the senders domain and do not accept invalid domains

If checked, XWall verifies the senders domain and does not accept the message when an invalid domain is detected. To pass this test a MX or A record for the domain must exist.

Note: If there is no name server defined in XWall, XWall will not validate the domain.

Also make sure that your firewall does not block port 53 tcp and udp or else XWall will not be able to connect to the authoritative name server for the domain that should be checked.

Verify the senders reverse lookup of the IP address

If checked, XWall verifies the reverse lookup of the IP address. To pass this test a PTR record for the IP address must exist.

Verify the senders FQDN (full qualified domain name) in the HELO/EHLO command (must resolve to an A record to pass the test)

If checked, XWall verifies the FQDN (full qualified domain name) in the HELO/EHLO command. To pass this test the FQDN needs to resolve to an A record.

Verify the sender e-mail address using a call back

XWall connects to the senders MTA and tries to send a message to the e-mail address, using a NULL sender. If the MTA accepts the message, then the test is passed.

Verify the recipient and reject the message during the SMTP session

Verify the recipients e-mail address using a static address list

If checked XWall verifies that the recipient of the message is in the address list. You must either manually add the e-mail addresses to the address list or use ExchImp or LDAPImp to import the e-mail addresses from the Global Address List (GAL) or AD into the address list.

Note: You need to update the address list in XWall every time you add or delete a e-mail address on your Exchange server.

Verify the recipients e-mail address dynamically using a SMTP query to Exchange

If enabled, XWall connects to Exchange and tries to send a message to the recioient. If Exchange accepts the recipient, the recipient is valid.

Verify the recipients e-mail address dynamically using an external program

XWall calls the external program to verify the e-mail address. If the program returns an errorlevel of 0 (zero), then XWall assumes the e-mail address is valid. If the errorlevel is 2, XWall assumes the e-mail is not valid. For every other errorlevel XWall assumes the program had an problem getting the information.

Program

The default program, LDAPQuery.vbs queries the Active Directory for the e-mail address.

For communication with Active Directory, the script uses LDAP on port 3268 tcp.

Parameters

The default parameter for the program is <EMAIL>. <EMAIL>acts as a placeholder and XWall will replace it with the real e-mail address at runtime.

Log detailed description how the program is executed

If checked XWall shows how the program is executed and what return code (errorlevel) the process returns

Verify the program by querying an existing e-mail address

If an e-mail address is given, XWall will call the program with that e-mail address at startup. If should-exist e-mail address does not exist, then XWall will disable the whole recipients checking, and will accept mail for any recipient in the domain.

This is to safeguard against a program that does not work or else it would block all your incoming messages.

Cache the result of the program

If checked, XWall caches the result of the program for 8 hours

Using LDAPQuery.vbs

LDAPQuery.vbs queries the AD/GC server for a given e-mail address and shows the CN and all the proxy addresses for that CN. When you run LDAPQuery.vbs on a machine that is not part of your domain (DMZ), then you need to specify the GC server (Global Catalog server) as a second parameter.

Usage is:

cscript LDAPQuery.vbs e-mail [GCserver|defaultNamingContext] [-uUser] [-pPassword] [-notesdomino]

cscript LDAPQuery.vbs e-mail
[GCserver|defaultNamingContext]
[-uUser]
[-pPassword]
[-notesdomino]

To test LDAPQuery.vbs open a DOS box on the XWall machine and run it with a known e-mail address and optionally a gc server.

Note: In the case you have Lotus Notes Domino, you can use the -notesdomino switch so that the script uses the correct query for Notes

Allows you to block all messages that are not excluded

Action

List of Actions

Lookup the IP address of the connecting host or the message header in the Spam Lookup Service (SLS/RBL/DNSBL)

IP address based Spam Lookup Services

XWall checks if the IP address of the sending host and/or all IP addresses in the header of the messages is on one of the real time spammer lists.

You can create a group of services by separating the services with a comma. In a group the IP address must be on each list to trigger the action.

The following IP addresses are excluded from the check: 127.0.0.1, 10.x.x.x, 192.168.x.x, 172.16.x.x, 224.x.x.x and the IP addresses of the same subnet as the machine where MBServer is currently running

Add Common

Adds some common free-of-charge services.

Domain based Spam Lookup Services

XWall checks if the e-mail domain of the sender (the MAIL FROM: e-mail domain) is on one of the real time spammer lists. A sample is dbl.spamhaus.org.

Examine the IP addresses in the message header

If this is checked, XWall will scan the Received: lines of the header of the message for the IP address and check that IP address against the SLS/RBL.

Reject the message during the SMTP session

If checked, XWall will reject the message during the SMTP session and the message will not be accepted.

Action

List of Actions

Greylisting spam filter, based on http://www.greylisting.org

The Greylisting method looks at three pieces of information about any particular mail delivery attempt:

• the IP address of the host attempting the delivery
• the envelope sender address
• the envelope recipient address

From this an unique triplet for identifying a message is created and if this triplet was never been seen before, or the sender is not excluded or on the white list, then the message delivery is refused with a temporary failure.

Any normal SMTP server will reschedule the message and will resend it after some time (usually 10 - 15 minutes).

Spammers however are sending applications designed specifically for spamming. These applications usually adopt the fire-and-forget methodology. That is, they attempt to send the spam to one or several MX hosts for a domain, but then never attempt a true retry as a real SMTP server would.

If a sending host is found to actually resubmit a mail after a temporary rejection, there's no point in ever using Greylisting with that host again. XWall excludes the host, because the host is queues mail properly and isn't a fire-and-forget spammer. It may be a spammer or an open relay, but Greylisting isn't going to help you deal with it.

Note: Make sure your backup MX SMTP also runs XWall or any other SMTP server that support Greylisting or else the spammer will bypass XWall by sending to XWall first and then to the backup MX. If your backup MX does not support Greylisting, then you can use our MTA Backup Service

Max triplets to gather

Defines how many triplets XWall should remember

Initial delay of a previously unknown triplet

Lifetime of triplets that have allowed mail to pass

Lifetime of triplets that have not yet allowed a mail to pass

Defines the time interval of the triplets

Accept all IP addresses from a Class C net

If checked, XWall ignores the rightmost part of the IP address (10.0.0.x) when creating the triplet. This treats all servers in a Class C net the same and prevents infinite blocking when the sender uses a server farm where each connection is coming from a different IP address.

Log detailed triplet description (last seen, time elapsed)

If this is enabled XWall shows a detailed description about the status of the triplet, including the last seen and elapsed time.

Enable Central Checksum Service (CCS) to detect bulk e-mail

The Central Checksum Service (CCS) is designed to detect bulk e-mail on a worldwide level.

To do this, XWall calculates a checksum of every incoming message and reports it to the CCS server. The CCS server cumulates incoming reports and responds how many message with the same checksum were circulating in the past few hours.

Depending on the threshold you selected, XWall decides whether to classify an e-mail as bulk e-mail or not.

XWall communicates with the CCS server using port 53 udp or port 12178 udp. If you have a Cisco PIX, you need to make sure port 12178 is open.

Additional Info: Live statistic of the CCS server

Threshold

Defines above which level XWall should trigger the action

Log detailed triplet description (last seen, time elapsed)

If this is enabled XWall shows a detailed description how the CCS valued a checksum.

Action

List of Actions

Note: The Central Checksum Service (CCS) is an add-on to XWall and requires a yearly subscription.

You may request a free 6 month subscription

Bayesian spam filter, based on Paul Graham's paper A Plan For Spam

Enable gathering of statistical data for the Bayesian filter (Learn Mode)

In Learn Mode XWall gathers statistical data about the frequency of the words that appear in the subject, the body text and the html text of the message.

Based on other spam checking functions (SLS/RBL/MAPS, blocked strings, blocked or excluded addresses) the words are stored in a good-word list and a bad-word list.

Max words to gather

Defines how large the good-word list and the bad-word list should become. Note: More words takes up more memory and CPU

Limit gathering to the first KB

Defines how many KB of the subject , the text and the HTML part of the message should be scanned.

Note: More KB take up more CPU. If you have not that many messages (below 500 per hour), then you can set this value higher.

Ignore common words when gathering

If enabled XWall ignores common word when calculation the Bayes value. This results in a more aggressive calculation.

Classify spam spam by sending mail to this e-mail address

Classify good spam by sending mail to this e-mail address

Defines an e-mail address that is NOT in your domain and that is used for manually classification of spam messages.

If you are not sure what e-mail address you should use, then use spam@bayes.spam and nospam@bayes.spam

To manually classify a spam message forward it to spam@bayes.spam

To manually classify a good message forward it to nospam@bayes.spam

Exchange will forward the message to XWall (because the address is not local) and XWall will then capture the message, feed Bayes with it and then discard the message.

Note: Make sure that your outgoing mail goes through XWall or XWall will not be able to get the message and you will get back a non-deliver report from Exchange.

Also make sure you remove your own signature and header lines when you forward a message using Outlook or else your own signature goes into the bad word list.

Enable a statistical approach with the Bayesian filter to filter out spam mails using

Paul Grahams's original method

Gary Robinson's alternative method

The classification algorithm is based on Bayes formula and is comparing the frequencies of words in the message with those found in the good-word list and a bad-word list and calculates the spam value of a message.

Assume spam when the value is more than xx

If the spam value is more than 90 (Paul Graham's method) or more than 60 (Gary Robinson's method) the selected action will be triggered.

The main difference between the two methods is that Paul Graham's method tend to generate values that a very low (somewhere around zero) or very high (90 an above), but nothing in the middle. So it is hard to adjust the value where a message should be considered as spam.

Gary Robinson's alternative method generates more flat numbers from zero to 100 and you will see a lot of messages with a spam value of 37 or 54 or something like that.

Note: It takes at least 1000 learned e-mails unless the classification algorithm starts working

Action

List of Actions

Enable a heuristic approach to filter out spam mails

The classification algorithm is based on rules that use a wide range of heuristic tests on mail headers and body text to identify spam messages.

Each rule has a weight and the sum of all rules it the total spam value of a message.

Log detailed description which rule was triggered

If this is enabled XWall shows a detailed description which heuristic rule was triggered

Assume spam when the value is equal or more than x

A value of 30 or less results in an aggressive spam blocking, a value of 70 or more is a relaxed spam blocking.

Action

List of Actions

Block messages where the SPF results in a FAIL

Block messages where the SPF results in a SOFTFAIL

Block messages where the SPF results in a NEUTRAL

SPF works by domains publishing reverse MX records to tell the world what machines send mail from the domain. When receiving a message from a domain, those records are checked to make sure mail is coming from where it should be coming from. This prevents from spammer that use a valid e-mail domain as the From: address but relay through a completely different mail server.

For example, AOL uses SPF to publish the IP addresses of its e-mail servers. When the message from AOL comes in, the IP address is checked against the published IP addresses and if the IP address is not one of the published, then the SPF results in a FAIL.

More information about the SPF project at www.openspf.org and www.getmailbird.com

Examine the IP addresses in the message header

If checked XWall will examine the IP addresses in the message header against SPF.

If unchecked only the IP address of the sending server is checked.

Use a default TXT record when the domain does not publish it's own TXT record

A lot of domains do no publish their TXT records.

To overcome XWall can use a default TXT record for such domains.

The default TXT record is: v=spf1 ptr a mx -all

This means that SPF results in a PASS when one of the following is true:

The host name of the sending server is from the same domain as the sender

The IP address of the sending server is one of the A records of the senders domain

The IP address of the sending server is one of the MX records of the senders domain

Reject the message during the SMTP session

If checked, XWall will reject the message during the SMTP session and the message will not be accepted.

Action

List of Actions

Enable Spam URI Realtime Blocklists - SURBL -http://www.surbl.org

SURBL is an SLS/RBL that lists domains found in the HTML part of the message, usually meaning the domains of spam-advertised web sites.

The randomized subdomain problem is solved by extracting the base domain on both the SURBL data and message-checking client sides then comparing those base domains. In this way any random stuff added to the base domain is ignored. (The base domain is what would be registered with a name registrar.)

Expand shortened URLs

If this is enabled, XWall expands shortened URLs before performing the SURBL query. e.g. http://goo.gl/u6U1n0 is expanded to http://expandurl.me

Note: The URL is expanded using a HTTP connection, so port 80 and 443 must be open.

Log detailed description about the URL in the message

If this is enabled XWall shows a detailed description which URL was found in the message

Action

List of Actions

Enable Google Safe Browsing - https://safebrowsing.google.com

Check URLs in the message against Google's constantly updated lists of unsafe web resources.

Note: Query Google Safe Browsing list requieres a HTTP connection, so port 80 and 443 must be open.

Api Key

Using Google Safe Browsing list requires an API Key as a kind of authentication.
You get the API Key at https://developers.google.com/maps/documentation/javascript/get-api-key

Once you got the API Key, you must activate the API Key for Google Safe Browsing API.

Note: When XWall shows a 403 rather than an 200 response in the logfile, then the API Key is invalid or not activated or the quota is exceeded.

Expand shortened URLs

If this is enabled, XWall expands shortened URLs before performing the SURBL query. e.g. http://goo.gl/u6U1n0 is expanded to http://expandurl.me

Log detailed description about the URL in the message

If this is enabled XWall shows a detailed description which URL was found in the message

Action

List of Actions

Enable Sublime Security E-Mail Reputation - https://emailrep.io

Check senders e-mail in the message using Sublime Security E-Mail Reputation.

Note: Query Google Safe Browsing list requieres a HTTPS connection, so 443 must be open.

Api Key

Using Sublime Security E-Mail Reputation requires an API Key as a kind of authentication.
You get the API Key at https://emailrep.io/key

Note: When XWall shows a 403 rather than an 200 response in the logfile, then the API Key is invalid or not activated or the quota is exceeded.

Log detailed description about the reputation

If this is enabled XWall shows a detailed description about the reputation of the e-mail

Action

List of Actions

Enable Senderbase to detect message volume spikes - http://www.senderbase.org

Senderbase collects data for a large amount of the world e-mail traffic Based on this data Senderbase calculates a daily and a monthly magnitude for every IP address and domain.

If the daily magnitude is much larger then the monthly magnitude, then the IP address or domain is sending more then on average. Usually such a spike happens because the IP address or domain sends out spam, but a virus outbreak is also possible or even a newsletter.

Log detailed description which rule detected the spike

If this is enabled XWall shows a detailed description which rule was used to detect the message volume spike

Action

List of Actions

Detect Backscatter

Backscatter occurs when a spammer uses your e-mail address to send out spam or a virus. For all the messages that can't be delivered, you get back a non-delivery report. Based on the initial message volume you may get back thousands of non-delivery reports.

XWall checks the Received: header lines of the original message and compares the IP address with the IP address of the XWall machine, the SPF record and the IP address of the backup MX and if not match is found, then the system messages is faked.

Action

List of Actions

Detect Phishing in HTML messages

Phishing means that the sender is either impersonating a domain that you trust (e.g. paypal.com or eBay.com) or they want to redirect your browser to a web site that is different from the site that you may think the browser goes to (used mostly with bank accounts).

Note: Phishing does not honor the white list or the global exclusions, because the exclusions usually contains trustworthy senders and due that they are impersonated, the exclusions would open a security whole.

XWall checks the message for

a link in the message appears to belong to one page, but the underlying URL points to a different page

e.g. http://www.citibank.com/logon.asp vs. http://www.badsite.com/bad.php

Ignore when the base domain matches

http://www.site.com/logon.asp is equal to http://any.site.com/logon.asp

This prevents from false positive when the URL points to a differetn server on the same domain, e.g. http://www.adobe.com vs. http://download.adobe.com

detect masquerading as a trustworthy sender using SPF

XWall check the SPF record of the sender and if SPF returns either FAIL, SOFTFAIL or NEUTRAL, the message is Phishing.

Note: This SPF has nothing to do with the SPF settings at Options->Spam->SPF

detect masquerading as a trustworthy sender using DKIM

XWall check the DKIM of the sender and if DKIM returns PERMFAIL, the message is Phishing.

detect masquerading as a trustworthy sender using DMARC

XWall get the DMARC policy of the sender using a DNS query. If a DMARC policy exists, XWall checks DKIM and SPF against the policy and if the policy is violated, the the message is Phishing.

Log detailed description about the URL in the message and the SPF result

If this is enabled XWall shows a detailed description which URL was found in the message and how SPF was performed

Action

List of Actions

Inbound Messages

Check if the message uses BCC (Blind Carbon Copy) addressing

A BCC message is a message where the recipients address is not in the To: or CC: field.

Most SPAM messages are addressed using BCC and this is a way to mark this kind of messages.

Check if the message has a faked From: address

A From: is faked when the e-mail address in the From: line of the messages does not match the e-mail address of the message envelope (the MAIL FROM: e-mail address of the SMTP transfer)

Also if the From: address of the message is the same as the recipients address, then the From: address is faked.

Check if the message has an internal From: address

An internal From: is when the sender uses an e-mail domain that is used on your Exchange server.

Note: By default this method does not honor the white list and the global exclusions. This means you need to exclude the following:

POP3 Clients

If you have external POP3 clients that use SMTP authentication, you need to make sure that Options->Global Exclude->Other->Exclude messages received from an authenticated user is enabled.

For POP3 clients that don't use SMTP authentication you need to exclude the IP address or the e-mail address in Options->Spam->Envelope->Check if the message has an internal From: address->Exclude

ESATInformer

You need to exclude the e-mail address that ESATInformer uses to send the report and messages to the users in Options->Spam->Envelope->Check if the message has an internal From: address->Exclude->MAIL FROM e-mail address

Web Mailer

If you have an web mailer or any other application that sends messages to your users and uses an e-mail address of your domain, you need to exclude the IP address or the e-mail address in Options->Spam->Envelope->Check if the message has an internal From: address->Exclude

Blackberry user

If you have Blackberry users that send using their company e-mail address, then you need to exclude the Blackberry host. A sample of the Blackberry host is smtp15.bis.na.blackberry.com.

This means that you need to exclude .blackberry.com in Options->Spam->Envelope->Check if the message has an internal From: address->Exclude->Host

Check if the message is coming from a faked MX

A MX is faked when the hostname of the sending host is not the one of the sending domain or the IP address of the sending host is not in the MX records for that domain.

However, there is no RFC that requires that a message is sent by a specific host and so this testing is testing something common, but not something that is required.

Action

List of Actions

Enable Forward Confirmed reverse DNS (FCrDNS)

Verify that the senders IP address has both forward (name-to-address) and reverse (address-to-name) DNS entries that match each other.

This is the standard configuration expected by the Internet standards. RFC 1912 and RFC 1033 recommend it as a best practice, but it is not a requirement of standard defining RFCs governing operation of the DNS.

Reject the message during the SMTP session

If checked, XWall will reject the message during the SMTP session and the message will not be accepted.

Action

List of Actions

Enable detection of a mailing list or a newsletter

Detect a mailing list or newsletter by checking the One-Click unsubscribe functionality or other mail headers.

Action

List of Actions

Image spam

An image spam message is a message where the spam is in an attachment, usually an image, a PDF or an archive.

Detect empty HTML message with a picture

The message must be a HTML message with at least one picture, no text and no other attachment.

The first wave of image spam messages are built using only a picture and no text at all.

Detect HTML message with a picture

The message must be a HTML message with at least one picture, any text, no other attachment and no URL.

The second wave of image spam has still the picture, but some text is added to the message.

Usually the text is English prose or nonsense text.

Note: Enabling this will block basically any HTML message with a picture, even when the picture is a logo like it is used on top of many messages or inside a signature.

Detect message with a picture

The message must have one picture of with at least the given size in pixels, no text, no HTML and no other attachment

Note: Enabling this will block basically any empty message with a picture.

Detect empty message with a PDF

The message must have no text with one PDF attached and the subject is either blank or has the filename in it.

Detect empty message with a RAR-ZIP

The message must have no text with one RAR file that is renamed to ZIP or a ZIP and the subject is either blank or has the filename in it.

Action

List of Actions

Inbound SMTP Session

Enable greeting delay

Protects against open proxies and SMTP slammers which send SMTP traffic without waiting for the SMTP greeting.

If enabled, XWall waits the amount of seconds before sending the initial 220 SMTP greeting.

If any traffic is received before then, a 554 SMTP response is sent and the session is closed.

Most spam software doesn't wait long for the greeting, but any real MTA will wait up to 5 minutes. A delay of 90 seconds seams to stop all spam software.

XWall doesn't delay all global excluded ip addresses and host names. Also XWall caches all valid IP addresses so that there is no delay on the second attempt of a real MTA.

Note: If you set this value above 10 seconds, AOL.COM will permanently fail any inbound traffic to your domain because it exceeds their timeout value. So exclude AOL.COM from greeting delay.

Note: If you have a Linux or BSD based firewall, then please read KBXW061.

Enable tar pitting / honey pot / teergrube to protect against a directory harvest attack

A directory harvest attack is an attempt to determine the valid e-mail addresses associated with an e-mail server so that they can be added to a spam database.

Tar pitting / honey pot / teergrube is the practice of deliberately inserting a delay into certain SMTP communications. By slowing an SMTP conversation, you can dramatically reduce the rate at which a dictionary attack can be conducted.

Enable an external program

XWall calls the external program or script and if the program returns an error level greater than zero, then XWall triggers the selected action.

A sample script (UDM.vbs,UDM.ps1) is included in Approve-Toolkit.zip, which you may download separately.

Program

The name of the program or script that XWall should run.

Note: It is up to the external program to do anything useful with the message.

Parameters

The parameters (arguments) that XWall should pass to the program.

There are two placeholders for built-in data.:

If <DATAFILE> is specified, then this placeholder will be expanded to a full file name which hold the decoded message parts. For a description of the parts and how to access them see the sample UDM.vbs/UDM.ps1 script.

If <RAWMSG> is specified, then this placeholder will be expanded to the full file name of the raw message and it is up to the program to decode the message.

Log detailed description how the program is executed

If checked XWall shows how the program is executed and what return code (error level) the process returns.

Program needs to be serialized

If checked XWall will only start one instance of the program, other messages are queued up until the program finishes.

Action

List of Actions

Approve the method and action using an external program

XWall passes the message data and the status of all methods to the program for approval. The program can either approve the status or it can return a different method and/or action and XWall will continue using this information.

A sample script (ApproveAction.vbs/ApproveAction.ps1) is included in Approve-Toolkit.zip, which you may download separately.

Run the external program only when spam was detected

If checked, XWall runs the program only when at least one method and action is detect.

If unchecked, XWall runs the program for all messages.

Log detailed description how the program is executed

If checked XWall shows how the program is executed and what return code (error level) the process returns.

Program needs to be serialized

If checked XWall will only start one instance of the program, other messages are queued up until the program finishes.

Enable SaneSecurity rules - http://www.sanesecurity.com

SaneSecurity provides rules for ClamAV virus scanner against the following e-mail types: Phishing, Spear phishing, Fake lottery, Ecard malware, Casino, Fake jobs, Fake loans, 419s, Fake Diplomas, porn and malware

Action

List of Actions

See also SaneSecurity Quick Start

Enable SecuriteInfo rules - http://www.securiteinfo.com

SecuriteInfo provides rules for ClamAV virus scanner against the following e-mail types: Malware and merketing spam

Action

List of Actions

See also SecuriteInfo Quick Start

Enable Community rules

The community provides rules for ClamAV virus scanner against the following e-mail types: Malware and merketing spam

Note: Community rules are all rules that are not from the ClamAV Virus Database (CVD), from SaneSecurity or from SecuriteInfo.

Action

List of Actions

Enable Office Macro OLE2 rules

ClamAV detects Microsoft Office OLE2 files with Visual Basic for Applications (VBA) macros using heuristics.

Note: OLE2BlockMacros yes must be in clamd.conf.

Action

List of Actions

Inbound Messages, Outbound Messages

Remove HTML formatting from the message

If checked, XWall removes the HTML formatting from the message.

Some viruses use HTML to automatically start programs or download files and so HTML messages are more dangerous than plain text messages.

Remove TNEF formatting from the message

If checked, XWall removes the TNEF formatting from the message.

This is useful if your mail client are not Microsoft programs, because then they can not handle TNEF formatted messages and always get some kind of unknown attachment.

Note: TNEF is sometimes called RTF formatting or WINMAIL.DAT

Remove DKIM signature from the message

If checked, XWall removes the DomainKey and DKIM signature formatting from the message.

When XWall adds a header line or tags the subject, the DomainKey/DKIM signature is no longer valid. So it is a good idea to remove the signature before sendign the message to Exchange.

Remove S/MIME signature from the message

If checked, XWall removes the S/MIME signature formatting from the message.

If XWall detects a S/MIME signature, it will not touch the message, because this would break the signature. Removing the signature allow XWall to handle the message as any other message.

Reassemble message

(removes invisible attachments and MIME and e-mail address exploits)

If checked, XWall decodes and then encodes the messages. This prevents from invisible attachments sent by some viruses, MIME exploits and e-mail address exploits.

Often viruses and other destructive programs use malformed messages to bypass security restrictions, simply because they are invisible to the decoder of the program that checks for the restriction.

For example Outlook Express use a very liberal decoding and so it decodes nearly every attachment. Exchange on the other side is more restrictive in decoding and may not see the attachment. So it can happen that Exchange does not see an attachment, but Outlook Express later on finds it.

Remove all characters from the subject that prevent OWA / IIS from opening the message (& % \\ ./ ..)

OWA can't open messages with some special characters in the subject, because IIS blocks such the URL.

If checked, XWall removes this characters from the subject so that the message can be opened in OWA.

Inbound Messages

Remove request for a read-receipt (Return-Receipt-To:)

If checked, XWall removes the Return-Receipt-To: line from the message.

Return-Receipts are also known as Read-Receipt or Delivery-Receipts and are generated by the Exchange server or the client when a messages is read or delivered and the sender of the message has requested it.

Remove request for a delivery-receipt (DSN SUCCESS)

If checked, XWall clears the DSN SUCCESS flag at the SMTP protocol level.

The DSN SUCCESS is also known as Delivery-Receipts and are generated by the Exchange server or the client when a messages is delivered and the sender of the message has requested it.

Remove request for a read-receipt (Return-Receipt-To:)

If checked, XWall removes the Return-Receipt-To: line from the message.

Return-Receipts are also known as Read-Receipt or Delivery-Receipts and are generated by the Exchange server or the client when a messages is read or delivered and the sender of the message has requested it.

Remove request for a delivery-receipt (DSN SUCCESS)

If checked, XWall clears the DSN SUCCESS flag at the SMTP protocol level.

The DSN SUCCESS is also known as Delivery-Receipts and are generated by the Exchange server or the client when a messages is delivered and the sender of the message has requested it.

Suspicious message

A suspicious is usually a message loop which happens when one of your users forward his/her mailbox to an Internet address and this address has a problem, like the mailbox is full or the e-mail is invalid.

In this case the recipients server sends back a non-delivery-message, which will then forwarded to the e-mail address and the message will be looping between the two server until one one the server crashes.

To prevent this XWall monitors the e-mail traffic and if a given threshold is reached, XWall send an status message to postmaster.

Observe last xx minute

Defines the time frame which XWall monitors

Alert when more then xx messages

Defines after how many messages in the time frame a status message is sent

Exclude e-mail address

Allows to exclude some e-mail addresses from monitoring

BCC non-delivery reports to e-mail address

Sends a copy of every non-deliver report to the given e-mail address.

If you have a virus scanner defined in XWall, then XWall will pass every non-delivery message to the scanner for verification. If the scanner finds a virus, then the virus action is triggered and the attachments of the message are removed.

Note: In the case you have no virus scanner in XWall defined, then select View->Advanced Configuration->DNS and set the Return content of the original message to Include only the header of the message into the DNS or else XWall may forward a virus to your Exchange.

BCC forward report to e-mail address

Sends a copy of every forwarded report to the given e-mail address.

Forwarded reports are the reports that are sent to the recipient when a blocked attachment or text is forwarded to the user or administrator.

BCC all inbound messages to e-mail address

BCC all outbound messages to e-mail address

Sends a copy of every message to the given e-mail address

Enable on-demand virus scan on inbound messages, Enable on-demand virus scan on outbound messages

If checked, XWall scans the message using an on-demand scanner or command line scanner.

XWall extracts all attachments of the message into the TEMP directory and then starts the scanner. The scanner scans each file and returns an error level in the case a virus is found. XWall checks the return code of the scanner (error level) and if the return code is anything other than zero, XWall assumes that there is a virus in the file and triggers the selected action.

On-Demand Virus Scanner

Virus Scanner

Select one of the predefined scanners

Executable

Full path to the executable that XWall should start. If your scanner is not on a local disk, make sure you are using a UNC name before you select the .exe file for the scanner.

Argument

The arguments / parameters that the scanner requires

Currently there are some scanners known to work with XWall:

• McAfee VirusScan Command line version 6.x
• ClamAV Virus Scanner
• Grisoft AVG AntiVirus 7.0
• Trend Micro TrendMicro VSCANTM Ver 1.0
• NOD32 v2.70
• Kaspersky v6.0
• F-Prot for Windows Corporate 6.0.9.1

Besides the supported scanners, you can use nearly any scanner that can be started from the command line. XWall calls the scanner with the arguments you specify and the current filename.

As an example, here is the input you need to use for McAfee Scan:

Executable: C:\McAfee\Scan.exe
Arguments: <FILE> /ALL /NOBEEP

XWall translates <FILE> to the current filename and then starts the scanner. This looks like:

C:\McAfee\Scan.exe
C:\TEMP\$TE22234
/ALL /NOBEEP

C:\McAfee\Scan.exe C:\TEMP\$TE22235 /ALL /NOBEEP

You need to make sure that your scanner scans all files for all viruses including files with no extensions. XWall passes over filenames with no extension and scanners that do their virus scanning based on a file's extension will also fail to locate some viruses.

After the scanner returns, XWall checks the errorlevel. If the errorlevel is anything except 0 (zero), XWall will consider the file to be infected with a virus and will trigger the selected action.

Triggering the action on a different errorlevel :

If XWall should trigger the action on a different errorlevel then you can do this by adding the line

to XWall. ini. You need to put a small x for every errorlevel where XWall should trigger the action and a large X for every error level XWall should ignore.

Note: The string is zero bound, which means the first x is error level 0.

For example if XWall should ignore errorlevel 2 then the string looks like

Further info:

• Using McAfee Virusscanner
• Install ClamAV Antivirus Native Win32
• Using other virus scanners like Symantec / Norton, Trend Micro and others
• How to get the name of the virus into the non-delivery report

Enable on-access virus scan on inbound messages, Enable on-access virus scan on outbound messages

If checked, XWall scans the message using an on-access scanner.

An on-access scanner is a scanner that scans a file as soon as it is written to disk.

Directory

XWall copies all attachments of the message into this directory. The scanner detects the new files and scans them. XWall waits some time to see if the scanner removes or renames one of the files, indicating that a virus was found. And if this happens, XWall triggers the selected action.

Note: The scanner must scan only files in this directory, the XWall directory and the TEMP directory must be excluded from scanning.

Enable native ClamAV virus scan on inbound messages, Enable native ClamAV virus scan on outbound messages

If checked, XWall scans the message using a TCP connection to the ClamAV service (clamd).

ClamAV Virus Scanner

Name or IP address

Host name or IP address of the ClamAV service. The default is localhost, which means that the ClamAV service is on the same machine as XWall.

Port

The port where the ClamAV service is listening. The default is port 3310

Scanner supports EML message format

If checked, XWall lets the scanner scan the raw messages as it was sent over the wire

Scanner supports archive files

If not checked, XWall extracts the files from a archive file and let the scanner scan them individually

Scanner needs to be serialized

If checked XWall will only start one instance of the scanner, other messages are queued up until the scanner has finished

Enable diagnostic logging

Shows what process XWall starts and what return code (error level) the process returns

Scan messages even when they are blocked

If checked XWall will also scan the message even the message is already blocked by other methods.

So if you block .exe and there is virus in an .exe XWall will not scan the message unless the action of the message results that the message is sent to your Exchange

Add the extension of the original attachment to the temporary file name

By default, XWall doesn't add an extension to the temporary file name. This forces the scanner to scan for all viruses and not only for the one that matches the extension.

However, some new scanner do no longer support this and so you can tell XWall to add the extension of the original attachment to the temporary files. The scanner then knows the extension and is able to scan the file.

Action

List of Actions

Note: XWall does not have the option to clean attachments. The scanner vendors claim that they can decontaminate a file, but in fact they often fail; which results in a contaminated file with an undetectable virus. Melissa was a great example where users sent out "cleaned files" which infected other recipients because the file was still contaminated but undetectable to the recipient's virus scanner.

Allows you to define a company wide disclaimer that will be added to every outbound message.

In the following cases no disclaimer is added

• signed messages
• crypted messages
• non-deliver messages (DSN)
• the TNEF part of a message

See also Outbound Disclaimer in XWall

Enable TLS/SSL for inbound connections

If checked, XWall announces TLS/SSL so that a connecting client can establish a TLS/SSL connection and thereby encrypt the data that is sent over the wire. By default this is disabled, because a valid certificate for the host is required or else the sending host can not verify your machine.

Server certificate file

The file that holds the certificate, in PEM format

Server private key file

The file that holds the privat key of the certificate, in PEM format

In most cases both the certificate and the private key are in one file and the name of the file is certt.pem

Note:Type in the filename and not the full path name (e.g. cert.pem and not c:\XWall\cart.pem)

Enable TLS/SSL for outbound messages

If checked, XWall uses TLS/SSL and encrypts the data sent over the wire.

Certificate authority certificate file

The name of the file with the certificate authority certificates, in PEM format

XWall uses this list of authority certificates to validate the target server.

However, XWall will always try to establish a TLS/SSL connection, even when the certificate or the CN name can not be verified.

TLS/SSL Toolkit:

You will find a generic certificate in the TLS/SSL Toolkit that you may use for a quick start.

Download TLS/SSL Toolkit and extract tlscert.pem and cacert.pem into the XWall directory.

Set the fields as follows:

Note: If you have your own certificate in Windows 2000/2003/2008 then you can export it and use PKCS12_to_PEM.bat from the TLS/SSL Toolkit to convert it into PEM format which XWall is able to read.

See also TLS/SSL Quick Installation

Verifies outbound TLS/SSL connections based on the following rules.

Each rule consists of a From e-mail address, a To e-mail address, a optional string in the subject and a type.

Note: Wildcards are allowed.

Examples:

Use mandatory TLS on all outbound messages from your domain to @secure.com

Use opportunistic TLS for all not covered by a rule

Don't use TLS with freefax.com

Reject the message during the SMTP session on

XWall terminates the connection if any checked condition is not fulfilled.

certificate not trusted

Either the certificate is verified using a chain of trust. The trust anchor for the digital certificate is the Root Certificate Authority (CA). Or the certificate is verified using DANE (DNS-based Authentication of Named Entities).

Note: Trusting a well know CA (Certificate Authority) that must follow the US PATRIOT Act (e.g. Verisign or Thawte) is not a feature.

self-signed certificate

Note: Trusting a self-signed certificate together with a fingerprint is secure.

expired certificate

An expired certificate means that the certification authority is no longer reporting on the integrity of the certificate. But for a self-signed certificate or trust by DANE, the exipiration date is not an issue.

revoked certificate

XWall obtains the revocation status of the certificate using CRL (certificate revocation list) or OCSP (Online Certificate Status Protocol)

CN mismatch

FQDN (fully qualified domain name) doesn't match the CN (Common Name) or SAN (Subject Alternative Name) in the certificate.

fingerprint with TOFU (Trust On First Use) mismatch

A fingerprint is a hash of the public key, usually SHA1. TOFU (Trust On First Use) is a security model whereby XWall, upon connecting to a new server, stores the fingerprint. From then on XWall uses the fingerprint to identify the server.

Note: Verify the fingerprint of a certificate prevents against man-in-the-middle attacks and using TOFU (Trust On First Use) mimizes administration.

weak key (less than 2048 bit)

Industry standards set by CA/B (Certification Authority/Browser) and NIST (National Institute of Standards and Technology) requires that certificates issued after January 1, 2014 must be at least 2048-bit key length.

Because as computer power increases, anything less than 2048-bit is at risk of being compromised by hackers or any agency with sophisticated processing capabilities.

weak cipher

Basically AES with 128 bit and all algorithms with 256 bits are strong ciphers, everything else is weak.

Note: A strong key and a strong cipher makes it harder, if not impossible, for the NSA (National Security Agency) to crack the communication.

missing PFS (Perfect Forward Secrecy) using Diffie-Hellman Key Exchange

PFS (Perfect Forward Secrecy) is a defense against an attacker who records encrypted conversations where the session keys are only encrypted with the communicating parties long-term keys. Should the attacker be able to obtain these long-term keys at some point later in the future, he will be able to decrypt the session keys and thus the entire conversation.

Diffie-Hellman Key Exchange is a specific method of exchanging cryptographic keys. The Diffie-Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher like AES.

Diffie-Hellman is used in SSL/TLS, as ephemeral Diffie-Hellman, the cipher suites with DHE in their name. What is very rarely encountered is static Diffie-Hellman, cipher suites with DH in their name, but neither DHE or DH_Anon. These cipher suites require that the server owns a certificate with a DH public key in it, which is rarely supported for different reasons.

Note: DHKE prevents against an attack, where the government obtained a secret order from a judge, demanding to hand over the private key of the recipients server, like is was done with Lavabit.

Verifies inbound connections based on the following rules.

Each rule consists of a From address, a To address and a type.

Note: Wildcards are allowed.

Note: At present the To address is not honored and must be a *

Examples:

Use mandatory TLS on all inbound messages from @secure.com

Use opportunistic TLS for all not covered by a rule

Reject the message during the SMTP session on

XWall terminates the connection if any checked condition is not fulfilled.

weak cipher

Basically AES with 128 bit and all algorithms with 256 bits are strong ciphers, everything else is weak.

Note: A strong key and a strong cipher makes it harder, if not impossible, for the NSA (National Security Agency) to crack the communication.

missing PFS (Perfect Forward Secrecy) using Diffie-Hellman Key Exchange

PFS (Perfect Forward Secrecy) is a defense against an attacker who records encrypted conversations where the session keys are only encrypted with the communicating parties long-term keys. Should the attacker be able to obtain these long-term keys at some point later in the future, he will be able to decrypt the session keys and thus the entire conversation.

Diffie-Hellman Key Exchange is a specific method of exchanging cryptographic keys. The Diffie-Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher like AES.

Diffie-Hellman is used in SSL/TLS, as ephemeral Diffie-Hellman, the cipher suites with DHE in their name. What is very rarely encountered is static Diffie-Hellman, cipher suites with DH in their name, but neither DHE or DH_Anon. These cipher suites require that the server owns a certificate with a DH public key in it, which is rarely supported for different reasons.

Note: DHKE prevents against an attack, where the government obtained a secret order from a judge, demanding to hand over the private key of the recipients server, like is was done with Lavabit.

Verifys the S/MIME signature of an inbound message based on the following rules.

Each rule consists of a From address, a To address and one or more methods.

Note: Wildcards are allowed.

Verify the S/MIME signature

If checked, XWall verifies the S/MIME signature on an inbound message.

The result of the verification is written to the X-XWall-SMIME-Verify-Status: header line.

Remove the S/MIME signature

If checked, XWall removes the S/MIME signature from an inbound message.

Signs outbound message based on the following rules.

Each rule consists of a From address, a To address and a certificate.

Note: Wildcards are allowed.

The wildcard for the certificate is a * (star) and this means that XWall searches for a certificate file with the same name as the senders e-mail address, but with a .pem extension (e.g. user@domain.com.pem)

Examples:

Sign all outbound messages from your domain with your company certificate

Sign all outbound messages from your domain with a user certificate (e.g. user@domain.com.pem)

Sign all outbound messages from a user to a recipient with a user certificate

Don't sign outbound messages to a fax gateway

(use the !!void-certificate!! for do-nothing rules)

Some guidelines for the certificate:

• The certificate must be in PEM format
• The certificate file with the private key of the sender, required for signing, must be in the CERT \ PRIV directory

The entire content of your message, including all attachments, will be signed with your private key and the certificate will added to the message signature

The header of the message, including the subject of the message, will not be signed

Recipients of your signed message will be able to verify that the content has not been altered, and they will be able to store your certificate and later send you encrypted messages.

See also S/MIME Quick Start

Encrypts outbound message based on the following rules.

Each rule consists of a From address, a To address and a certificate.

Note: Wildcards are allowed.

The wildcard for the certificate is a * (star) and this means that XWall searches for a certificate file with the same name as the recipients e-mail address, but with a .pem extension (e.g. user@domain.com.pem).

If there is no such certificate, XWall searches for a certificate file with the db- in front (e.g. db-user@domain.com.pem). This are the certificates that XWall optionally extracted from signed messages.

Examples:

Encrypt all outbound messages where a public certificate for the recipient is available

Encrypt all outbound messages from a user to a recipient with a recipient public certificate

Some guidelines for the certificate:

• The certificate must be in PEM format
• The certificate file with the public key of the recipient, required for encrypting, must be in the CERT \ PUB directory

The entire content of your message, including all attachments, will be encrypted with the public key of the recipient.

The header of the message, including the subject of the message, will not be encrypted.

Decrypts inbound message based on the following rules.

Each rule consists of a From address, a To address and a certificate.

Note: Wildcards are allowed.

The wildcard for the certificate is a * (star) and this means that XWall searches for a certificate file with the same name as the recipients e-mail address, but with a .pem extension (e.g. user@domain.com.pem)

XWall searches for alternate certificate files in the CERT\PRIV\ALT directory. XWall uses for all certificate files that start with the same name as the original certificate file (e.g. if the original certificate name is peter@mydomain.pem, XWall will find peter@mydomain-2007.pem). This allows you to move outdated certificate files into the ALT directory, so that XWall can use them in the case it needs to decrypt an old message.

Examples:

Encrypt all inbound messages where a privat certificate for the recipient is available

Encrypt all inbound messages from a user to a recipient with a recipient private certificate

Some guidelines for the certificate:

• The certificate must be in PEM format
• The certificate file with the private key of the recipient, required for decrypting, must be in the CERT \ PRIV directory

Defines the S/MIME policy for an inbound message based on the following rules.

Each rule consists of a From address, a To address and one or more methods. If at least one checked method is fulfilled, XWall triggers the selected action.

Note: Wildcards are allowed.

Action

List of Actions

Defines the S/MIME policy for an outbound message based on the following rules.

Each rule consists of a From address, a To address and one or more methods. If at least one checked method is fulfilled, XWall triggers the selected action.

Note: Wildcards are allowed.

Action

List of Actions

Certificate authority certificate file

The name of the file with the certificate authority certificates, in PEM format.

XWall uses this list of authority certificates to validate the signature certificate.

XWall searches the file in the CERT folder, unless a full file name is given.

Collect the public certificate of the sender

If checked, XWall writes the certificate of the sender into the CERT\PUB directory.

The file name consist of the string db- and the e-mail address of the sender and the .pem extension.

This certificate can then be use to automatically encrypt all outgoing messages to the sender.

Log detailed S/MIME description

If this is enabled XWall shows a detailed description about the status of the S/MIME handling.

DKIM (DomainKeys Identified Mail) is a method for associating a domain name to an e-mail message, thereby allowing an organization to claim some responsibility for the message. The association is set up by means of a digital signature which can be validated by recipients. The verifier recovers the signer's public key using the DNS, and then verifies that the signature matches the actual message's content.

See www.dkim.org for more information on DKIM.

Signs outbound message based on the following rules.

Each rule consists of a From address, a To address, a certificate and a selector. Wildcards are allowed for the From and To field.

Examples:

Sign all outbound messages from your domain with your company certificate, using mail as the selector

Some guidelines for the certificate:

• The certificate must be in PEM format
• The certificate file with the private key, required for signing, must be in the CERT \ PRIV directory

The entire content of your message, including all attachments and the header lines, will be signed. Recipients of your signed message will be able to verify that the content has not been altered.

See also DKIMQuick Start

Verify DomainKey signature

If checked, XWall verifies the DKIM signature on an inbound message.

The result of the verification is written to the X-XWall-DKIM-Status: header line.

Optionally XWall can remove the DomainKey signature from the message, see Remove DKIM signature from the message

Block messages when the DKIM signature is not valid

If checked, XWall triggers the selected action when the DomainKey signature is not valid

Action

List of Actions

Allows you to exclude messages from every method that is checked in Exclude-Options.

The options are:

Exclude - E-mail Address

Exclude - Subject

Exclude - Text

Exclude - HTML

Exclude - IP Address

Exclude - Host

Exclude - Other

All options use the same logic as their corresponding blocking options. So for example in Exclude - Subject you can add a string or a word and if this string is in the subject, the message will not be blocked.

Note: If the SLS action is Block message transfer at the SMTP level then the message can not be excluded from SLS by the target address in Exclude - Address, Exclude - Address, Exclude - Text or Exclude - HTML. The reason is that the message is blocked before this information is sent by the sending server.

Note: Excluding an address does not mean that the message will not be virus scanned.

Enable gathering of outgoing recipient e-mail addresses and automatically exclude this e-mail addresses

When Exclude - White List is enabled, then XWall saves all outgoing e-mail addresses in a database and all incoming messages are checked against this database for exclusion.

This means that everyone to whom you send a e-mail is automatically excluded from spam checking.

This allows you to use a more aggressive spam checking, simply because all your customers/friends/relatives are excluded once you have them an e-mail.

Note: Make sure that your outgoing mail goes through XWall or XWall will not be able to get the e-mail address of the recipient.

Note: System messages like out-of-office message, non-delivery reports or delivery status notifications are ignored and not added to the white list.

Maintain a separate White List for each user

If enabled, XWall will create a separate White List for each user.

Pack the White List at midnight

If enabled, XWall will sync AdrOWL-A.dat with AdrOWL-B.dat. More technically speaking XWall will remove outdated and duplicated entries from AdrOWL-A.dat

Max addresses to gather

Defines how large the White List should become

Manage the White List by sending a message with an e-mail address in the subject to

Add e-mail address

Delete e-mail address

Defines an e-mail address that is NOT in your domain and that is used for manually adding or deleting of e-mail addresses.

If you are not sure what e-mail address you should use, then use add@whitelist.xxx and del@whitelist.xxx

To manually add an e-mail address send a message to add@whitelist.xxx with the e-mail address that should be added in the subject. To manually delete an e-mail address send a message to del@whitelist.xxx with the e-mail address that should be deleted in the subject.

How XWall stores the White List:

XWall stores the e-mail addresses in two files. AdrOWL-B.dat which is the binary database and AdrOWL-A.dat which is a ASCII file that acts as some kind of log that XWall uses to rebuild AdrOWL-B.dat from scratch.

You can edit AdrOWL-A.dat with an editor like Notepad and remove or add an e-mail address.

However, you need to stop XWall while you are doing this and when XWall starts up, it will create a new AdrOWL-B.dat from AdrOWL-A.dat. Depending on the size of your AdrOWL-A.dat, this may take some time (app. 30 minutes for 1.000.000 e-mail addresses)

Note: Excluding an e-mail address does not mean that the message will not be virus scanned.

Technical side note: There are duplicated e-mail addresses in AdrOWL-A.dat because AdrOWL-A.dat is actually a logfile and not a database. XWall uses AdrOWL-A.dat to rebuild AdrOWL-B.dat and due that AdrOWL-B.dat has a limited capacity (100.000 by default) only the last 100.000 e-mail addresses are added to AdrOWL-B.dat.

Additional Info: Synchronizing the White List across a server farm

Enable Legitimate Lookup Service (white list SLS/RBL)

IP address based services

XWall checks if the IP address of the sending host and/or all IP addresses in the header of the messages is on one of the lists. You can create a group of services by separating the services with a comma. In a group the IP address must be on each list to be excluded.

Add Common

Adds some common free-of-charge services.

Domain based services

XWall checks if the e-mail domain of the sender (the MAIL FROM: e-mail domain) is on one of the lists.

Examine the IP addresses in the message header in the IP address based Spam Lookup Service

If this is checked, XWall will scan the Received: lines of the header of the message for the IP (but not the host name)

dnswl.org provides a White List of known legitimate e-mail servers to reduce the chances of false positives while spam filtering.

There are 4 score levels which represent the trustworthiness:

• None - Legitimate mail server, may send spam (e.g. Hotmail, Yahoo)
• Low - Occasional spam occurrences, actively corrected but less promptly
• Medium - Extremely rare spam occurrences, corrected promptly
• High - Never sends spam

And there are categories:

• Financial services
• E-Mail Service Providers
• Organisations (both for-profit [ie companies] and non-profit)
• Service/network providers
• Personal/private servers
• Travel/leisure industry
• Public sector/governments
• Media and Tech companiessome
• special cases
• Education, academic
• Healthcare
• Manufacturing / IndustrialRetail / Wholesale / Services
• E-Mail Marketing Providers

Examine the IP addresses in the message header in the IP address based Spam Lookup Service

If this is checked, XWall will scan the Received: lines of the header of the message for the IP (but not the host name)

Note: As a good starting point check Medium and High and all categories.

Exclude messages when the DKIM signature is valid

XWall verifies the DKIM signature of the message and if the signature is valid, then message is excluded from every method that is checked in Exclude-Options.

Exclude only messages sent from the following e-mail address

If you add a domain, then XWall verifies only messages from that domain. Spammer sometimes also use DKIM and here you can tell XWall verify only know domains.

Add Common

Adds some common DKIM domains.

Exclude messages when the SPF (Sender Permitted From) result is PASS

XWall verifies the SPF of the message and if the SPF results in PASS , then message is excluded from every method that is checked in Exclude-Options.

Exclude only messages sent from the following e-mail address

If you add a domain, then XWall verifies only messages from that domain. Spammer sometimes also use SPF and here you can tell XWall verify only know domains.

Add Common

Adds some common SPF domains.

Allows you to define which methods should be excluded by the white list exclusion and by all other exclude options.

The White list excludes from these methods

Here you indicate which methods will be applied (or ignored) for e-mail addresses appearing in the White List.

For example:

by default the Exploit method is not checked. As a result XWall will block a message with an exploit even when the e-mail address of the sender is on the White List.

by default the Subject method is checked. As a result XWall will not block a message where the e-mail address of the sender is on the White List, regardless of the subject.

All other exclusions exclude from these methods

Here you indicate which methods will be applied (or ignored) for e-mail addresses appearing in all other Global Exclude options.

For example:

by default the Exploit method is not checked. As a result XWall will block a message with an exploit even when the message is coming from an excluded IP address.

by default the Subject method is checked. As a result XWall will not block a message, when the message was coming from an excluded IP address.

Bind to address

SMTP outbound port

By default XWall uses port 25 for outgoing connections and there is usually no need to change this.

SMTP inbound port

By default XWall accepts incoming connections on port 25 and there is usually no need to change this.

Note: Don't change the port from the default (port 25) unless you know what you are doing. Usually using a different port results that XWall can no longer send out or that you create a message loop.

Bind to IP address

In general you should leave the fields blank and let XWall detect the IP address automatically.

Note: XWall binds to every address of the machine, if your machine has more than one IP address, and in general this is ok.

Note: Don't bind to an IP address unless you know what you are doing. Usually binding to an IP address results that your Exchange can not send or that XWall can not detect Exchange.