smtpf.cf

While there is an example smtpf.cf file, it is recommended that you generate one in order to have the most up-to-date version. Some options maybe dropped or added and the example smtpf.cf may not be current. Use the command:

# smtpf -help > /etc/smtpf/smtpf.cf

If you already have a smtpf.cf configured, it will be read and its values merged with the default. Values that are different from the defaults will appear commented out above the current value.

Avast! Anti-Virus

smtpf provides support for Avast! anti-virus scanner. If you have avastd installed and chose to scan message content as it passes through smtpf, then specify the host:port of the avastd server with the avastd-socket option. Make sure that the avastd process owner, if running as something other than root, must be a member of the same group that smtpf is running as, else it will not be able to read any message files; see run-group.

When the avastd-socket is specified, all messages will be virus scanned, no exceptions possible. Those servers that use MailScanner may prefer to skip virus scanning in smtpf.

Also check the default settings for avastd-timeout option.

If a virus is found, then the default setting of avastd-policy is to reject the message, other choices being to discard the message or take no action (ignoring a virus infected message is a bad idea). If there is an I/O error between smtpf and avastd, probably caused by avastd being restarted, then the message is temporarily rejected and a legitimate SMTP client will retry later retry sending the message.

Cache

This family of options control cache management, such as where it lives, garbage collection, how long records should be kept, and whether it needs to be shared with one or more machines.

There are three general time-to-live options which control the maximum life span of a cache record. cache-accept-ttl is used for long term, typically positive, results, cache-reject-ttl is used for negative results, and cache-temp_fail-ttl for temporary failures. Unless otherwise specified for a particular test like Grey Listing or recipient Call-Aheads, the life span of cache records are extended every time they are consulted, so that active records can remain cached for long periods of time.

If you have more than one MX on the same local network segment then it is recommended you specify the same multicast IP group for all MXes with cache-multicast-ip, such as 232.0.0.1 or FF12::0001. As local cache records are added or modified, they are broadcast to this multicast IP group so that all smtpf listeners can be kept in sync in case an SMTP client later connects to one of the other MXes. This is particularly important for grey-listing in order to avoid unnecessary delays in mail delivery.

If you have more than one MX on different network segments or different subnets, then specify either a definitive domain that lists all those machines as MX servers with cache-unicast-domain or a list of host names and/or IP addresses with cache-unicast-hosts. Note these two options are mutually exclusive.

When using the cache-unicast-domain option, as local cache records are added or modified, they are broadcast to each MX server for the domain in turn. Note that unicast cache updates are less efficient than multicast and should only be used in instances where multicast is not ideal. Also note that a current limitation of the DNS client code does not support multihomed MX records nor truncated UDP packets, so be sure to review your MX setup and make adjustments accordingly.

Sometimes cache-unicast-domain is not convient to use, in which case cache-unicast-hosts is provided as a simpler way to specify hosts to which unicast cache packets should be sent. While cache-unicast-hosts is easier to use and setup, maintaining the list in sync across many machines could be more problematic than cache-unicast-domain and managing the DNS records for a single special (sub)domain. Note the list of unicast cache hosts is read once when smtpf is started, therefore changes to the list of hosts requires that smtpf be restarted.

When using multicast and/or unicast cache, all participating servers must specify the same shared cache-secret. Cache updates are broadcast as UDP datagrams in the clear, so in order to authenticate valid UDP packets and detect attempts at tampering, an MD5 signature is generated using this secret and the packet contents, then included in the packet sent. The receiver regenerates an MD5 signature based on what they received and compares the signature contained in the packet to see if they match.

Also note when using the multicast and/or unicast cache, that clocks on all participating systems must be in sync, otherwise unusual behaviour will result.

For information about manipulating the cache manually, please refer to the document about The Cache File.

Call-Backs

Call-backs are a form of sender address verification. The idea being to contact one of the sender's MX servers to validate if their server and mail address is known and in good standing. Accept or reject responses to the test are cached, while temp. fail responses are cached typically for a shorter time with call-back-temp-fail-ttl.

If a call-back succeeds and call-back-pass-grey is enabled, then grey-listing will be skipped to avoid any delays. However, with the enhanced grey-listing as implemented in smtpf, this is not recommended, since spam can forge the sender with a valid mail address expressly for this purpose passing the call-back and grey-listing.

