IP Screening

Use the Security Address Suppression/IP Screening… (or F4) menu selection to configure IP Screening. The IP Screen is a list of IP addresses that you have designated as either acceptable or non-acceptable. How the server treats attempted connections from the IP addresses listed on the IP Screen depends on the security setting selected in the Screen editor. You may specify a list of IP addresses and then configure the server to only allow connections from those on the list, or you can configure it to abort any connection attempt from an IP address on the list. Wildcards are acceptable in any of the four IP address positions:

*.*.*.* Matches to any IP address
206.*.*.* Matches to any IP that begins with 206
206.97.*.239 Matches to IP addresses from 206.97.0.239 to 206.97.255.239

Current IP Screen Entries

This window displays all IP addresses that are being screened by MDaemon. They are listed either globally or according to the Local IP Address to which they apply.

New IP Screen Entry

Local IP

Choose from the drop-down list either "All IP's" or the local IP to which you wish to apply the screen.

Remote IP

Enter an IP address that you wish to add to the screened list. You must enter this address in dotted decimal form. The IP Screen works with IP addresses only. Click the Add button to add the specified IP address to the address listing.

This remote IP can connect

Selecting this option will allow only those IP addresses specified under the given domain to connect and deliver messages. Attempts to connect via IP addresses not specified in the listing will be refused and immediately aborted. This option is useful for setting up private mail network systems.

This remote IP can not connect

Selecting this option will allow all IP addresses other than those specified in the address listing to connect and deliver messages. Attempts to connect from IP addresses specified in the address listing will be refused and immediately aborted. This option is useful for excluding IP's that cause problems for your mail transport system.

Add

Click this button to add the address specified in the IP Address control to the Current IP Screen Settings window.

Remove

Click this button to remove a selected entry from the listing.

Default for Undefined IP's

Undefined IPs can connect to this local IP

When this option is chosen, all IP addresses not listed in the IP Screen will be allowed to connect.

Undefined IPs cannot connect to this local IP

When this option is chosen, only those IP addresses specifically granted permission in the IP Screen will be allowed to connect.

Current Host Screen Entries

This window displays all hosts that are being screened by MDaemon. They are listed either globally or according to the Local IP Address to which they apply.

New Host Screen Entry

Local IP

Choose from the drop-down list either "All IP's" or the local IP to which you wish to apply the screen. This is the IP address that the remote host is attempting to connect to.

Remote host

Enter a host that you wish to add to the screened list. Wildcards are permitted, so you could enter "*.example.com" to prevent or allow connections from all sub domains of example.com, or "example.*" to apply the screen to all top-level domains beginning with "example". Click the Add button to add the specified host to the list.

This remote host can connect

Selecting this option will allow only those host specified under the given domain to connect and deliver messages. Attempts to connect by hosts not specified in the listing will be refused and immediately aborted. This option is useful for setting up private mail network systems.

This remote host can not connect

Selecting this option will allow all host other than those specified in the address listing to connect and deliver messages. Attempts to connect by a host specified in the address listing will be refused and immediately aborted. This option is useful for excluding hosts that cause problems for your mail transport system.

Add

Click this button to add the host to the list.

Remove

Click this button to remove a selected entry from the list.

Default for Undefined Hosts

Undefined hosts can connect to this local IP

When this option is chosen, all hosts not listed in the host screen will be allowed to connect to the specified IP address.

Undefined hosts cannot connect to this local IP

When this option is chosen, only those hosts specifically granted permission in the host screen will be allowed to connect to the specified IP address.

Use the Security IP Shielding… menu selection to configure IP Shielding. The IP Shield is a list of domain names and matching IP addresses that will be checked during the SMTP MAIL FROM: command. An SMTP session claiming to be from someone at one of the listed domains will be honored only if it is coming from a machine with one of the associated IP addresses. For example, suppose your domain name is mdaemon.com and your local LAN computers use IP addresses in the range from 192.168.0.0 to 192.168.0.255. With this information you can set up IP Shielding to associate the domain name mdaemon.com with the IP address range 192.168.0.* (wildcards are allowed). Thus anytime a computer connects to your SMTP server and states, "MAIL FROM ", the SMTP session will continue only if the connecting computer has an IP address within the required range from 192.168.0.0 to 192.168.0.255.

Currently Defined Domain/IP Pairs

This is the list of domain names and their corresponding IP addresses that will be compared when someone attempts to connect to MDaemon claiming to be from one of them.

Messages to valid local users are exempt from domain/IP matching

