SPAMCONTROL is an extension mainly for qmail-smtpd. It provides the following features:
ESMTP enhancements
SMTP envelope Anti-Spam-Tools
Recipients extensions
Bounce control
Virus prevention
qmail-smtpd logging
With SPAMCONTROL, Qmail can stand the two most common threats:
Throughout this document, I assume that qmail-smtpd is under control of supervise (out of the Daemontools package) and served by tcpserver (part of the UCSPI package).
A typical - minimal - so called run script looks like follows:
Qmail - and SPAMCONTROL - relies on the concept of environment variables which are available for a task (sharing the same environment). qmail-smtpd may be fed by environment variables in three different fashions:
While the first two cases define static and "global" environments variables, the last case makes the environment variables client-dependent and - by means of tcprules - dynamically changeable.
Caution: Only the "last" setting of an environment variable is effective!
As a convention, I will call the tcperver's cdb, which rules the behavior of qmail-smtpd, tcp.smtp. A typical tcp.smtp would look like
The cdb is constructed on the fly:
Caution: For use with tcpserver, the value of the environment variable has to be included in quotes.
Though qmail can live happily without the knowledge of domains to be responsible for as provided by rcpthosts/morercpthosts.cdb, it is highly adviceable to include all domains to receive emails for (as per DNS MX Records) into those control files. Otherwise, qmail-smtpd may act as an Open Relay. Further, some LOCALMFCHECKs will fail, as discussed below.
The SMTP Envelope consists of three parts:
SPAMCONTROL allows to filter E-Mails according to the bad* criteria with a so-called wildmat search.
According to RFC 821, SMTP implementations must obey the case and according to RFC 2821 envelope addresses must be enclosed in brackets!
Any E-Mail address, lets say <user@host.domain.com> consists of a
E-Mail addresses for local accounts are considered case-insensitive and delivered irrespective of their case.
Lets say - if the local account is "admin" and the RCPT to: tells <AdMin> or <adMIN> the delivery will be successful.
With SPAMCONTROL 2.1 the control/badmailfrom and control/badmailpatterns as well as control/badrcptto and control/badrcptbatterns control files have been functionally merged. Thus
is facilitated. The wildmat search works in order least significant to most significant.
SPAMCONTROL allows you to employ three additional filter files:
| Control file | Meaning | Syntax | Dependencies | Behavior (see 1.9) |
| badmailfrom | Mail From: <Sender> filter |
sender@baddomain.com * |
1. SMTP error message issued. - and/or - 2. Close after receipt of Rcpt To: address |
|
| badrcptto | Just like badmailfrom filters on the base of the Rcpt To: <Recipient> envelope sender |
recipient@localdomain.com; @localdomain.com * |
1. SMTP error message issued. - and/or - 2. Close after receipt of Rcpt To: address |
|
| badhelo | Filtering of HELO/EHLO sequence issued by SMTP client | blabla *spam* 192.168.0.1 |
1. SMTP error message issued. - and/or - 2. Close after receipt of Rcpt To: address |
Wildmat control characters:
Qmail records the HELO/EHLO greeting string for every received message in the E-Mail "Received:" header in case the provided HELO/EHLO string is different from the connecting hosts FQDN:
The HELO/EHLO string is included as "(HELO foo)". The HELO/EHLO string is usually generated by the sending MTA without much control (MUAs often use their generic hostname).
You may want to filter particular sending MTAs by means of their HELO/EHLO string, including those into
Due to discussions with Sven Paas (Sven.Paas@t-online.de) I introduced a "split horizon" evaluation of the badmailfrom control file.What does this mean?
The SPAMCONTROL Patch includes the MFDNSCHECK Patch with some enhancements. Thus, qmail-smtpd performs a DNS MX lookup for host/domain part of the Sender address of any incoming E-Mail (based on the addresses in the E-Mail's envelope). Results:
Invoking the environment variable MFDNSCHECK in the qmail-smtpd startup script enables globally the DNS check for the envelope's Sender.
Example:
Additionally, the environment variable may be defined individually within a cdb of tcpserver. Typically, this is done for "non-trusted" hosts within a tcpservers cdb:
If environment variable MFDNSCHECK is not set, qmail-smtpd does not perform this DNS MX check.
RFC 2821 says: "These commands (HELO/EHLO) are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. y The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command."
SPAMCONTROL 2.3 allows a flexible checking of the HELO/EHLO greeting string, depending on the setting of the environment variable HELOCHECK:
Some MUAs add trailing blanks to the Recipient name: "Mail From: <Return-Path >". While this wrong spelling is irrelevant for the receipt of the E-Mail and perhaps any bounces (the information in the E-Mail Header will be used instead), DNS MX lookups will fail and the mail erroneously rejected. By default, SPAMCONTROL removes the trailing blanks just in case of DNS MX lookups. This behavior is controlled via a compile-time option (see below).
Let's assume your MTA's FQDN is mta.domain.com and has IP address "12.34.56.78".
The inverse DNS name becomes "78.56.34.12.in-addr.arpa".
As already mentioned, the badmailfrom is analyzed in a straight/flat and a least significant to most significant order.
| control/FILE | expression | meaning |
| badmailfrom | @12.34.56.78 | avoid abuse of your IP address |
| badmailfrom | *12.34.56.78* | avoid abuse of your IP address |
| badmailfrom | *\ @* | reject addresses with white spaces in local part |
| badmailfrom | !*@*.* | require full qualified sender address |
| badmailfrom | *12.34.56.78* | avoid abuse of your IP address |
| badmailfrom | *78.56.34.12.in-addr.arpa* | avoid abuse of your inverse IP address |
| badmailfrom | !*@*.* | require full qualified sender address |
| badhelo | 12.34.56.78 | reject, if obvious spoofed HELO/EHLO |
| badhelo | mta.domain.com localhost localhost.localdomain 12.34.56.78 |
reject, if obvious spoofed HELO/EHLO |
RFC 2821 requires from the SMTP Server to continue the SMTP session even after having issued a reply carrying an error message: "An SMTP server MUST NOT intentionally close the connection". It's a pre-compile option of SPAMCONTROL to change that into a close of the session:
Since version 2.0.7 SPAMCONTROL includes a check and enforcement of the Sender's Mail From: <Sender> address (in SMTP language that is the Return-Path), setting the environment variable LOCALMFCHECK. This feature may be called a "Reverse Split Horizon" check. Though it seems at a first glance absurd to check for the Mail From: of a RELAYCLIENT, lets discuss three scenarios:
The LOCALMFCHECK can be used in the following ways:
Any mixture is possible.
I have included Chris Johnson's TARPITTING patch into SPAMCONTROL:
"What is tarpitting? It's the practice of inserting a small sleep in a SMTP session for each "Rcpt To:" after some set number of "Rcpt To:"s. The idea is to that spammers who would hand your SMTP server a single message with a long list of RCPT TOs. If a spammer were to attempt to use your server to relay a message, say, 10,000 Recipients, and you inserted a five-second delay for each Recipient after the fiftieth, the spammer would be 'tarpitted', and would most likely assume that the connection had stalled and give up."
Two additional control files can be employed:
is the number of "Rcpt To:"s to accept before starting tarpitting and defaults to 0 (no tarpitting).
is the number of seconds of delay to introduce after each subsequent "Rcpt To:". Default is 5 seconds.
Instead, the environment variables TARPITCOUNT and TARPITDELAY can be used.
Note: In combination with the Recipients extension, the TARPITCOUNT is used to terminate the SMTP session if the number of invalid Recipients ("Rcpt to:") exceeds the TARPITCOUNT. Unlike the typical tarpitting mechanism, this is a hard limit (Smart Rejection).
qmail-smtpd accepts messages if the SMTP domain part of Recipient address ("Rcpt to: <recip@domain>") matches an entry in control/rcpthosts or control/morercpthosts.cdb. The existence of a mailbox/maildir for the corresponding SMTP Recipient is checked later in the delivery chain. In case no Mailbox/Maildir exists, the message is bounced back to the SMTP Sender ("Mail From: <send@example.com>").
For normal SMTP mail traffic that's fine as long as the rate of undeliverable messages don't exceed 10% and the Sender is 'legitmate'; ie. exists. Today's situation is different: Spam and Virus attacks with forged/faked Sender addresses to a bunch of random Recipient addresses yield an undeliverable rate up to 90%. Worse, the generated bounces will never reach the Sender and a double-bounce is eventually send to the postmaster.
The Recipients extension makes qmail-smtpd aware of acceptable Recipients and is employed in a none-RELAYCLIENT case only. The Recipients are kept in 'fastforward' compatible cdbs for a case-insensitive quick lookup during the SMTP session.
The Recipients mechanism supports Qmail's address extensions. If a Recipient address like 'foo@mydomain.com' is included in a cdb, all VERP addresses like 'foo-bar@mydomain.com' are accepted for SMTP reception.
Within the Recipients mechanism you can define domain-wide wildlisting. Simply include '!@domain' into one of the cdbs to allow all addresses for domain "domain" to be accepted. For performance reasons it is advisable to put those "wilddomains" at the beginning of the first cdb.
Unqualified Recipient addresses are always translated to full qualified, appending the domain part '@localhost' (eg. 'foo' -> 'foo@localhost').
The qmail-smtpd Recipients extension is available by means of the control file
Here, you include the path to fastforward compatible cdbs in which you keep the Recipient addresses (in lower case).
- control/wilddomains.cdb
- users/recipients.cdb
etc/fastforward.cdb
With the Recipients extension qmail-smtpd will act for none-RELAYCLIENTs like follows
In any other case, a SMTP temporary failure protocol error is issued to the client saying:
The Recipients extension needs no customization except for the following circumstances:
Alternatively to the Recipients mechanism, as a side-effect of the wildmat filtering, you can use the badrcptto file as an effective whitelisting mechanism. The trick is, to initially reject everything while later to allow specific Recipients:
*
!*@otherdomain.com
!user1@maydomain.com
!user2@mydoamain.con
Note: The evaluation of control/badrcptto is done independent from the setting of the RELAYCLIENT environment variable.
The environment variable
can be used to restrict the number of counted "Rcpt To: "s in the SMTP session. By default, no restriction is facilitated.
Based on the "qmail-smtp-viruscan-1.1.patch" by Russell Nelson (and Charles Cazabon), SPAMCONTROL includes my WARLORD extension, which is a much robuster and efficient filter for BASE64 encoded MIME attachments and bundled with the Qmail High Performance Scanner Interface (QHPSI):
In case a badmimetype or badloadertype filter condition is met or a virus is detected, qmail-smtpd sends a SMTP 554 reply to the sender "554 sorry, invalid message content (#5.3.2)". Populating the REPLY554 environment variable, allows to include additional information (typically an URL), which can be used to deal with potential false-positives.
The badmimetype filter becomes active if
The control file badmimetypes.cdb is populated by the additional program qmail-badmimetypes which takes the input of badmimetypes. New MIME signatures can be added/removed on-the-fly. Bad MIME Type signatures have to have the length of at least 9 significant characters.
The currently included MIME signatures are:
Adding new badmimetypes is simple:
Comments (starting with "#") are allowed in badmimetypes; the length of the signature will be truncated to nine characters.
The badloadertype filter becomes active if
The BADLOADERTYPE mechanism deals in particular with "transport stealth" worms, ie. UPX encoded Windows executables.
badloadertypes.cdb is populated by the additional program qmail-badloadertypes which takes the input of badloadertypes The badloadertype mechanism looks for five significant strings in the BASE64 encoded data-stream which is matched against an entry in badloadertypes.cdb. badloadertype signatures can be added/removed on-the-fly.
The currently included Windows OS badloadertype signatures are:
Comments (starting with "#") are allowed in badloadertypes; the length of the signature will be truncated to five characters.
Caution: Unlike the badmimetype, the badloadertype signatures are placed anywhere in the BASE64 encoded datastream and are difficult to find out. In order to make the search efficient, a common character has to be providen in the environment variable BADLOADERTYPE. The provided pattern look basically for a string like "32.dll" as a subpart of "Kernel32.dll" which is an indication for an executable for the Windows OS. However, there is a small chance for false positives. Some - lets say - Word document attached as BASE64 MIME part in the message containing the buzz words "kernel32.dll" might become flagged and finally rejected as well.
Unlike all other AV Scanners currently in use for Qmail, with Qmail High Performance Scanner Interface (QHPSI) there is no need for any other umbrella program, neither qmail-scanner, AMAViS, qscanq or whatsoever. Further, no additional MIME analyzing program like reformime, metamail, or ripmime is required. Even better, no "staging" area for temporary files are needed, except the one, the AV Scanners requires for itself.
Today's AV Scanners - and in particular Clam AV - are able to read the BASE64 encoded message and eventually dig out the files in archives, ie. in zip format. In order to use an AV Scanner with QHPSI, the AV Scanner has to have the following qualifications:
The QHPSI allows to use the following environment variables:
The AV Scanner is directly called in the start scripts of Qmail (i.e. the run script for qmail-smtpd) or by means of tcpserver's capabilities. Here is a typical example, how to customize QHPSI together with Clam AV (clamd/clamdscan) for a tcpserver tcp.smtpd file:
Comments:
Note:
Results:
Here is a sample of Clam AV without and with the argument "--disable-summary":
Note: Even in case no virus is detected, the "SCAN SUMMARY" is provided.
Attention:
The badmimtypes and badloadertypes mechanism provides a wire-speed filtering of incoming emails. However, typically all not-filtered emails are subject of the AV Scannner as defined via the QHPSI. Almost all worms and virii are transported as BASE64 encoded attachments (except some trojans, encapsulated as HTML files). By means of the environment variable
one can advice QHPSI to scan only those emails which contain a BASE64 encoded attachment.
qmail-smtpd will send a SMTP 554 Error Reply under the following conditions:
The SMTP Reply code for the first three conditions is always "554 sorry, invalid message content (#5.3.2)". The rejection of email because of the message content is due to some internal policy. For those users, which a subject of this policy innocently (and did not send ie. a virus mail on purpose), it might be advisable to explain the company's email policy.
The environment variable
allows to include a particular SMTP 554 Reply. Typically, an URL is referenced: REPLY554="[ see: http://www.fehcom.de/emailpolicy.html ]" which allows to detail possible circumventions.
Bounces have generally a Null-Sender address (Mail From: <>) and are out-of-band error-messages to indicate a failure in the delivery process. In fact, RFC 2821/821 requires that all notification E-Mails have to have a Null-Sender address!
For every undeliverable message, qmail-send generates a bounce to the Sender.While this is legitimate and necessary for normal operation, in case of SPAM attacks the bounces are meaningless:
Unless you use a 'whitelisting' of Recipient E-Mail addresses, there is not much to do about. However, SPAMCONTORL helps you in three cases:
By construction, even if multiple Recipients specified, qmail-remote/qmail-local will send individual E-Mails to those Recipients. Thus, if any (or a set) of the Recipients is invalid or not reachable (and delivery errors are not already handled by other SMTP protocol means) qmail-send generates an individual bounce E-Mail to the remote Sender address (according to the "Return-Path" in the E-Mail header).
Thus, any legitimate Null-Sender Mails have to have a single Recipient. Charles Cazabon has first pointed out this issue and patched qmail-smtpd accordingly.
By definition, a bounce is a SMTP notification for a failure situation. It is common practice, to include the original message in the bounce. Qmail uses a specific format, introduced by Dan Bernstein and called "QSBMF" (qmail-send Bounce Message Format); other MTA encapsulate the original message as MIME attachment in rfc822/message format.
Anyway, for a legitimate bounce reaching the Sender the original message is usually of no interest, except for identification purposes. In order to save bandwidth, you can limit the size of bounces using the control file
Unlike the original patch (from Frank DENIS aka Jedi/Sector One <j@4u.net>), the default value is '0' byte, meaning no limits. A useful limit would by 2000 (byte), which covers the header and some body part information. The average size of a SPAM E-Mail is 5 Kbyte.
The original message included in the bounce will be limited to the defined bouncemaxbytes and truncated, which is displayed in the bounce with "--- Rest of message truncated." at the end of the bounce.
Double bounces are generated, if the bounce can not be delivered to the Sender.
Double bounces are usually delivered to the 'Postmaster' account. It is convenient that this account is local and eventual double bounces are stored in a mbox/Maildir for later inspection. However, Qmail allows you to forward double bounces to some other account defined in
However, due to the forged Sender address in SPAM E-Mails, practically all bounces become double bounces eventually. In this case any storage and inspection is fruitless. Taken from Russell Nelson and Charles Cazabon, you can optionally dump all double bounces immediately. This is facilitated if doublebounceto contains a '@' in the first line.
Those dumped double bounces show up in the qmail-send log as: "double bounce: discarding".
SMTP Authentication is discussed in RFC 2554. Other relevant RFCs are
SMTP Authentication requires a Client to authenticate and a Server to honor the authentication procedure. In this version of SPAMCONTROL, Qmail acts as an Authentication Server for qmail-smtpd and as an Authentication Client for qmail-remote.
SMTP Authentication somehow violates the principles of the SMTP protocol: Originally invented as a Host-to-Host protocol, with SMTP Authentication a User has identify himself and after successful authentication is granted transmission of his/her E-Mails.
Usually, a MTA (such as Qmail) will accept transmissions of E-Mails anyway as long as the "RCPT To: <forwarding-path>" is targeted to a local Recipient (according to control/rcpthosts). However, with SMTP Authentication you may allow an authenticated User to relay E-Mails. In this respect, SMTP Authentication copes with the deficiencies of the POP3/IMAP4 protocol and is applied as an alternative to SMTP-after-POP, which is ugly as well.
I have taken the SMTP-Auth Patch from Krzysztof Dabrowski and included this into SPAMCONTROL. However, SPAMCONTROL's implementation is compliant with the checkpassword API designed by Dan Bernstein (the Plugable Authentication Module PAM).
SPAMCONTROL provides the following features:
While SASL is a generic concept, the information flow for authentication between e.g. qmail-smtpd and the PAM is defined by Dan Bernstein's checkpassword API. SPAMCONTROL provides the PAM on file descriptor 3 as an informational string composed of:
You are free to choose or even write your own PAM program, but in any case, the SASL Procedure of the client and the server has to match and the procedure has to be advertised. Compliant PAMs:
Beware! Unlike the original implementation, I omitted the inclusion of the Hostname as argument for qmail-smtpd.
qmail-smtpd including SMTP Authentication may be called by INETD/XINETD or even better via tcpserver in a supervise run script. Here is an example (with some more features):
Unlike the standard qmail-smtpd, now you have to provide in addition a PAM program, here cmd5checkpw, which itself calls a shell named 'true' (/bin/true or /usr/bin/true) exiting simply with "0".
For SMTP Authentication, a User Database has to be generated and maintained. The SMTP Authentication SASL User may exist independently of any System Users, Qmail Users, or E-Mail Accounts. In case of the modified cmd5checkpw I decided to keep the SASL User in the Qmail directory as
There exist other flavors, in particular the saslpasswd scheme or the Cyrus SASL Library you may want to use. Further, for users with POP3/IMAP4 Accounts on the system it is advisable to use a common User Database. For Vpopmail you may use vchkpw.
Compiling SPAMCONTROL with the 'reqauth=yes' option, you may enforce SMTP Authentication based on the setting of the environment variable REQUIREAUTH. A typical run script to require SMTP Authentication for local SMTP clients looks like:
SMTP Authentication works well with vpopmail, however, you have to use a checkpassword compatible PAM. Older versions of vchkpw have to be patched accordingly (see http://www.fehcom.de/qmail/smtpauth.html).
vchpkw offers a lot of authentication capabilities; it supports login, plain, and CRAM-MD5 and may authenticate the user against a mysql database and others. In start-up script for qmail-smtpd you have to make sure to access the user database with the correct user access rights:
If you use Sqwebmail in addition, the user is free to set his own password.
The qmail-remote (qmail-smtp-auth-send) authentication from Bjoern Kalkbrenner has been included in a modular and RFC-complient version. qmail-remote sessions can be SMTP authenticated with the types PLAIN and LOGIN on a per-sender (Reverse-Path) base. Thus for each sender you can advice qmail-remote to use SMTP authentication with a particular username and password connecting to relay at port.
The qmail-remote authentication follows in this respect the smtproutes mechanism. Authentication for outgoing SMTP sessions is faciliated if the control file
is populated accordingly. Sample:
Scott Gifford's "ipme.c" patch (or qmail-0.0.0.0-patch) is included by default. According to RFC 1122, Sec. 3.2.1.3 the IP address "0.0.0.0" is a special address which always refers to "this host, this network". You may wish to tell Qmail about arbitrary IP addresses employing the moreipme patch and include the following control files:
See the enhanced man page qmail-smtpd and or consult the README.moreipme.
qmail-smtpd's "Mail From:" parameter parser is used to detect and evaluate the SIZE parameter and to eventually reject messages which initially exceed the databytes limit.
Nevertheless, qmail-smtpd checks the size of the incoming message anyway.
For incoming E-Mails which exceed the message size values (in Bytes) defined in
or via the $DATABYTES environment variable.
I included the following "recommended" patches into SPAMCONTROL:
Usually, qmail-smtpd is gentle enough, to accept 'bare' addresses in the SMTP dialogue. However, RFC 2821 requires any SMTP addresses to be enclosed in brackets: <foo.bar@mydomain.com>. With the compile time option 'reqbrackets=yes' you enforce correctly bra'ket-ed SMTP addresses; otherwise a "555 syntax error (#5.5.4)" is issued by qmail-smtpd.
Bruce Guenter's Qmail QUEUE_EXTRA patch has almost the rank of a recommended patch, because it's used by many Qmail extensions like the Qmail-Scanner. The compile time option "queue_extra=yes" enables the optional use of a Qmail qmail-queue replacement.
The actual use is controlled via the content of environment variable "QMAILQUEUE", which usually set in a tcpserver's cdb ie. tcp.smtp or globally defined in the qmail-smtpd's run script.
The queue directories ./intd and ./todo may be splitted (as per conf-split) into subdirectories to allow a more efficient treatment of many incoming messages.
Caution: Make sure, that the directories ./queue/todo and ./queue/intd are empty before applying the patch; otherwise qmail-send will not be able to process those messages anymore!
Note: The shell script qmail-qstat and in addition some qmail-mrtg analyses are affected by this patch.
Hint: Consider raising the value in conf-split in the first place !
As a further gadget, the qmail-send control files
are re-read by means of a HUP signal (eg. svc -h /service/qmail-send).
The following fixes for Qmail's sendmail wrapper have been included for compatibility reasons:
SMTP allows to reject Sessions based on some technical and/or political criteria, which are not well expressed in the RFCs (2821, 2554, 2505, 1122).
The SMTP protocol mechanism between the client and the server are defined as Commands and Replies. SMTP uses a three-letter Reply Code. The first digit tells whether a command was accepted and completed (2), transaction begin (3), or whether there was as transient (4) or permanent failure (5). In addition, an explanatory description may be given.
RFC 1893 introduces a concept of "Enhanced Mail System Status Codes" (EMSSC) which should provide easily parseable SMTP server conditions and transaction statuses, usually at the end of the SMTP reply and included in parenthesis, eg. (#5.5.1).
The SMTP Reply Codes and the EMSSC are detailed in the corresponding RFCs, but don't fit well to each other, thus either providing redundant information or almost no additional information at all. In short, the EMSSC is nowadays almost meaningless.
Here's a breakdown of SPAMCONTROL's SMTP Reply Codes, informational texts, and the used EMSSC.
Reply |
Informational text |
EMSSC |
| 450 | sorry, mailbox currently unavailable | (#4.2.1) |
| 501 | auth exchange canceled | (#5.0.0) |
| 501 | malformed auth input | (#5.5.4) |
| 503 | you're already authenticated | (#5.5.0) |
| 503 | no auth during mail transaction | (#5.5.0) |
| 503 | sorry, SMTP Authentication not available | (#5.7.3) |
| 504 | auth type unimplemented | (#5.5.1) |
| 535 | authorization failed | (#5.7.1) |
| 550 | sorry, invalid HELO/EHLO greeting | (#5.7.1) |
| 550 | sorry, your envelope recipient is in my badrcptto list | (#5.7.1) |
| 550 | sorry, invalid sender address specified | (#5.7.1) |
| 550 | sorry, too many recipients | (#5.5.3) |
| 550 | sorry, bounce messages should have a single envelope recipient | (#5.7.1) |
| 552 | sorry, that message size exceeds my databytes limit | (#5.3.4) |
| 553 | sorry, your envelope sender is in my badmailfrom list | (#5.7.1) |
| 550 | sorry, that domain isn't in my list of allowed rcpthosts | (#5.7.1) |
| 553 | sorry, your envelope sender domain must exist | (#5.7.1) |
| 554 | too many hops, this message is looping | (#5.4.6) |
| 554 | sorry, invalid message content (optional text) | (#5.3.2) |
Normally, qmail-smtpd doesn't log anything.With SPAMCONTROL qmail-smtpd logs accepted and some (important) rejected SMTP session attempts. The logging is done at the end of the "Rcpt To:" and eventually at the end of the "Data" phase.
Action |
Type |
Condition |
Explanation |
| Reject | SMTP | Toomany_Hops | Message Hop count exceeded |
| Reject | SMTP | Syntax_Error | Malformed SMTP address (e.g. missing brackets) |
| Reject | DATA | Invalid_Size | DATA exceeds sizelimit |
| Reject | DATA | Bad_MIME | DATA includes BASE 64 MIME type listed in badmimetypes |
| Reject | DATA | Bad_Loader | DATA includes BASE64 loader type listed in badmimetypes |
| Reject | DATA | Virus_Infected | DATA includes virus infected message (QHPSI) |
| Reject | SNDR | Bad_Helo | SNDR's HELO is in the badhelo |
| Reject | SNDR | DNS_HELO | SNDR's HELO has no DNS A/MX RR |
| Reject | SNDR | Invalid_Relay | SNDR's tries relaying; but not allowd |
| Accept | SNDR | Relay_Client | SNDR was identfied as relay client |
| Reject | ORIG | Bad_Mailfrom | ORIG is in badmailfrom |
| Reject | ORIG | DNS_MF | Domain part of ORIG has no DNS MX RR |
| Reject | ORIG | Failed_Auth | ORIG tried SMTP Authentication; but failed |
| Reject | ORIG | Invalid_Sender | ORIG not allowed to send |
| Reject | ORIG | Invalid_Nullsender | ORIG is Nullsender with multiple RCPTs |
| Reject | ORIG | Missing_Auth | SMTP Authentication required, but not granted |
| Accept | ORIG | Valid_Auth | ORIG was successful authenticated |
| Accept | ORIG | Local_Sender | ORIG was identified as local sender address |
| Accept | ORIG | Relay_Mailfrom | ORIG was accepted als Relaymailfrom |
| Reject | RCPT | Bad_Rcptto | RCPT is in badrcptto |
| Reject | RCPT | Toomany_Rcptto | Too many RCPTs |
| Reject | RCPT | Failed_Rcptto | RCPT could not acceptd as per recipients/cdb. |
| Accept | RCPT | Recipients_Rcptto | RCPT was accepted as per recipients/cdb. |
| Accept | RCPT | Recpients_VERP | RCPT was accepted per VERP address in recipients/cdb. |
| Accept | RCPT | Recpients_Domain | RCPT was accepted per Domain wildlisting in recipients/cdb. |
| Accept | RCPT | Rcpthosts_Rcptto | RCPT was accepted as per rcpthosts/morercpthosts |
The Information includes typically the following
This scheme is easy extensible to other successful/deferred SMTP sessions. Sample:
Accept::SNDR::Relay_Client: S:81.173.229.48:xdsl-81-173-229-48.netcologne.de H:mail.fehcom.de F:feh@fehcom.de T:erwin@example.com
A typical tcpserver start script applying standard splogger:
Since splogger is now facilitated, ACCUSTAMP time information is included.
A better choice would be multilog. multilog allows you to write separate filtered logs; to individual directories, and/or files, STDERR respectively.A typical Daemontools qmail-smtpd run script would look like:
Note: tcpserver's logging via the '-v' flag can be omitted to get mostly a full comprehensive and terse one-line logging of the SMTP session.
The corresponding multilog run script allows not only to filter the log information and write them to the file "current" in a specific directory but in addition to feed a file with specific information; here's a sample:
In this case, multilog adds at first a TAI64 time stamp.
In this version of SPAMCONTROL I have substantially reduced the number of compile-time options:
In order to consistently change all relevant binaries, use the file conf-spamcontrol which is evaluated by the installation routine install_spamcontrol.sh and passes the changes to the Qmail c-files:
In case your E-Mail environment complies to the assumption in PURPOSE do the following:
to your needs.
See above samples and check the included samples for ./badmailfrom and ./badrcptto.
*) Not useful, if tcpserver in employed.
Good luck!
Attention: For 64 bit OS'es you may need in addition the qmail-isoc patch from James Craig Burley (http://www.jcb-sc.com/qmail/patches/qmail-isoc.patch).
The SPAMCONTROL patch is incompatible with the Qmail LDAP patch. It should be applied against qmail-1.03 and not against netqmail-1.0x.
Actually, the Qmail LDAP enhancement is a super set of SPAMCONTROL. If you need to incorporate parts of SPAMCONTROL into the LDAP patch, look at the different pieces and pick 'em up from the sources.
Thanks to the discussion in the Qmail Mailing List (qmail@list.cr.yp.to) in particular:
Erwin Hoffmann (feh@fehcom.de)
Cologne, 2005-01-30