Call-backs are a very unpopular technique with many large mail services. They are seen to consume their system resources and as an abuse vector for anonymous proxy dictionary attacks used in harvesting mail addresses. As a result, some services may chose to locally black list servers that they think are performing a dictionary attack, because there is no means to tell the difference from a call-back.

Call-backs as implemented in smtpf are delayed until the SMTP DATA command is issued and before the 354 go-ahead response is sent in order to allow as many passive pre-DATA tests the chance to reject the message. However, despite these best efforts to make call-backs less intrusive, they could result in your mail servers being black listed. Use with caution.

Clam Anti-Virus

smtpf provides support for the clamd open source anti-virus scanner. If you have clamd installed and chose to scan message content as it passes through smtpf, then specify a unix domain socket path or host:port of the clamd server with the clamd-socket option. Make sure that the clamd process owner, if running as something other than root, must be a member of the same group that smtpf is running as, else it will not be able to read any message files; see run-group. In addition, in the /etc/clamd.conf specify AllowSupplementaryGroups yes and restart clamd.

When the clamd-socket is specified, all messages will be virus scanned, no exceptions possible. Those servers that use MailScanner may prefer to skip virus scanning in smtpf.

Also be sure to check the default settings for clamd-timeout and clamd-max-size options.

If a virus is found, then the default setting of clamd-policy is to reject the message, other choices being to discard the message or take no action (ignoring a virus infected message is a bad idea). If there is an I/O error between smtpf and clamd, probably caused by clamd being restarted, then the message is temporarily rejected and a legitimate SMTP client will retry later retry sending the message.

Client IP Address

There are a group of tests that deal with the SMTP client IP address. The first, client-ptr-required, will reject the SMTP client if it does not have DNS PTR record.

The second, client-ip-in-ptr, takes the result of the PTR lookup and applies a heuristic that identifies if the client's PTR contains octets from the client's IPv4 address (IPv6 is currently ignored) as this tends to be a good indicator of an ISP customer connecting from dynamically assigned address space when they should be passing through the ISP approved outbound SMTP server.

The above two tests are very aggressive and can often lead to false positives when a legitimate ISP customer actually has a static IP address and/or no control over ISP assigned PTR name. It is not recommended to use them by themselves.

However, the client-is-mx option will temper the above two tests by delaying their application until the MAIL FROM: is supplied. If the sender address does not pass the SPF check and the client's IP address does not correspond to one of the MX records listed for the sender's domain, then the MAIL FROM: may be rejected and the connection dropped if either of client-ptr-required or client-ip-in-ptr failed.

Concurrent Connections & Connection Rate Controls

See the access-map concerning the Concurrent-Connect: and Rate-Connect: tags.

DNS Black, Grey, and White Lists

When specified the dns-bl is a space or comma separated list of DNS black list zone suffixes. For example:

dns-bl="sbl-xbl.spamhaus.org bl.spamcop.net"

When enabled, smtpf will check the SMTP client's IP address against each black list specified in the order given. If the black list returns a result indicating that client IP is a known source of spam, then the connection is dropped.

Occasionally a SMTP client takes a long time to send one or more messages through, possibly due to client CPU load and/or Internet traffic. During such connections the idle-retest-timer will occasionally reapply some tests like dns-bl. The idea being that the dns-bl maybe have received new information and updated their databases to include the connected client as a new spam source. When this happens the connection is dropped.

smtpf also supports two other forms of DNS based lists using the same syntax as dns-bl. They are dns-gl and dns-wl. The dns-wl option white lists an SMTP client through all the tests except anti-virus, dns-gl option will grey list an SMTP client through all the pre-DATA tests upto, but not including the content based filters (clamd, EMEW, spamd). The dns-wl is used when you have total confidence in the DNS based white list, while dns-gl is intended for use with DNS white lists when you might have less than 100% confidence in the list.

Delay Checks

Sendmail and Postfix MTAs have a concept called "delay-checks", which essentially allows for recipient white listing to override possible rejections that might occur due to policy tests early in the SMTP session.

When the smtp-delay-checks is enabled, all the policy based tests leading up to the recipients being specified are still performed, but any rejection or drop result is delayed and a "250 2.0.0 proceed" reply given. As each recipient address is specified, it is checked whether it is black or white listed, in which case the recipient is rejected or accepted (and subsequent tests by-passed). Recipient addresses that are neither black nor white will either be rejected if there is a previously delayed rejection/drop result or simply accepted.