Click this option if you want only those messages that are destined for a non-local user or invalid local user to be checked for a domain/IP match. This will prevent others from posing as one of your local users in order to relay their mail through your server but save resources by not checking those sending messages to users on your server. If you click both this option and the IP Shield honors aliases option below, messages to valid aliases will be accepted as well.

IP Shield honors aliases

Click this option if you want the IP Shield to honor address aliases when checking domain/IP address shields. If IP Shield honors aliases is clicked, the IP Shield will translate an alias to the true account to which it points and thus honor it if it passes the shield. Without this option enabled, the IP Shield will treat each alias as if it is an address independent of the account that it represents. Thus, if an alias' IP address violates an IP Shield then the message will be refused. This option is mirrored on the Alias Editor (Accounts Address aliases…)-changing the setting here will be reflected there.

If you want incoming messages to valid address aliases to be exempt from IP Shielding then click both this option and the Messages to valid local users are exempt from domain/IP matching option above.

Domain name

Enter the domain name that you wish to associate with a specific IP address range.

IP address

Enter the IP address that you wish to associate with a domain name. You must enter this address in dotted decimal form.

Add

Click the Add button to add the domain and IP address range to the listing.

Remove

Click this button to remove the selected entries from the listing.

SMTP Authentication

Authenticated senders are valid regardless of the IP they are using

When this control is active, currently shielded IP addresses will not apply to users that have been authenticated. Mail will be accepted from them regardless of the IP address from which they are connecting.

Authenticated users are exempt from the POP before SMTP requirement

If you are utilizing the POP before SMTP security feature below, you may click this control to make authenticated users exempt from this restriction. An authenticated user will not need to check his or her email before sending messages.

Authentication is always required when mail is from local accounts

When this option is enabled and an incoming message claims to be from one of MDaemon's domains, the account must first be authenticated or MDaemon will refuse to accept the message for delivery.

…unless message is to a local account

If you are requiring authentication of messages from local accounts but wish to skip the authentication when the recipient also is a local account, and then click this option. Note: this may be necessary in some situations where you require some of your users to use different mail servers for outgoing and incoming mail.

Mail from 'Postmaster' alias requires an authenticated session

Click this checkbox to require messages claiming to be from one of your "postmaster@..." aliases to be authenticated before MDaemon will accept them. Spammers and hackers know that the "postmaster" account exists and may attempt to use that account to send mail through your system. This option will prevent them and other unauthorized users from being able to do so. This option is also available on the Alias Editor (Accounts Address aliases…). Changing the setting here will be reflected there as well.

Authentication credentials must match those of the email sender

Click this checkbox if you wish to require users who authenticate during SMTP delivery to use only their own authentication credentials. The logon and password used must be those of the sender given in the SMTP MAIL command. This will prevent valid local users from being able to send email through your system from addresses other than their own.

Global AUTH password

If the Authenticated senders are valid regardless of the IP they are using control is enabled, MDaemon accounts configured for dynamic NT authentication must use this global AUTH password for authentication instead of their normal NT password.

POP Before SMTP

Local sender must have accessed mailbox within last [XX] minutes

With this feature enabled, whenever someone claims to be a local user they must have logged in and checked their local mailbox within the specified number of minutes before they will be allowed to send mail.

Messages collected via ATRN are exempt from this requirement

Click this control if you want messages collected via ATRN to be exempt from the POP Before SMTP requirement.

Messages sent to local recipients are exempt from this requirement

Click this checkbox if you want messages that are sent from one local user to another to be exempt from the "Local sender must have accessed mailbox…" requirement. Ordinarily, MDaemon will enforce the "POP before SMTP" requirement as soon as the sender is known, but when this control is enabled MDaemon will wait until the recipient of the message is revealed before determining whether or not it is required.

Messages sent from trusted IPs are exempt from this requirement

If this checkbox is enabled, messages arriving from a domain listed in the Currently defined domain/IP pairs area of this dialog will be exempt from the Local sender must have accessed mailbox… requirement.

Creating an SMTP Session Policy Statement

Use this dialog to specify a Site Security Policy. The text is stored in the policy.dat file located in MDaemon's \app\ subdirectory and is transmitted to sending servers at the beginning of every SMTP mail session. An example of a common site policy is, "This server does not relay" or "Unauthorized use prohibited." You do not need to prepend each line with "220" or "220-". MDaemon handles each line accordingly, either with or without these prepended codes.

A site usage policy with a statement regarding relaying of mail would look like this during the SMTP transaction:

220-Alt-N Technologies ESMTP MDaemon v8.0220-This site does relay unauthorized email.220-If you are not an authorized user of our server220-then you must not relay mail through this site.

HELO domain.com…

