This config section holds settings for the SMTP server module. This module listens for incoming connections and allows mail to be sent to your company.
The following settings can be used in this section:
Enable
You can turn on/off the entire SMTP server module using this switch
bool
On/Off, True/False, Yes/No, 1/0
On
Enable=On
Hide
You can hide the SMTP Server interface entirely using this switch
bool
On/Off, True/False, Yes/No, 1/0
off
Hide=off
Host
the explicit network address or hostname of the network card you wish the server to bind to. Typically you will want to leave this blank to ensure binding to the default network device. Setting this to 127.0.0.1 can render it impossible to connect to the application
text
Host=127.0.0.1
Port
the port you wish the server to bind to. If you are using Hexamail as the gateway for your company email, you will typically want to leave this on the default setting of 25
number
25
Port=25
PortEnable
You can optionally enable this protocol
bool
On/Off, True/False, Yes/No, 1/0
true
PortEnable=true
SSLPort
You can allow SMTP access over SSL on a separate port. 465 is the default standard for SSL enabled SMTP and will work with most email clients.
number
25 - 32000
465
SSLPort=465
SSLHost
The host binding or NIC to use for SSL communications
text
SSLHost=127.0.0.1
SSLPortEnable
You can optionally enable this protocol over a secure channel using SSL. If you do not specify a certificate name using the SSLCertificate configuration parameter in the config file (.cfg) one will be created automatically for you. However, as this is an auto-created certificate it will not be signed by a certification authority and may cause warnings in the clients used to connect to this server. If the users of the clients accept the warnings, then SSL can be used immediately. If you do not wish users to see these warnings you need to obtain and install a valid, signed, SSL certificate for your server from a provider such as Thawte, or Verisign. You must then specify the certificate name in the SSLCertificate parameter of the configuration file.
bool
On/Off, True/False, Yes/No, 1/0
false
SSLPortEnable=false
SSLCertificate
WIN32: Choose a valid suitable certificate from those listed. If none are shown, then there are no suitable certificates installed on the server machine. You can install a certificate using IIS and then use that certificate from Hexamail. Certificates must be suitable for server authentication and secure channel encryption.
LINUX (OpenSSL): Specify the name/full path of a PEM certificate file valid for SSL server usage.
select
SSLPrivateKey
OpenSSL (LINUX) ONLY: You can optionally provide a separate private key PEM file. This must match the public key used of the certificate PEM file.
text
MaxConnections
You can allow a large number of simultaneous connections to provide for large amounts of email users. Set this high if you have lots of users all wishing to connect simultaneously.
number
1 - 256
32
MaxConnections=32
TimeOut
If no data at all is received from a remote server within this time the connection is dropped
240 Seconds
TimeOut=60
MaxDuration
If an operation is not completed within this time the connection is dropped
6000 Seconds
MaxDuration=6000
SpecialSMTPGreeting
The SMTP Greeting text can optionally be specified manually here. To use default setting, leave this field blank
text
SpecialSMTPGreeting=ESMTP server
GreetWithCompanyName
The greeting provided to connecting clients can optionally include company name shown in your license. When clients connect via SMTP to deliver email to your server they receive an 'SMTP Greeting' - this is a short banner telling the client about the server it is connecting to. The string can optionally include your company name as part of the greeting. Turn this off to remove your company name from the greeting string.
bool
On/Off, True/False, Yes/No, 1/0
on
GreetWithCompanyName=on
GreetWithProductVersion
The greeting provided to connecting clients can optionally include product and version information. When clients connect via SMTP to deliver email to your server they receive an 'SMTP Greeting' - this is a short banner telling the client about the server it is connecting to.
The string can optionally include your product name and version name as part of the greeting. This allows other organizations to debug any potential problems. In some situations you may want to disable this to prevent malicious attacks based on known vulnerabilities, thought there are no known vulnerabilities at this time.
bool
On/Off, True/False, Yes/No, 1/0
off
GreetWithProductVersion=on
SpecialSMTPGoodbye
The SMTP Goodbye text can optionally be specified manually here. To use default setting, leave this field blank
text
MaxEmailSize
You can set the maximum message size that is allowed to be sent through this server. Remember that this includes the size of the attachments encoded using MIME encoding. Hexamail will disconnect any email client attempting to send larger email.
number
1 - 512000 kbytes
32000 kbytes
MaxEmailSize=10000
MaxEmailSizeInt
You can set the maximum message size that is allowed to be sent through this server by an internal domain sender address. Remember that this includes the size of the attachments encoded using MIME encoding. Hexamail will disconnect any email client attempting to send larger email.
number
1 - 1000000 kbytes
64000 kbytes
MaxEmailSizeInt=56000
MaxEmailSizeSkipFor
Skip mesage size checks for these sender addresses
text
MaxEmailSizeSkipFor=admin@domain.com
MaxEmailLines
You can set the maximum number of lines a email can have before the server blocks the email. This includes the lines used in transmitting attachments, HTML alternative versions etc.
number
1 - 256000 lines
1000 lines
MaxEmailLines=1000
Domains
The domain list is used by Hexamail Vault to work out which email are incoming and which are outgoing. Email to recipients with addresses matching these domains are considered as incoming, and will be sent to the configured Existing Email Server. Email to recipients with addresses not matching these domains will be sent to the configured Smart Host or directly to the external email server using MX Lookup delivery.
The primary domain is used for auto-completion of email addresses and reporting to clients the name of the SMTP server. It should be configured to be one of your served domains
You can optionally provide a list of valid users of your system in the form of their email addresses. This list can subsequently be used to allow restriction of activities to only those users, for example sending email to people outside of your domains (relay). If you provide no list any email address matching your configured domains will be considered a valid internal user. This can save you having to mirror all your users, groups and aliases in Hexamail, but also means that you may receive email that subsequently wont have anywhere to be delivered to in your email server. Remember that any groups or routes you have configured in the application also need to be added to this list if you are using the user list.
You can restrict the ability to send email to only your listed users. This can help prevent open relay, but be sure to add all your users to this list, otherwise they cannot send email to external parties
You can ensure that only valid, listed internal recipients may receive email. This includes all email addresses configured for users, their alias, groups, routes and responders.
Email addresses matching your configured domains are considered internal, you can restrict sending to just senders from these domains using this switch. This will set your server to only allow incoming email to your domains to be received OR email sent from a user in a listed domain to send email to any external address. It prevents email from external addresses to other external addresses being sent with your server. This is one mechanism for "preventing open relay"
The list of IP addresses that will be allowed to relay through this server. You can use wildcards and ranges (e.g. 192.168.0.0/16, 192.*.*.*, 192.10-50.*.*) or leave blank for no restrictions. (Not recommended). Typically you want to set these to include the IP address of your email server (for example, in the case of Exchange it will be sending outgoing email), any internal ranges of IPs and also any external ones commonly used by your users if they use your server to send email when out of the office (Be careful when adding other ISP's IP ranges as the ISP may also host spammers who can then relay thru your server)
The default is usually sufficient to allow outgoing email to be sent from your email server, as the typical internal IP ranges (non routed IP ranges) of 192.168.*.*, 10.*.*.* and 172.16-31.*.* are present by default. (NOTE: 172.16-31.*.* is rarely used today)
The list of IP addresses that will not be allowed to relay through this server. You can use wildcards and ranges (e.g. 192.168.0.0/16, 192.*.*.*, 192.10-50.*.*) or leave blank for no restrictions. Normally this should be set to *.*.*.* to prevent open relay from any IP, except those specified in the Allowed Relay IP addresses.
You can also use the Relay IPs configured to restrict only these IPs to send email from your domain to your domain (internal email). Authentication overrides any IP restriction
This setting automatically allows clients to send or relay email if they have previously logged in via a webinterface, POP3 or IMAP within this time. Set to 0 to disable this feature
number
0 - 60 minutes
15 minutes
AutoLoginMaxTime=10
AutoCompleteAddresses
Allow users to send email without specifying a domain, email addresses with no domain are auto completed using the configured primary domain
You can set the maximum message size that is allowed to be sent through this server. Remember that this includes the size of the attachments encoded using MIME encoding. Hexamail will disconnect any email client attempting to send larger email.
number
1 - 512000 kbytes
32000 kbytes
MaxEmailSize=10000
MaxEmailLinesCheck
bool
On/Off, True/False, Yes/No, 1/0
false
MaxEmailLinesCheck=false
MaxEmailLines
You can set the maximum number of lines a email can have before the server blocks the email. This includes the lines used in transmitting attachments, HTML alternative versions etc.
number
1 - 256000 lines
1000 lines
MaxEmailLines=1000
AllowedIPList
This is the list of allowed IP addresses that can connect to your SMTP server. You can use wildcards and ranges (e.g. 192.168.0.0/16, 192.*.*.*, 192.10-50.*.*) or leave blank for any IP. WARNING: By setting this, connections are restricted to ONLY those that match an entry in this list. This is mainly used for ensuring that only another SMTP proxy server can connect to your system, for example a Virus screen/wall, proxy or firewall server.
In some situations you may need to extract the sender IP information from the email MIME headers instead of using the connection information.
Normally it is best to use the connection information. In cases where all your email comes from another relay server, forwarding service, or SMTP batching service,
it is necessary to inspect the MIME headers to obtain the sender IP address. Email downloaded via POP3 automatically uses this technique regardless of this setting
This is the list of connecting IP addresses for which the MIME IP is used rather than the connecting IP. You can use wildcards and ranges (e.g. 192.168.0.0/16, 192.168.0.0/16, 192.*.*.*, 192.10-50.*.*) or leave blank for any IP
Add any open relay or dial-up user list servers here to use them to prevent known spammers and open relays being able to send email and thereby prevent SPAMmers using your server to send email
Some DNSBL are free to use, others can require subscription should your email volume exceed certain limits. Please be sure to check with the DNSBL provider the terms of their usage policy.
DEPRECATED: Use the new unified DNSL editor
Many mailservers are well configured and never send spam. These DNS based list servers can help prevent good email be accidentally blocked
by other blocklists or spamblocking rules. The servers list the IPs of known good email servers.
Please be sure to check with the DNSWL provider the terms of their usage policy.
DEPRECATED: Use the new unified DNSL editor
the dns based lists that are to be used to delete email
text
ips.backscatterer.org
DNSLDelete=ips.backscatterer.org
DNSLReject
the dns based lists that are to be used to reject email
text
ips.backscatterer.org
DNSLReject=ips.backscatterer.org
DomainKeyEnable
This setting enables Yahoo Domain Keys processing for received email.
Domain Key processing involves verfiying incoming email using cryptogtraphic signatures.
This can help verify the identity of senders,
and therefore ensure that forged or spoofed email can be eliminated at the earliest opportunity.
It must look up domain keys for signed email from a DNS host so there may be some latency introduced when receiving email.
Using Domain Key processing may have some impact on CPU usage as it needs to verify each signed email using encryption.
For further information please consult the Yahoo Domain Keys pages:
http://antispam.yahoo.com/domainkeys/
off
DomainKeyEnable=off
DomainKeyPolicyAction
Domain Keys specifies that signing domains should publish a policy record specifying how they sign email. If an email is NOT signed the policy for that domain is looked up and the
email checked for breaches to the policy. For example, a policy may state that ALL email from the domain must be signed. In this case any unsigned email from that domain is either blocked (and quarantined) or rejected at the SMTP level as soon as it is submitted.
select
Accept, Block, Reject
Block
DomainKeyPolicyAction=Block
DomainKeyRequiredDomains
Currently many domains have policies that state that only SOME email may be signed, and that Domain Keys is in'testmode'. These policies mean that
email cannot be rejected according to policy breaches if it lacks a Domain Keys signature. If you wish to insist that selected domains MUST send Domain Key signed email, add the domains to the list.
BE SURE TO CHECK that the domains you add are indeed adding Domain Key signatures to their outgoing email and intend to continue to do so!
Once you have listed domains for which you REQUIRE a signature (regardless of policy), use this setting to select the action to take for email with no signatures from those domains.
select
Accept, Block, Reject
Block
DomainKeyRequired=Block
DomainKeyBadSig
If a Domain Key signed email is enountered, its Domain Key signature is verified against the email headers and content. If the signature doesn't match (so the email may be forged)
this setting selects the action to take. Remember that in some cases email may have been modified or corrupted on their way to your server (e..g if via a mialing list or news list server), so sometimes signatures fail for legitimate email.
In addition bear in mind that anyone can sign email from their own domain: so even spammers sometimes sign email with Domain Keys! Domain key signatures verify that the email does indeed come from the specified domain, not that the domain itself is one you wish to receive email from!
select
Accept, Block, Reject
Block
DomainKeyBadSig=Block
DomainKeyNoKey
Sometimes a signed email points to a domain which doesn't have a public key DNS entry published. This means the signature CANNOT be verified. Often these are SPAM email.
select
Accept, Block, Reject
Block
DomainKeyNoKey=Block
DomainKeyNoPolicy
Often an unsigned email points to a domain which doesn't have a policy DNS entry published. This means the policy CANNOT be verified, this setting is for future use when Domain Keys is more widely implemented.
select
Accept, Block, Reject
Accept
DomainKeyNoPolicy=Accept
DomainKeyRevoked
Sometimes a signed email points to a domain for which the key has been revoked. Use this setting to select an action for such email.
select
Accept, Block, Reject
Block
DomainKeyRevoked=Block
DomainKeySyntax
Sometimes a signed email contains MIME syntax errors. Use this setting to block such email.
select
Accept, Block, Reject
Block
DomainKeySyntax=Block
DomainKeyDebug
Due to the complexity of Domain Key processing this features allows the full MIME of Domain Key signed email to be dumped
to disk if the verification fails. This will allow better debugging of what may be wrong with the MIME of the email in question.
off
DomainKeyDebug=off
SPFEnable
This setting enables Sender Policy Framework processing for received email.
Sender Policy Framework processing involves verfiying incoming email are coming from the servers designated as being allowed to send email from the sender's domain.
This can help verify the identity of senders,
and therefore ensure that forged or spoofed email can be eliminated at the earliest opportunity.
It must look up special SPF DNS entries for ALL email received and so there may be some latency introduced when receiving email with SPF enabled.
For further information please consult the SPF homepage:
http://new.openspf.org/Introduction
on
SPFEnable=on
SPFMIMEFrom
This setting enables Sender Policy Framework processing to also take place on the MIME From address shown on the email by email clients (similar to Microsoft Sender ID).
This can help prevent spoofing. Sender Policy Framework processing involves verfiying incoming email are coming from the servers designated as being allowed
to send email from the sender's domain. This can help verify the identity of senders, and therefore ensure that forged or spoofed email can be eliminated at
the earliest opportunity. It must look up special SPF DNS entries for ALL email received and so there may be some latency introduced when receiving email with
SPF enabled. For further information please consult the SPF homepage:
http://new.openspf.org/Introduction
NOTE: SPF is intended to operate on the SMTP Envelope sender address not the displayed MIME From address, however it can be extremely useful to also check the displayed MIME
From domain against the SPF record in order to prevent spoofing. The end-user can only see the MIME From address in their email client, so it is useful to have verified it in some way
and to this date there is no dedicated standard for doing so, so SPF is the only available method.
off
SPFMIMEFrom=off
SPFDebug
This setting enables Sender Policy Framework debugging to the log file logs/spf.log
off
SPFDebug=off
SPFSoftFail
A softfail means that SPF check did not produce a specific failure, but neither
was the IP completely authorized for sending email from the sender domain.
Typically such results come from test SPF records
that domain owners have setup during the testing period or early phase of SPF.
It can be useful to quarantine these messages using the Block option for further inspection:
currently very few domains have full/strict checking in place so receiving a full failure is unlikely, and
a soft failure is indicative that the email originated somewhere unintended by the domain owner.
You SHOULD NOT reject these email outright as that goes against the RFC recommendation for SPF, and during this
early phase of the implementation of SPF some domain owners may be making mistakes with their records.
However, you are ALLOWED to reject these email if you wish, according to the RFC.
Full failures are automatically rejected, and full Pass results are accepted.
select
Accept, Weight, Mark, Block, Reject
Block
SPFSoftFail=Block
SPFFail
A fail means that SPF check produced a specific failure, the IP was not authorized for sending email from the sender domain.
It can sometimes be useful to quarantine these messages using the Block option for further inspection:
currently a few domains have incorrect SPF records in place so a full failure can sometimes occur unintentionally.
You CAN reject these email outright however as the domain owner/sender should receive a non delivery report from the server trying to send to Hexamail.
select
Ignore, Weight, Mark, Block, Reject
Reject
SPFFail=Reject
SPFSoftFail
A softfail against the MIME From field means that SPF check did not produce a specific failure, but neither
was the IP completely authorized for sending email from the sender domain.
Typically such results come from test SPF records
that domain owners have setup during the testing period or early phase of SPF.
It can be useful to quarantine these messages using the Block option for further inspection:
currently very few domains have full/strict checking in place so receiving a full failure is unlikely, and
a soft failure is indicative that the email originated somewhere unintended by the domain owner.
You SHOULD NOT reject these email outright as that goes against the RFC recommendation for SPF, and during this
early phase of the implementation of SPF some domain owners may be making mistakes with their records.
However, you are ALLOWED to reject these email if you wish, according to the RFC.
Full failures are automatically rejected, and full Pass results are accepted.
select
Accept, Weight, Mark, Block, Reject
Weight
SPFSoftFail=Weight
SPFFail
A fail against the MIME From means that SPF check produced a specific failure, the IP was not authorized for sending email from the sender domain.
It can sometimes be useful to quarantine these messages using the Block option for further inspection:
currently a few domains have incorrect SPF records in place so a full failure can sometimes occur unintentionally.
You CAN reject these email outright however as the domain owner/sender should receive a non delivery report from the server trying to send to Hexamail.
select
Ignore, Weight, Mark, Block, Reject
Block
SPFFail=Block
SPFSkipIPList
This setting allows you to bypass SPF checks for email originating from the listed IP addresses. IP addresses can include wildcards and ranges.
Use this list to list any secondary MX servers that are used if your primary MX fails. Email from those MX servers cannot have their originating IP checked reliably against SPF records, as the IP is masked
by the secondary MTA (queuing) server, and received from headers can be spoofed. In these cases SPF checks must be bypassed and the email processed in other ways to determine spam content.
Often MTAs hosted by large ISPs should alerady perform SPF checks so disabling SPF checking for secondary MX servers is an acceptable solution.
text
SPFSkipAddr
This setting allows you to bypass SPF checks for email from specific email addresses.
NOTE that without an SPF check you cannot depend on the email address being used by a legitimate sending server,
so in doing this you may allow email from spoofed sender addresses to bypass SPF checks.
They will stil be checked for spam using other measures though.
text
SPFSkipAddr=*@domain.com,specific@domain2.com
DisallowedIPList
This is the list of disallowed IP addresses that cannot connect to your SMTP server. You can use wildcards and ranges (e.g. 192.168.0.0/16, 192.*.*.*, 192.10-50.*.*) or leave blank for no restrictions. By setting this connections from any IP that matches an entry in this list are prevented.
Note that if an IP matches an entry in the allowed IP address it is allowed regardless of matching a disallowed IP
the dns based lists that are to be used to reject email
text
BlockedSenders
This is the list of disallowed email addresses that cannot send email through your SMTP server and will be rejected before they can send any data. You can use wildcards (e.g. *@*.tw, customerdirect@*.*) or leave blank for no restrictions. Note that this list overrides any 'Allowed Senders' and any 'auto-allowed' senders in the SPAM blocking module.
This is the list of allowed email addresses that can always send email through your SMTP server. You can use wildcards (e.g. *@*.tw, customerdirect@*.*) or leave blank for no specific allowed senders. Note that this list overrides any 'Blocked Senders'
Any recipients of email from users within your company can be automatically added to the list of users whose email will never be checked for SPAM. This helps prevent false-positives (email being marked/ blocked as SPAM when they are in fact not)
This is the list of recipient email addresses that cannot be sent to through your SMTP server. You can use wildcards (e.g. *@*.tw, customerdirect@*.*) or leave blank for no restrictions
The SMTP protocol transactions will be logged to the file logs/SMTPIn.log
bool
On/Off, True/False, Yes/No, 1/0
off
LogSMTP=off
MaxRecvBandwidth
You can throttle the maximum bandwidth allowed for sending email clients to use when communicating with it. Typically you do not need to change this setting.
number
1 - 1000000 kbps
1000000 kbps
MaxRecvBandwidth=64
MaxSendBandwidth
You can throttle the maximum bandwidth allowed for sending responses to email clients. Typically you do not need to change this setting.
number
1 - 1000000 kbps
1000000 kbps
MaxSendBandwidth=64
AllowAuthentication
This allows clients to authenticate usign a configured login and thereafter perform authenticated operatiosn as per your configuration.
This is useful in preventing unauthorized use of your mail server system to relay spam to other companies, an activity that can get your company blacklisted on Open Relay Databases.
In order to use this setting you MUST also add authentication users.
Turning off this setting will prevent authentication attempts using a configured login on this SMTP server
This allows clients to authenticate using a configured user and thereafter perform authenticated operatiosn as per your configuration.
This is useful in preventing unauthorized use of your mail server system to relay spam to other companies, an activity that can get your company blacklisted on Open Relay Databases.
In order to use this setting you MUST also add users or mailboxes.
Turning off this setting will prevent authentication attempts using a configured user or mailbox on this SMTP server
This restricts the AUTH mechanisms that are allowed for clients connecting over unencrypted channels.
Some AUTH mechanisms transmit passwords in an insecure way. You can restrict these mechanisms to only be allowed over
secured channels such as SSL or TLS
This restricts the AUTH mechanisms that are allowed for clients. It requires a service restart to change the available mechanisms.
Note DIGESTMD5 is now obsoleted by RFC5802 - Salted Challenge Response Authentication Mechanism (SCRAM) with reasons mentioned in RFC6331
bool
On/Off, True/False, Yes/No, 1/0
PLAIN,LOGIN,NTLM,CRAMMD5
AuthMethods=PLAIN+NTLM
AuthHost
The hostname used for Authentication, e.g. mycomputer
text
<hostname>
AuthHost=<hostname>
AuthDomain
The domain used for Authentication, e.g. domain.com
text
<domain>
AuthDomain=<domain>
AuthFQDN
The FQDN used for Authentication, e.g. mail.domain.com
text
<FQDN>
AuthFQDN=<FQDN>
AuthenticationRequiredRelay
DEPRECATED: This insists that clients be authenticated using LOGIN before allowing them to proceed with email relay (sending to recipients outside the configured domains). This is useful in preventing unauthorized use of your mail server system to relay SPAM to other companies, an activity that can get your company blacklisted on Open Relay Databases. In order to use this setting you MUST also add authentication users.
You do not need to check this box to allow users
who are on dial-up or external IPs to send using Authentication and bypass any Allowed Relay IP address list. This checkbox FORCES all users to authenticate to relay regardless of their IP.
DEPRECATED: This insists that clients be authenticated using LOGIN before allowing them to proceed with sending any email. In order to use this setting you MUST also add authentication users. You do not need to check this box to allow users
who are on dial-up or external IPs to send using Authentication and bypass any Allowed Relay IP address list. This checkbox FORCES all users to authenticate to send regardless of their IP.
You can insist that clients must be authenticated using LOGIN before allowing them to proceed with sending or relaying email (see settings above), or you can allow users who do authenticate to bypass any Allowed Relay IP address checks specified in the Relay page.
If users authenticate their login is verified against username password pairs in this list.
It is usually necessary to only add one or two logins and use them for all users: in this way you reduce maintenance of password lists. NOTE that this login has nothing to do with users receiving their email so
security is not compromized. These logins are merely to authenticate that your user belongs to your organization and should be allowed to relay and send email through your Hexamail Vault server.
Configuring Outlook Clients to use SMTP authentication to send
If you have setup logins in the Authentication Users list you need to configure your user's Email clients to send the authentication login when connecting to and sending email via Hexamail Vault.
In Outlook clients select the properties for the Email Account and go to the 'Servers' page/tab. Ensure your outgoing server is set to be the Hexamail Vault server and then check the 'My server requires authentication' checkbox. Next, click the Settings button to the right of the checkbox.
In the Outgoing Mail Server configuration box choose 'Log on using' and then specify the username and password you have added to the list of Authentication Users in Hexamail Vault.
Choose 'Remember Password' to save users having to retype the password to send every email. DO NOT select 'Log on using Secure Password Authentication' as this is a proprietary Microsoft protocol.
STARTTLS
If SSL is enabled you can also enable STARTTLS which allows secured encrypted communication over the standard SMTP port.
Connceting clients and servers will see this feature advertised in the EHLO response and be able to initiate a secure connection using the STARTTLS protocol
bool
On/Off, True/False, Yes/No, 1/0
on
STARTTLS=on
PreventAddressProbing
A delay can be enforced after every client enquiry into valid email addresses (SMTP VRFY and RCPT TO). This prevents mass probing for valid email addresses. The delay is only inserted after usual numbers of RCPT TO or VRFY commands have been processed: so it wont slow down your ability to receive legitimate email
text
Off
PreventAddressProbing=Off
PreventAddressProbingDelay
A delay can be enforced after every client enquiry into valid email addresses (SMTP VRFY and RCPT TO). This prevents mass probing for valid email addresses. The delay is only inserted after usual numbers of RCPT TO or VRFY commands have been processed: so it wont slow down your ability to receive legitimate email
number
1 - 60 seconds
5 seconds
PreventAddressProbingDelay=15
PreventAddressProbingAddresses
A delay can be enforced after every client enquiry into valid email addresses (SMTP VRFY and RCPT TO). This prevents mass probing for valid email addresses. The delay is only inserted after usual numbers of RCPT TO or VRFY commands have been processed: so it wont slow down your ability to receive legitimate email
number
2 - 2000
32
PreventAddressProbingAddresses=24
MaxRecipients
This is the maximum number of recipients allowed per incoming email. Email exceeding this number of recipients are processed according to the MaxRecipientsAction setting
this sets what happens to email that exceed the number of recipients specified in MaxRecipients. "Reject" makes the SMTP server reject the email completely. "Limit Recipients" limits the number of recipients of the email. "Close Connection" closes the email client's connection to the email server
select
Off, Limit Recipients, Reject Mail, Close Connection
If a single client sends too many email too rapidly its usually a sign of a compromised machine (for example a virus or malware). Use these settings to specify the maximum number of email a single client should send
in a specific period and what to do if this limits is exceeded. Use the "Ignore these IPs" to specify the IP of your mailserver and any webserver or other apps that may need to send large volumes of email in
short periods of time.
"Reject" temporarily rejects the email, no more email can be sent until the period has expired
"Close Connection" closes the email client's connection to the email server, no more email can be sent until the period has expired
"Block IP" closes the email client connection and blocks the IP temporarily (for 1 hour or until service restart)
select
Off, Reject Mail, Close Connection, Block IP
Off
MaxEmailUserAction=Off
See Also:
MaxEmailUserCount
Maximum number of email that can be sent by a user in the specified period
number
2 - 99999 email
5 email
MaxEmailUserCount=50
MaxEmailUserPeriod
The period to measure the maximum email count per user over
number
2 - 99999 seconds
60 seconds
MaxEmailUserPeriod=3600
AlertEmailUserCount
This alerts the adminafter this number of email are sent by a user in the specified period
number
2 - 99999 email
5 email
AlertEmailUserCount=50
MaxEmailIPAction
If a single client sends too many email too rapidly its usually a sign of a compromised machine (for example a virus or malware). Use these settings to specify the maximum number of email a single client should send
in a specific period and what to do if this limits is exceeded. Use the "Ignore these IPs" to specify the IP of your mailserver and any webserver or other apps that may need to send large volumes of email in
short periods of time.
"Reject" temporarily rejects the email, no more email can be sent until the period has expired
"Close Connection" closes the email client's connection to the email server, no more email can be sent until the period has expired
"Block IP" closes the email client connection and blocks the IP temporarily (for 1 hour or until service restart)
Maximum number of email that can be sent by a client in the specified period
number
2 - 99999 email
10 email
MaxEmailIPCount=50
MaxEmailIPPeriod
The period to measure the maximum email count per client over
number
2 - 99999 seconds
60 seconds
MaxEmailIPPeriod=3600
AlertEmailIPCount
This alerts the admin after this number of email are sent by a client in the specified period
number
2 - 99999 email
5 email
AlertEmailIPCount=50
MaxEmailSubjectAction
If a multiple clients send too many email with the same subject too rapidly its usually a sign of a coordinated botnet spam attack. Use these settings to specify the maximum number of email witht eh same subject clients should send
in a specific period and what to do if this limits is exceeded. Use the "Ignore these IPs" to specify the IP of your mailserver and any webserver or other apps that may need to send large volumes of email in
short periods of time.
"Reject" temporarily rejects the email, no more email can be sent with this subject until the period has expired
"Close Connection" closes the email client's connection to the email server, no more email can be sent with this subject until the period has expired
"Block IP" closes the email client connection and blocks the IP temporarily (for 1 hour or until service restart)
Maximum number of email with the same subject that can be sent in the specified period
number
2 - 99999 email
10 email
MaxEmailSubjectCount=50
MaxEmailSubjectPeriod
The period to measure the maximum email count
number
2 - 99999 seconds
120 seconds
MaxEmailSubjectPeriod=3600
AlertEmailSubjectCount
This alerts the admin after this number of email are sent with the same subject in the specified period
number
2 - 99999 email
8 email
AlertEmailSubjectCount=50
MaxEmailSkipIPList
This setting allows you to bypass max email rate checks for email originating from the listed IP addresses. IP addresses can include wildcards and ranges.
Use this list to list any mailservers or apps you have that send out email. For example if your mailserver sends email out thru Hexamial then you may want to exclude it from the max email count checks
text
127.*.*.*
MaxEmailSkipIPList=127.*.*.*
MaxSendersAction
Some clients, particularly spammers will try various sender addresses until they find one that is allowed. In this case you can close the connection
on them or block their IP address to prevent further attempts