Enhanced Message-ID as Email Watermark (EMEW)

EMEW provides a means to filter DSN and MDN backscatter caused when a spammer or virus impersonates a mail address of a local mail box. It will also auto-white list replies through content filters.

When a message without an EMEW passes through the mail server, the Message-Id header is modified with an encoded timestamp and one-way security hash generated from a timestamp, the original Message-ID, and the site specific emew-secret. For EMEW to work correctly all outbound and inbound mail servers must use the same secret, otherwise it is better to disable this facility.

When a recipient later replies, sends a mail delivery notice (MDN), or an error message (DSN) is sent back to our server, it will contain a reference to our enhanced Message-ID that will allow smtpf to verify if the reply is actually in response to a message that originated or transited our systems. If a DSN or MDN does not contain a reference to a valid EMEW then apply the emew-dsn-policy.

In order to reduce the risk for replay attacks, emew-ttl specifies how long an EMEW remains valid. If a stale EMEW appears in a DSN or MDN, then the message is rejected according to emew-dsn-policy. Otherwise if a stale EMEW appears in a recipient reply, then the message will be subjected to content filtering as normal.

Some mail architectures make it impossible or very difficult to deploy EMEW. For this reason an alternative facility is available to deal with backscatter, the Null-Rate-To: tag, which monitors the rate of mail from the null sender (MAIL FROM:<>) arrives and imposes a threshold. This threshold can be global or varied according to recipient domain or address.

F-Prot Anti-Virus

smtpf provides support for F-Prot anti-virus scanner. If you have fpscand installed and chose to scan message content as it passes through smtpf, then specify the host:port of the fpscand server with the fpscand-socket option. Make sure that the fpscand process owner, if running as something other than root, must be a member of the same group that smtpf is running as, else it will not be able to read any message files; see run-group.

When the fpscand-socket is specified, all messages will be virus scanned, no exceptions possible. Those servers that use MailScanner may prefer to skip virus scanning in smtpf.

Also check the default settings for fpscand-timeout option.

If a virus is found, then the default setting of fpscand-policy is to reject the message, other choices being to discard the message or take no action (ignoring a virus infected message is a bad idea). If there is an I/O error between smtpf and fpscand, probably caused by fpscand being restarted, then the message is temporarily rejected and a legitimate SMTP client will retry later retry sending the message.

Grey Listing

One of the more significant tests in smtpf is the enhanced grey-listing.

The original grey listing method keeps track of key sets consisting of the SMTP client's IP, sender's envelope, and recipient's envelope. If a key set does not exist in the cache, then a new record is added and kept until it expires and the message is temporarily rejected.

A legitimate server, when temporarily rejected, is expected to queue the message and retry sending it sometime in the near future. The temporary reject policy remains in force until the temporary block period (grey-temp-fail-period) has elapsed, at which point the message will be allowed to be delivered until the cache record expires.

Our enhanced grey-listing introduces some interesting optimisations. The first being that the grey-list key set is configurable with the grey-key option and that one of the configurable key set members can be the SMTP client's PTR information found from a DNS lookup.

One of the common problems with grey-listing is that some sending sites use a pool of mail servers with a shared mail queue (gmail.com is one such site). This has a negative impact on recipient sites using the original grey-listing { ip, sender, recipient } key set. The receiving site constantly sees a different IP address, but with the same sender and recipient. This results in the receiving site greylisting and delaying a message multiple times, and may result in a message not being delivered.

With the SMTP client's PTR information, we remove the first label from the PTR (note this is a generalisation of the process), then use this trimmed PTR as part of the grey-listing key set. If no PTR result was found, then the client's IP address is used as with the original grey-list method. The net effect of using the trimmed PTR in place of the IP address is that it grey-lists the sender's pool of mail servers instead of just a single machine.

For example, consider a sender site like:

out1.pool1.example.com	192.0.2.1
out2.pool1.example.com	192.0.2.2
out3.pool1.example.com	192.0.2.3
out4.pool1.example.com	192.0.2.4

Using the original grey-list key set, the first time the sending site connects, the receiver will record:

{ 192.0.2.3, fred@example.com, john@receiver.com }

and temporarily reject the mail. When the sending site retries, the receiver will likely see a different connecting IP address and record a new grey-list key:

{ 192.0.2.1, fred@example.com, john@receiver.com }