The POLICY.DAT file must be comprised of printable ASCII text only and have no more than 512 characters per line; however no more than 75 characters per line is highly recommended. The maximum size of this file is 5000 bytes. MDaemon will not display files larger than 5000 bytes.

Use the Security Relay/… (Alt+F1) menu selection to define how your server reacts to mail relaying. When a message arrives at your mail server that is neither from nor to a local address, your server is being asked to relay (or deliver) the message on behalf of an unknown third party. If you do not want your server to relay mail for unknown users you can use the options provided here.

Mail Relaying

This server does not relay mail for foreign domains

When this switch is selected, MDaemon will refuse to accept messages for delivery that are both FROM and TO a non-local user.

Refuse to accept mail for unknown local users

When this checkbox is enabled, MDaemon will refuse to accept mail that is for a local domain but addressed to a nonexistent user. "Local" includes both LAN and Domain Gateways.

Sender's address must be valid if it claims to be from a local domain

If the person sending a message claims to be from one of MDaemon's domains, the account used will be verified against the account database. The local account must exist or MDaemon will refuse to accept the message for delivery.

Mail addressed to known aliases can always be relayed

Click this control if you want MDaemon to relay mail for Address Aliases regardless of your Relay Control settings.

Mail sent via authenticated SMTP sessions can always be relayed

When this checkbox is enabled, MDaemon will always relay mail when it is sent via an authenticated SMTP session.

Mail can always be relayed through domain gateways

Enable this checkbox if you want MDaemon to permit mail relaying through domain gateways regardless of your Relay Control settings. This feature is disabled by default and isn't recommended.

Domain and IP Permissions

Trusted domains

Domains that you list here are exceptions to the no-relay rule. These domains are "trusted" by your server and MDaemon will not refuse to relay mail for their users.

New trusted domain

Enter a new domain name to be added to the Trusted Domains list.

Add

Click this button to add the new domain to the Trusted Domains list.

Remove

Click this button to remove the selected entries from the Trusted Domains list.

Trusted IP addresses

IP addresses that you list here are exceptions to the no-relay rule. These IP addresses are "trusted" by your server and MDaemon will not refuse to relay mail for their users.

New trusted IP address

Enter a new IP address to be added to the Trusted IP Addresses list.

Add

Click this button to add the new IP address to the Trusted IP Addresses list.

Remove

Click this button to remove the selected entries from the Trusted IP Addresses list.

Click Security Relay/Trusts/Tarpit/… (Alt+F1) to open this dialog. It is used for configuring two security features: Tarpitting and Automatic IP Screening.

Tarpitting makes it possible for you to deliberately slow down a connection once a specified number of RCPT commands has been received from a message's sender. This is to discourage spammers from trying to use your server to send unrequested bulk email ("spam"). You can specify the number of RCPT commands allowed before tarpitting begins and the number of seconds to delay the connection each time a subsequent command is received from that host during the connection. The assumption behind this technique is that if takes spammers an inordinately long period of time to send each message then that will discourage them from trying to use your server to do so again in the future.

Automatic IP Screening bans a specific IP address from future connections to your MDaemon server once a specified number of "unknown recipient" errors occur from that address during a mail session. You can also ban hosts that attempt to relay messages through your server or deliver messages to unknown local accounts. These IP addresses and hosts will not be banned permanently. They will be banned only for the number of minutes that you have specified in the dialog's settings. The TARPIT.DAT file contains lists of IP addresses and the length of time they are banned. This file is memory resident and can be changed manually with a text editor. Further, when manually editing this file you can also create a

TARPIT SETTINGS:blank file called TARPIT.SEM and place it in MDaemon's \APP\ directory. This will cause MDaemon to reload the memory resident TARPIT.DAT file thus implementing your changes.

Tarpit Settings

Activate tarpitting

Click this check box to activate MDaemon's tarpitting features.

SMTP RCPT tarpit threshold

Specify the number of SMTP RCPT commands that you wish to allow for a given host during a mail session before MDaemon will begin tarpitting that host. For example, if this number was set to 10 and a sending host attempted to send a message to 20 addresses (i.e. 20 RCPT commands), then MDaemon would allow the first 10 normally and then pause after each subsequent command for the number of seconds specified in the SMTP RCPT tarpit delay control below.

SMTP RCPT tarpit delay (in seconds)

Once the SMTP RCPT tarpit threshold is reached for a host, this is the number of seconds that MDaemon will pause after each subsequent RCPT command is received from that host during the mail session.

White list

Click this button to open the Tarpitting White List dialog. On it you can designate IP addresses that you wish to be exempt from tarpitting.

Automatic IP Screening

Activate automatic IP screening

Click this check box to activate Automatic IP Screening.

Advanced

Click this button to open the tarpit.dat file in a text editor. This file lists all IP addresses that have been banned by Automatic IP Screening. You can manually add IP addresses and the number of minutes to ban them by listing them one entry per line in the form: IP_addressMinutes. For example, 1.2.3.4 60 .

'Recipient unknown' error threshold

This is the number of "Recipient unknown" errors allowed from a given host during a mail session before that host will be automatically banned for the number of minutes specified in the Ban sites for this many minutes option below. Frequent "Recipient unknown" errors is often a clue that the sender is a spammer since they commonly attempt to send messages to outdated or incorrect addresses.

Ban sites that connect more than [X] times in [X] minutes

Click this check box if you wish to temporarily ban sites that connect to your server an excessive number of times in a limited time period. Specify the number of minutes and the number of connections allowed in that period.

Ban sites that fail this many authentication attempts

Use this option if you wish to temporarily ban sites that fail an authentication attempt a specified number of times. This can help prevent attempts to "hack" a user account and falsely authenticate a session.

Ban sites for this many minutes

When an IP address is automatically banned, this is the number of minutes that the ban will last. When the ban expires the host will be able to send to you again normally. This feature prevents you from accidentally banning a valid sender permanently.

Authenticated sessions are exempt from tarpit and IP screening

Click this checkbox if you want senders who authenticate their mail sessions before sending to be exempt from tarpitting.

Using the controls on this tab, MDaemon can be configured to do a reverse lookup on the domain passed in the HELO/EHLO and/or MAIL commands. When performing the lookups MDaemon will attempt to acquire all of the MX and A record IP addresses for the given domain. Then the IP of the machine making the connection is compared to this list in an attempt to determine whether the sender might be forging their identity.

Oftentimes the sending mail server's IP address will not match any known MX or A records for a given domain and yet still be delivering the mail legitimately. The purpose of the Reverse Lookup process is therefore not to exclude mail but to include as much information as possible in the log files, and to provide the means whereby the postmaster can act according to their own local policies regarding these suspicious messages. To that end, an option exists that makes it possible for a special header to be inserted into all messages that do not pass a reverse lookup. The content filter system can then be used to determine the fate of messages containing the header.

You can also perform reverse lookups on pointer (PTR) records of incoming IP addresses. When using this option the connection can be aborted or a warning header inserted into the message if the incoming IP address does not match any PTR record.

Finally, it is generally agreed that accepting mail from sources that identify themselves by using a domain that does not exist should be optional. Therefore, a switch exists that makes it possible for you to refuse messages for which the reverse lookup process returns a "domain not found" message from the DNS server. In such cases, MDaemon will return a 451 error code, refuse to accept the message, and then allow the SMTP session to progress. However, should you wish to return a 501 error code, close the socket connection, or do both, other switches are provided for those purposes.

Trusted IP addresses and localhost (127.0.0.1) are always exempt from reverse lookups.

Reverse Lookups

Perform reverse PTR record lookup on inbound SMTP connections

Enable this option if you want MDaemon to perform reverse pointer record lookups on all inbound SMTP connections.

…send 501 and close connection if no PTR record match

If this box is checked then MDaemon will send a 501 error code (syntax error in parameters or arguments) and close the connection if the result of a reverse pointer record lookup fails to match.

Perform lookup on HELO/EHLO domain

Click this box if you want a reverse lookup to be performed on the domain name that is reported during the HELO/EHLO portion of the session. The HELO/EHLO command is used by the client (sending machine) to identify itself to the server. The domain name passed by the client in this command is used by the server to populate the from portion of the Received header.

Perform lookup on value passed in the MAIL command

Enabling this switch will cause a reverse lookup to be performed on the domain name that is passed during the MAIL command portion of the mail transaction. The address passed in the MAIL command is supposed to be the reverse-path for the message, and is usually the mailbox from which the message is originating. Sometimes, however, it is the address to which error messages should be directed instead.

…send 501 and close connection on forged identification (caution)

Click this check box if you want a 501 error code to be sent and then the connection closed when the result of a reverse lookup appears to be a forged identification.

Refuse to accept mail if a lookup returns 'domain not found'

When a lookup results in "domain not found", enabling this option will cause the message to be refused with a 451 error code (Requested action aborted: local error in processing) and then the session will be allowed to progress normally to its conclusion.

…send 501 error code (normally sends 451 error code)

Enable this checkbox if you want the error code that is sent in response to a "domain not found" result to be 501 (syntax error in parameters or arguments) instead of 451.

…and then close the connection

Click this checkbox if you want the connection to be closed immediately instead of allowed to progress when "domain not found" is the result of the reverse lookup.