and temporarily reject the mail. This process can repeat itself for as many times as there are machines in the sending pool of servers, resulting in excessive mail delivery delays.

Using our optimisation, if the sender connects from IP address 192.0.2.3 which has a PTR of out3.pool1.example.com, then the receiver would use the trimmed PTR information to record the following grey-list key the first time the sender attempts to deliver the message:

{ pool1.example.com, fred@example.com, john@receiver.com }

and temporarily reject the message. The next time the sending site connects to the receiver, no matter from which machine within the same pool, the trimmed PTR information will match the previously cached record and result in the mail being passed through grey-listing.

The second optimisation concerns the objective of grey-listing as an anti-spam technique, which is essentially: does the remote mail server implement a retry queue? The assumption here being that spam sources do not bother with retry queues for speed. Many trivial grey-listing implementations record each and every unique { ip, sender, recipient } set, only allowing repeat visits from the same key set to passed without delay. However, once it is determined that a remote mail server implements a retry queue, new mail from the same host, but from different senders and/or to different recipients will result in additional and redundant grey-listing delays.

So in order to improve mail throughput, once a host or pool of hosts is known to implement a retry queue and if the grey-key specifies either the key set members IP or PTR, then we create a new cache record with a shortened key using only the IP or trimmed PTR information and allow all subsequent mail from that IP or trimmed PTR group to pass unhindered.

For example the first time an unknown SMTP client attempts to send a message, smtpf records:

{ pool1.example.com, fred@example.com, john@receiver.com }

When the sending site later retries to send the message, smtpf will find the above cached record and shorten that record key to be:

{ pool1.example.com }

Now when the sending site connects again in the future, smtpf will first look for the shortened key using either the SMTP client's trimmed PTR information or IP address and if it finds the record, passes the mail regardless of who the sender and recipients are, since we know that the hosts in question implement a retry mail queue. If the shortened key is not present, we look for the regular grey-list cache record and handle as before.

By default grey-key="ptr,mail,rcpt" takes advantage of both optimisations. The original grey-list method can be used by specifying grey-key="ip,mail,rcpt", though the second optimisation is still applied. To disable grey-listing specify an empty value grey-key="".

The grey-content option provides a variant on grey-listing. When an unknown key set is seen, a cache entry is created with the MD5 hash of the message content, and it is temporarily rejected. Subsequent attempts to deliver the message result in a temporary rejection until the grey-temp-fail-period has expired, at which point a MD5 hash of the message content is generated and compared with that previously saved within the cache. If the compared hashes are equal, then the message is allowed to proceed. Otherwise messages from this key set continue to be temporarily rejected until the originally message is seen once again.

The grey-content technique is effective against spamware that changes the content of their junk messages regularly in an effort to defeat Bayes analysis, distributed checksums, and/or simple pattern scanners. If the spammers do not change their text, then they will pass this test only to be caught most likely by something else like URI filtering or SpamAssassin.

SMTP HELO, EHLO Argument Testing

The first test applied verifies that the SMTP HELO argument contains only valid characters that can appear in a FQDN or IP-domain literal. An invalid character will reject the command and drop the connection.

The HELO argument is suppose to be a FQDN or it may be a IP-domain literal, which is technically not allowed by RFC 2821, but is a commonly accepted convention. The option rfc2821-strict-helo will reject and drop a connection, if the HELO argument is a bare unqualified name.

When reject-rfc2606 is enabled and the SMTP client is not one of our relays nor a RFC 3330 private LAN address, then smtpf with reject the command and drop the connection if the HELO argument is a reserved domain name as defined by RFC 2606 or similar such as .localdomain.

If helo-ip-mismatch is enabled and the HELO argument is an IP-domain-literal, then it must match that of the SMTP client IP address, otherwise the command is rejected and the connection dropped. RFC 3330 private LAN addresses are excluded.

Another interesting HELO test is helo-claims-us where the connected client is neither one of our relays nor a RFC 3330 private LAN address, yet specifies a HELO argument that claims to be from a domain we are responsible for, in which case the command is rejected and the connection dropped.

Finally if uri-bl-helo is enabled and uri-bl and/or uri-dns-bl are specified, then the HELO argument is tested against one or more URI black lists, rejecting the command and dropping the connection if true.

Interface Settings