Insert 'X-Lookup-Warning' header into suspicious messages

Click this checkbox if you want a header to be inserted into messages that are considered suspicious due to the results of the reverse lookup. You can edit the name and content of the header by editing the following MDaemon.ini key:

[Special]
LookupWarningHeader=X-LookupWarning: text

If you edit this value, MDaemon will allow you to make the "X-LookupWarning: text" portion anything that you want, but be certain that your alterations conform to RFC regulations regarding mail headers.

White list

Click this button to open the Reverse Lookup White List dialog. On it you can designate IP addresses that you wish to be exempt from reverse lookups.

Note:This dialog is identical to the dialogs of the same name located in RAS Dialup Settings and Bandwidth Throttling. Changes made to the settings on any one of these dialogs will appear on all of them.

These IPs are on my local LAN

This tab is used to list IP addresses that reside on your LAN (local area network). These IP addresses therefore do not require RAS to reach them, and they are treated as local traffic for the purposes of bandwidth throttling. Further, there are various other security and spam prevention restrictions that they may be exempt from since they are local addresses.

Remove

Select an IP address from the list and then click this button to remove it. You may also double click an entry to remove it.

New local LAN IP

Enter an IP address to add to the local IP list and click Add. Wildcards like 127.0.*.* are permitted.

Add

After entering an IP Address into the New local LAN IP control, click this button to it to the list.

Hide local IPs when processing message headers

Click this check box if you want MDaemon to hide all local IP addresses when it creates received headers.

…hide these LAN IPs also

If MDaemon is configured to hide local IP addresses, click this check box if you want to hide these LAN IP addresses as well.

All domains publish MX records to identify the machines that may receive mail for them, but this doesn't identify the locations allowed to send mail for them. Sender Policy Framework (SPF) is a means whereby domains can also publish "reverse MX" records to identify those locations authorized to send messages.

Use the options on this tab to configure your server's SPF settings.

For more information on SPF, visit http://spf.pobox.com.

Sender Policy Framework

Enable SPF lookups

Click this check box to enable SPF lookups-MDaemon will perform queries for SPF data on all incoming messages that do not come from white listed IP addresses or exempt sessions such as authenticated connections or trusted IP addresses (when those exemptions have been enabled).

Process 'From' headers with SPF

Click this option if you wish to perform an additional SPF lookup on the address found in a message's From header instead of just checking the sender identified in the SMTP envelope. If the address contained in the From header is the same as the one that was already checked during the SMTP session then the duplicate check is unnecessary and will be skipped.

Insert 'Received-SPF' header into messages

Click this option if you want a "Received-SPF" header to be inserted into each message.

…except when the SPF result is 'none'

Enable this option if you do not wish the "Received-SPF" header to be inserted into a message when the result of the SPF query is "none".

When SPF processing returns a FAIL result:

…send 550 error code

Click this check box if you want a 550 error code to be sent when the result of the SPF query is "Fail".

…and then close the connection

Enable this option if you want the connection to be closed immediately after sending the 550 error code.

The following options require MDaemon PRO

Add this to the Spam Filter score for PASS result

Specify the amount that you wish to be added to the message's Spam Score when the result of the SPF query is "Pass".

Add this to the Spam Filter score for NEUTRAL result

Specify the amount that you wish to be added to the message's Spam Score when the result of the SPF query is "Neutral".

Add this to the Spam Filter score for SOFT FAIL result

Specify the amount that you wish to be added to the message's Spam Score when the result of the SPF query is "Soft Fail".

Add this to the Spam Filter score for FAIL result

Specify the amount that you wish to be added to the message's Spam Score when the result of the SPF query is "Fail".

Use account email in SMTP envelope when forwarding messages

Click this option if you wish all mail automatically forwarded by MDaemon to use the email address of the account forwarding the mail. This helps reduce problems associated with forwarding. Normally, forwarded messages are sent using the email address of the original sender and not the email address of the account actually doing the forwarding.

Authenticated sessions are exempt from SPF processing

Click this check box if you wish authenticated connections to be exempt from SPF queries. Authenticated sessions include those verified via AUTH, POP before SMTP, or the IP Shield.

White List

Click this button to open the SPF white list on which you can designate IP addresses that you wish to be exempt from SPF lookups.

Connections from Trusted IPs are exempt from SPF processing

Enable this option if you want connections from Trusted IP addresses to be exempt from SPF.

Cache SPF results

Click this option if you wish to temporarily cache the results of SPF queries.

Cache

This button opens the SPF cache.

Additional Links

Search

Documentation

Authorization

 
Forgot your password?
Register

Subscribe

Subscribe to company news