smtpf defaults to connecting to both IPv6 and IPv4 interfaces on port 25 (see interfaces option). This can be configured to be a more restrictive list of hostnames or IP address if necessary in order to exclude some interfaces from the "bind to all" default. The canonical hostname for each interface will be looked up and used as the hostname in the welcome banner and for the HELO/EHLO argument when forwarding connections.

When specifying an IPv6 address with a port number, the address must appear within square brackets, [ and ], for example "[2001:DB8::1234]:25". Using an IPv4 address within the square brackets is also supported, eg. "[192.0.2.1]:25", in addition to the traditional IPv4 dot-colon notation, eg. "192.0.2.1:25".

Message Length & Limit Controls

See the access-map concerning the Length-*: and Msg-Limit-*: tags.

RFC Compliance Controls

There are many RFC documents that cover many aspects of the Internet. smtpf has several options that check for RFC conformance pertaining to mail.

Probably the most important set of RFC documents pertain to how mail travels using SMTP (RFC 2821) and the structure of mail messages (RFC 2822).

RFC 2821 documents several limits that SMTP servers must be able to support and that messages must not exceed, such as the maximum length of the parts that appear before (rfc2821-local-length) and after (rfc2821-domain-length) the at-sign (@) of an mail address, and the maximum length of a message line (rfc2821-line-length) can be. When enabled, these length related options will reject mail addresses or messages that exceed the documented limits.

While exceeding these lengths are often a sign of spam or mail born viruses, there are also some legitimate, yet badly written mail software throughout the Internet, that also exceed them. Therefore the above length controls should be used with caution as they could result in legitimate mail being rejected.

SMTP is a protocol that has a well defined grammar and syntax, particularly for specifying mail addresses as arguments to the MAIL FROM: and RCPT TO: commands. When rfc2821-angle-brackets is enabled, then mail addresses that don't adhere to this syntax are rejected.

Sendmail is a very popular MTA, that uses a plus-sign (+) in the local part before the at-sign (@) to delimit the mail box name from a folder or tag attributed by the mail box user. When rfc2821-literal-plus is disabled, then any plus-detail appearing in a mail address is removed before performing various access-map or route-map lookups. When enabled, the entire local-part is used unmodified.

The option rfc2821-strict-helo enforces the requirement that the HELO argument be a FQDN, ie. has two or more labels or is an IP-domain-literal. Anything else would be rejected.

The end of the DATA state and message transfer is suppose to be denoted by a CRLF-DOT-CRLF sequence, ie. a line consisting only of a single period. Enabling rfc2821-strict-dot option enforces this, since accepting other newline dot combinations could inadvertently terminate the message transfer early and subsequent unknown command errors. When disabled, other newline combinations are accepted, such as LF-DOT-LF, CRLF-DOT-LF, and LF-DOT-CRLF. Unfortunately, while typically a sign of spam software, there are some badly written mail applications that are careless in their handling of newlines and the final dot.

Mail messages, in particular the headers, are not suppose to contain unencoded 8-bit data, since how those values are interpreted when scanned can vary based on regional language and they can cause legacy mail systems to fail. With rfc2822-7bit-headers set, if the message headers are not 7-bit ASCII printable, then the message is rejected.

There are several domains, as described by RFC 2606, reserved for documentation and special local uses. They are the top level domains .test, .example, .invalid, .localhost, and the second level domain .example using any TLD. These domains should never appear in domain names from the public Internet. If rfc2606-special-domains is enabled, then various tests are applied at different stages to the SMTP client name, HELO argument, sender and recipients. The appearance of a reserved domain will cause a rejection, unless the SMTP client is from the LAN or a relay. While not part of RFC 2606, .localdomain and .local are also included in the restricted list.

Run Settings

smtpf is normally started by the root user in order to bind to SMTP port 25, set its working directory to run-work-dir, create its run-pid-file, and switch to a chroot jail if run-jailed is set. Once initialised, the smtpf process drops root privileges and becomes the user and group specified by run-user and run-group respectively.

The run-open-file-limit is used to specify the maximum number of open files for the smtpf process. When approximately half this number is reached, smtpf will start to refuse SMTP connections on the assumption that each SMTP client needs at least two file descriptors in order to process the session.

Server Performance

The server connection handling uses a collection of pre-spawned server threads that are reusable and grow or shrink as load varies. This server design reduces the effect of constantly creating and destroying threads by maintaining an active pool of waiting threads.

server-min-threads sets the lower bound on the number of server threads to keep in circulation. server-new-threads specifies the number of new servers threads to create when there a no available server threads to handle new connections. The smtp-accept-timeout option specifies how long a server thread will wait for a new connection before it times out and is possibly terminated.

SMTP Settings

When smtpf binds to SMTP port 25, it can only accept one connection at a time, while the kernel queues any other connections that arrive. The smtp-server-queue value is used to tell the kernel how many connections it should be prepared to handle before refusing clients.

When an SMTP client connects, it is supposed to wait for the SMTP 220 response and welcome message. Some spam software will often assume that the ESMTP pipelining is used and simply blast out one or more message transactions, ignoring any responses from the server. One or more GreetPause: tags, which specify a delay in milliseconds, can be added to the access-map. If the client sends any data before this delay expires, then the connection will be dropped.

An SMTP client that successfully connects is sent a 220 status code along with the SMTP server host name and a welcome message. smtp-welcome-file can be used to supply a custom welcome message and it is the file path to a file containing one or more lines of text. The 220 status code will be automatically prepended to each line. It is recommended that this message be two or more lines as this has been found to foil some spam software that fail to handle multiline responses. If an empty string is given, a hard coded default is used.

The CommandPause: tag used in the access-map is similar in principal to GreetPause:. It specifies the number of milliseconds to pause before processing a SMTP command. If more input arrives before the delay passes then the command is rejected and the connection dropped. If a CommandPause: lookup returns a value of zero (0), then smtpf will allow RFC 2920 SMTP Pipelining after a successful EHLO command.

It is possible to drop a client connection after a certain number of unsuccessful SMTP commands with smtp-drop-after.

The smtp-drop-unknown can be used to reject and drop a connection that issues an unknown SMTP command. This option should be used with care, because it has been seen that Cisco Pix firewalls with SMTP filtering enabled, will for some silly reason obfuscate an EHLO command and thus trigger this test. Use with caution.

smtpf provides a very simple form of tar pitting when smtp-reject-delay is set. For any negative SMTP responses, exponentially delay sending the responses to the client. After several temporary failures or rejects, the client connection will timeout and be dropped. Particularly interesting in combating dictionary harvesting attacks.

The smtp-connect-timeout in seconds is used when smtpf attempts to make a connection to a FORWARD: host. While the smtp-command-timeout in seconds controls how long smtpf will wait for the next client command or server response. Finally the smtp-data-line-timeout in seconds controls how long to wait for the next message line from the client. If a client takes too long, the connection will be dropped.

The smtp-enable-esmtp option when disabled causes some badly written spam software that fails to fall-back to regular SMTP to disconnect or become out-of-sync (see the ehlo-no-helo counter). Regular mail software is unaffected and falls-back correctly. Other spam software will send an EHLO and when the command is rejected, send a HELO, but using a different host/domain argument to the EHLO that was previously sent; smtpf will reject and drop these connections (see the helo-schizophrenic counter).

Spamd Support

smtpf provides support for SpamAssassin the open source message content scanner. If you have spamd installed and chose to scan message content as it passes through smtpf, then specify a unix domain socket path or host:port of the spamd server with the spamd-socket option.

Also be sure to check the default settings for spamd-timeout and spamd-max-size options.

When scanning message content with spamd, the default spamd-command is to simply CHECK and report the score and a yes/no answer. The other commands possible are SYMBOLS, REPORT, and REPORT_IFSPAM, which provide more detailed logging if the verbose spamd flag is set.

As of smtpf 2.0 it is now possible to tag the Subject: header with a custom prefix given by spamd-subject-tag. The Subject: tag is applied when the score returned by SpamAssassin is greater than or equal to the required_score defined in the SpamAssassin configuration and less than the value given by spamd-score-reject.

In addition X-Spam-Flag, X-Spam-Status, X-Spam-Level, and X-Spam-Report headers may be added depending on the result. The X-Spam-Report varies depending on the spamd-command applied.

Some sending sites include X-Spam-Flag: YES and/or X-Spam-Status headers that indicate that they already thought the message was spam. In such case when the X-Spam-Status score exceeds our spamd-score-reject, we reject the message. Or if there is only a X-Spam-Flag header that states YES (regardless of case), then we reject the message. Otherwise we discard previous X-Spam-* headers and content filtering proceeds as per usual.

It is possible to specify a specific SpamAssassin configuration file to use through the use of spamd: tag. If the message is addressed to a single recipient, then a Spamd:mail lookup is done. If the message is for more than one recipient, all of whom are within the same domain, then a Spamd:domain lookup is done. Otherwise the Spamd: default configuration is used. The right hand side must be a user name or address to pass to spamd. It can be a pattern list. If the special user name OK is used, then the message is not processed by spamd.

SPF Classic Support

SPF Classic is a means by which a domain documents, using DNS TXT records, all the valid sources of mail. SPF is an interesting idea, but is considered experimental by the IETF. SPF checks use the SMTP client's IP address, the HELO argument, and MAIL FROM: domain to determine whether a message is coming from an acceptable mail source. The spf-helo-policy and spf-mail-policy options can be set to reject messages that result in hard and/or soft failures.

Many mail systems have no SPF record or have syntax errors, so when there is no SPF pass result from the SPF check, the spf-best-guess-txt option can perform a second SPF using the supplied string (for example "v=spf1 a/24 mx/24 ptr") to see if that would yield a pass result. Otherwise the result of the first SPF check is retained.

The enhanced grey-listing and client-is-mx options will take the SPF results into account. When spf-received-spf-headers is set, then Received-SPF headers detailing the results will be added to a message's headers.

Statistics

smtpf can gather assorted statistics, such as the number of connections, how many were intentionally dropped, number of lost client connections, how many times a particular test fires, etc. The majority of the counters are grouped by category: CLIENTS, SENDERS, RECIPIENTS, and MESSAGES. The percentages are computed by dividing a counter by the counter of the category it appears in. Note that multiple statistics counters can be incremented during the lifetime of the SMTP connection.

By default the stats-map is disabled. When enabling statistics, the SQLite database is the recommended format. Also note that it becomes the responsibility of the statistics gathering software to age and remove old statistics from the stats-map as it will grow over time.

The stats-map consists of key-value pairs where the key is given by a string of digits indicating the current hour according to "YYYYMMDDHH". The value is a space separated list of hex values. The special key "fields:$VERSION", where $VERSION is the smtpf version number. The fields key is used to obtain the field names and the order they are saved in, since this can change between versions of smtpf.

It is possible to observe the raw statistics while smtpf is running. See the SMTP STAT extension.

URI Black Listing

URI can appear in the headers and content of a message. They typically take the form of email addresses, machine host names, and web page links. When the uri-bl and/or uri-dns-bl are specified, smtpf will parse and MIME decode a message looking for URI and check the domain portion against one or more DNS based URI black list services. When a black listed URI is found, the uri-bl-policy is then applied at the end of the message.

By enabling uri-sub-domains it is possible to check sub-domains against all the URI black lists servers specified by uri-bl and/or uri-dns-bl. Note though that most URI black lists currently only list the top level domains, therefore enabling this option will generate more DNS traffic with little result.

Sometimes spammers will use the same domain that appears in their spam content for the their host name or as the domain that appears in either the HELO or MAIL FROM: arguments and so it is sometimes possible to catch spam early in the SMTP transaction. By enabling uri-bl-ptr, uri-bl-helo, or uri-bl-mail options the SMTP client host name, HELO argument, or MAIL FROM: arguments repectively are checked against the URI black list services given by uri-bl and/or uri-dns-bl.

Some messages, be them spam or HTML formatted news letters for example, will include a lot of URI throughout. The uri-max-test option will limit the number of unique URI domains that are checked in order to avoid possible denial of service situations from looking up too many URI, while the uri-max-limit counts how many URI are present and if over a given threshold a message would be rejected.

Some spam messages intentionally add broken or circular web page links. By specifying a uri-links-policy other than none, each web link will be tested using an HTTP HEAD request to see if a link is broken or generates a circular loop of HTTP redirects. If true the selected policy is applied. The http-timeout option specifies how long to wait in seconds before giving up testing a link.

Verbose Logging

smtpf is capable of logging a lot of detail about the software's behaviour, SMTP transaction details concerning the SMTP client and FORWARD: hosts, and actions of various options to the system's mail log. The extra logging can aid in finding software and/or configuration issues. However, in day to day operations verbose='error,info' is typically sufficient. Note too that the logging level can be adjusted at runtime without having to restart the server. See the SMTP VERB extension.

- TOP -

Copyright 2006, 2008 by SnertSoft. All rights reserved.
BarricadeMX trademark & patents pending.