| COURIER(8) | Double Precision, Inc. | COURIER(8) |
courier - The Courier mail server
courier {start | stop | restart | flush | flush qid | clear user@domain | clear all | show all }
The Courier mail server is a modular multi-protocol E-mail transport agent. The courier command is an administrative command, and most of its options are only available to the superuser.
"courier start" starts the server by running /usr/lib/courier/courierctl.start in the background. "courier stop" immediately stops all the Courier mail server processes and aborts all current mail deliveries. "courier restart" restarts the Courier mail server server. A restart is often needed for certain configuration changes to take effect. "courier restart" waits for all current deliveries to complete before restarting. This is the "nice" way to restart the mail server. "courier flush" takes all undelivered messages in the queue and attempts to deliver them immediately, instead of waiting until their next scheduled attempted delivery time. "courier flush" can be optionally followed by a message queue ID in order to schedule an immediate delivery attempt for only a single message. Message queue IDs are displayed by the mailq(1)[1] command.
Please note that courier start runs the main Courier mail server scheduling engine only. It does not start any other daemons that you may have, such as the ESMTP or the IMAP daemon.
"courier show all" lists all E-mail addresses currently blacklisted for backscatter. "courier clear user@domain" manually clears <user@domain> from the backscatter blacklist. "courier clear all" removes all addresses from the backscatter blacklist. When the Courier mail server encounters a delivery failure to an E-mail address the Courier mail server may stop accepting any more messages to the same address in order to minimize generation of so-called "backscatter bounces". This does not occur in all cases, see "Backscatter suppression" in the Courier mail server's installation instructions for more information.
The Courier mail server will resume accepting messages to the blacklisted address if the delivery attempt originally encountered a temporary failure, and a subsequent retry succesfully delivered the message, or if more than two hours elapsed since the delivery failure. Use the "clear" command to manually clear the E-mail address from the backscatter blacklist. This may be useful if the undeliverable message is manually removed from the Courier mail server's mail queue, using the "cancel" command. Even if the message is cancelled, the Courier mail server will continue to refuse accepting mail for this address for up to two hours. The "clear" command can be use to reenable mail acceptance before then.
The Courier mail server uses several configuration files which are located in /etc/courier. These configuration files are plain text files that can be modified with any text editor. In certain instances a subdirectory is used, and all plain text files in the subdirectory are concatenated and are considered to be a single, consolidated, configuration file. Unless otherwise specified, you must run courier restart for any changes to these files to take effect.
International domain names should be listed in UTF-8 lowercase. For example, the hosteddomains file may list “пример.испытание” as a domain.
aliasfilteracct
When mail filtering is enabled, local recipients have the ability to define mail filters which can selectively reject unwanted mail. /etc/courier/aliases may define local mail aliases that contain one or more recipients. If it is desired to use local mail filtering for mail addressed to an alias address, designate a local account that will be used to specify filtering instructions, and put its home directory into this control file. The filtering argument will be "alias-address" where address is the name of the alias. See localmailfilter(7)[2] for more information.
Due to technical limitations, content filtering is not available for multiple-recipient aliases.
Changes to this file take effect immediately.
autoresponsesquota
The autoresponsesquota file contains one line: "Cnnn" or "Snnn" (or both strings, on the same line). Cnnn: allow up to #nnn autoreplies to be created. Snnn: allow up to #nnn bytes as the total size of all autoreplies, combined. If both Cnnn and Snnn are specified, both quotas apply. If this file does not exist, there is no limit on autoreplies. This quota setting applies systemwide. To override the quota setting for a particular Maildir, create the autoresponsesquota file in that Maildir (which takes precedence).
backuprelay
Mail gets rerouted if it cannot be delivered after the time interval specified by the warntime configuration file. When backuprelay is provided a delayed delivery status notification will NOT be generated. The message will be rerouted even if the recipient's delivery status notification setting does not include a delayed notification request.
This feature is intended for use by relays that handle large quantities of mail, where you don't want to accumulate a large mail queue for unreachable mail servers. Please note that ALL undeliverable mail will be rerouted in this fashion. Even if the recipient of a message is a local recipient - and the recipient's mail filter is rejecting the message with a temporary error code - the message will still be rerouted if it's undeliverable after the specified amount of time.
Although currently SMTP is the only meaningful application for this feature, the Courier mail server is a protocol-independent mail server, and the backup relay function can be extended to other protocols, as they become available.
Multiple backup relays can be used by simply assigning multiple IP addresses to the same machine name. Note that the Courier mail server checks for both MX and A records for the machine specified in this configuration file.
It's important to note that when this setting is specified, warning messages get turned off for all messages, including messages addressed to local recipients. If a temporary delivery error prevents a message from being delivered to a local mailbox, it remains in the queue until the temporary error condition gets cleared. Normally, if the message remains in the queue beyond the warning interval, the warning message gets generated. When this setting is specified, the warning message gets replaced with a forward to the backup relay, but this occurs only for messages that are delivered via SMTP.
batchsize
bofh
badfrom user@domain
badfrom @domain
badfrom @.domain
badfrom user@.domain
badmx N
freemail domain [domain2] [domain3]...
spamtrap user@domain
maxrcpts N [hard]
opt BOFHCHECKHELO=1
opt BOFHCHECKHELO=2
opt BOFHHEADERLIMIT=n
opt BOFHNOBASE64TEXT=1
opt BOFHSPFHELO=keywords
SPF checking is not used for HELO or EHLO commands that specify an IP address instead of a domain name.
opt BOFHSPFMAILFROM=keywords
opt BOFHSPFFROM=keywords
opt BOFHSPFHARDERROR=keywords
The default setting for BOFHSPFHARDERROR is fail,softfail.
opt BOFHSPFTRUSTME=1
opt BOFHSPFNOVERBOSE=1
opt BOFHSUPPRESSBACKSCATTER=list
“list” is a comma-separated list of message sources. The possible message sources are:
authsmtp
smtp
none
The default setting is “opt BOFHSUPPRESSBACKSCATTER=smtp”. The other possible values are “opt BOFHSUPPRESSBACKSCATTER=smtp,authsmtp” (which suppresses backscatter from all SMTP mail), and “opt BOFHSUPPRESSBACKSCATTER=none”.
calendarmode
echo "local" >/etc/courier/calendarmode
courierd
defaultdomain
When the ESMTP server receives a “RCPT TO” command containing the address <user@[ip.address]>, and the IP address is the same as the IP address of the socket it's listening on, the ESMTP server replaces the IP address with the contents of the defaultdomain control file. If defaultdomain is missing, the Courier mail server uses the contents of the me control file.
The contents of defaultdomain are also appended to return addresses to mail sent from the Courier mail server's webmail server, if they don't already have a domain. If defaultdomain does not exist, the Courier mail server's webmail server obtain the machine hostname, and uses that.
Otherwise, if a domain-less address in mail headers gets augmented with defaultdomain and the recipient replies to the message, upon receipt Courier won't recognize the recipient address as a local mailbox. This might not necessarily be wrong, but the consequences of such an action must be clearly understood.
dotextension
dsnfrom
dsnlimit
The sender can request that the entire message be returned even on delayed notices or return receipts, however the Courier mail server will ignore this request if the message size exceeds this limit.
enablefiltering
esmtp
local
uucp
If you want to specify more than one source of mail, such as ESMTP and local mail, specify both esmtp and local, separated by a space character.
esmtpacceptmailfor
See the section called “Hostname-dependent configuration” for more information on hostname-dependent configuration in the esmtpacceptmailfor configuration file.
esmtpacceptmailfor.dat and esmtpacceptmailfor.dir
See the section called “Hostname-dependent configuration” for more information on hostname-dependent configuration in the esmtpacceptmailfor.dir configuration files.
esmtpauthclient
relay userid password
ESMTP negotiation will take place, and the Courier mail server will use a SASL authentication method supported by both the Courier mail server and the remote ESMTP server. Currently the Courier mail server supports PLAIN, LOGIN and CRAM-MD5 authentication. CRAM-MD5 is preferred over the other two, and PLAIN is preferred over LOGIN.
The Courier mail server also supports ESMTP over SSL (the ESMTP STARTTLS extension). If ESMTP STARTTLS is enabled, STARTTLS will be used to establish a secure link first. The authentication will take place afterwards, over a secure channel.
Changes to this file take effect, more or less, immediately (existing connections are not affected, but new connections will read the updated data).
esmtpd
esmtpdelay
The courieresmtp process delivers mail that's routed to external mail relays, via ESMTP. When attempting to initally contact a mail server courieresmtp waits for the amount of time specified by esmtptimeoutconnect (see below). esmtptimeoutconnect is usually set to a relatively long period of time, in order to accomodate slow mail servers. A large number of messages queued up for an unreachable mail server can tie up delivery slots that can be put to a better use by reassigning them for mail to another domain. Although the Courier mail server does not usually assign all delivery slots for messages to the same domain (this is a tuneable parameter), it is still not very healthy to have a bunch of courieresmtp daemons spinning their wheels, doing nothing.
The situation worsens when there is a large number of mail relays that accept mail for the same domain, and all of them are unreachable due to a network failure. That's because the esmtptimeout waiting period is used for each individual mail relay. Multiply esmtptimeout by the number of servers to see how large the delay really will be.
esmtpdelay is implemented internally in the courieresmtp module. The main the Courier mail server scheduling daemon is not aware of what's happening internally in courieresmtp. When courieresmtp fails to contact any mail relay for the domain, the message is postponed, and the esmtpdelay timer is set. Any additional messages received by the same courieresmtp daemon (for the same domain), are immediately postponed without any attempt to contact a remote mail relay. When the amount of time set by esmtpdelay expires, courieresmtp will attempt to make another delivery attempt as usual.
If esmtpdelay does not exist, the default delay is five minutes. Any messages that are postponed look like any other temporary failure to courierd. Delivery attempts are rescheduled as if a real temporary failure took place. Therefore it does not make sense to set esmtpdelay to be greater than retryalpha (see below). When retryalpha is smaller is esmtpdelay, you'll just messages spinning through the mail queue, with useless delivery attempts being attempted because esmtpdelay still hasn't expired.
Occasionally you might observe somewhat strange behavior on systems with heavy mail traffic. esmtpdelay applies separately to each individual instance of courieresmtp. When a remote mail server keeps going up and down, it is possible to end up with multiple courieresmtp daemons handling mail for the same domain, but only some of them will encounter a network failure, purely by the luck of the draw. The remaining daemons will be able to establish a connection. So you'll end up with some courieresmtp daemons being able to deliver mail immediately, while the rest are still waiting patiently for esmtpdelay to expire, postponing all messages in the meantime. Some messages - but not all - will be immediately postponed without a delivery attempt, becauses they ended up getting to a daemon which is waiting for esmtpdelay to expire.
Another anomalous situation may happen when a courieresmtp daemon gets reassigned to another domain, and then receives more mail for the previous domain. This can happen when you have a lot of mail going through. Although the Courier mail server tries to shuffle all mail for same domain into one pile, the scheduler still tries to dispatch mail on "first-come, first-serve" basis, as much as possible. When that happens another delivery attempt will be made immediately, because the previous esmtpdelay was cancelled when the daemon got reassigned to another domain.
There can also be occasional abnormalities that affect systems with light traffic. When there is a domain with several mail relays of equal priority, one mail relay is chosen at random for the connection attempt. If some of the equal-priority mail relays are unreachable and a courieresmtp daemon picks it, it will start the esmtpdelay timer and refuse to deliver any more mail until it expires, even if most of the mail servers are functional. This will happen only with mail relays of the lowest priority. Otherwise, courieresmtp will always try to contact another mail relay of a still lower priority, before giving up and setting the esmtpdelay timer. Another courieresmtp daemon will not be started for the same domain if there's already an existing one, so all delivery attempts will be turned away until esmtpdelay expires. Another courieresmtp daemon will be started only in the event of multiple simultaneous delivery attempts that happen to coincide at the same time.
This is somewhat mitigated by the fact that all courieresmtp daemons are killed after a short period of total inactivity (currently one minute), so that longer intervals specified by esmtpdelay are ignored. Note, however, that receiving a message to deliver, and then postponing it immediately, does count as some activity.
esmtpdelay can be turned off by setting it to 0 seconds. esmtpdelay is designed for servers that handle heavy amount of mail that wish to avoid having outbound delivery slots tied up due to network failures, at an expense of an occasional anomalous behavior due to harmless paranoia. esmtpdelay may prove to actually make things worse for systems that carry only light mail traffic, if they are burdened with a task of exchanging mail primarily with external systems that are not properly maintained.
esmtpgreeting
esmtphelo
esmtphelo may also be set to a special value of “*”:
echo '*' >esmtphelo
esmtproutes
domain:relay[,port][/SECURITY=STARTTLS][/SECURITY=REQUIRED][/SECURITY=SMTPS]
relay can be another domain, or an explicit IP address inside brackets. For example, if esmtproutes contains the following:
example.com: relay.domain.com domain.com: [192.168.0.2]
.example.com: [192.168.0.3],26
esmtproutes is read from top to bottom, stopping as soon as a first match is found.
domain may be empty, this specifies a smarthost for all domains. For example, if esmtproutes contains the following text:
example.com: relay.example.com
:[192.168.0.4]
If relay is empty, the Courier mail server interprets it as an explicit directive to use MX and A records from DNS. For example:
example.com: :[192.168.0.4]
The /SECURITY=STARTTLS flag indicates that mail to this domain will use the SECURITY ESMTP extension. See the Courier mail server installation notes for a description of SECURITY, what it does, and how to configure it.
: relay.example.com,465 /SECURITY=SMTPS
Otherwise, TLS still gets used to send mail, but the smarthost's certificate does not get validated. Properly-managed Internet providers should install a valid certificate, signed by a trusted authority, if they require SMTPS. Poorly-managed Internet providers will just install a self-signed certificate, and will not be able to explain why they require SMTPS, if it's trivially compromised with a man-in-the-middle attack that a non-validated certificate enables, so either find a more competent provider, or use /SECURITY=SMTPS without actually enabling all the extra validation that's actually needed to gain any kind of a secure mail transmission channel.
When the Courier mail server connects to another server that claims to support an encrypted connection, tries to enable it, then fails because the other mail server drops the connection or returns an error message, all subsequent connection attempts to the same mail server will ignore the server's false advertising, and proceed to send mail without attempting to enable encryption. The Courier mail server remembers not to use the encryption with this server for the next 2-4 hours (depending on an internal log file's rotation schedule). Once the remote mail server emerges from the penalty box, the next connection attempt will try again, and see if it's still doesn't work.
The /SECURITY=REQUIRED flag blocks the Courier mail server from sending mail to the remote server unless a standard encryped connection can get established. If it's known that the given mail server should only receive encrypted mail, /SECURITY=REQUIRED prevents a man-in-the-middle attack where the remote mail server's advertisement of is STARTTLS capability gets suppressed, and the mail gets sent in the clear.
/SECURITY=STARTTLS
/SECURITY=SMTPS
/SECURITY=REQUIRED
Changes to esmtproutes take effect immediately, more or less. Existing courieresmtp processes that already have an established connection will ignore any changes.
esmtptimeout
esmtptimeoutconnect
esmtptimeoutdata
esmtptimeouthelo
esmtptimeoutkeepalive
Note that there's also a separate limit to the maximum number of simultaneous SMTP sessions to the same domain. That limit is currently four, which is adequate for nearly every situation, so for now it will be set by an undocumented configuration file.
esmtptimeoutkeepaliveping
esmtptimeoutquit
faxqueuetime
faxqueuetime specifies the timeout for fax messages. This time interval is specified in the same way as queuetime (see queuetime for more information).
faxnotifyrc
faxrc
hosteddomains
If the domain "example.com" appears in hosteddomains instead, the Courier mail server will look for a local mailbox named "user@example.com" instead.
The contents of the hosteddomains configuration file is a list of domains, one per line, in lowercase. You must run the makehosteddomains command, followed by courier restart (this restarts the server) for any changes to take effect.
Additionally, hosteddomains can specify simple domain aliases. See the complete description in the makehosteddomains(8)[8] manual page.
See the section called “Hostname-dependent configuration” for more information on hostname-dependent configuration in the locals configuration file.
ipout, ip6out
ldapaddressbook
name<tab>host<tab>port<tab>suffix<tab>binddn<tab>bindpw
ldapaliasrc
locallowercase
locals
.domain.com
Specific hosts can be excluded from the wildcard. Example:
!host.domain.com
.domain.com
The "!hostname" syntax is also valid in the esmtpacceptmailfor control file.
If locals does not exist, the Courier mail server uses the contents of the me control file (note that me specifies only one domain, second and subsequent lines are ignored). Also, see hosteddomains.
See the section called “Hostname-dependent configuration” for more information on hostname-dependent configuration in the locals configuration file.
localtimeout
logindomainlist
What if you don't want to display a drop down menu? Administrators can now specify records that generate a hidden field in login.html, or an editable text field, allowing sqwebmail to show only one mail login domain to each user per access URL or IP address. This functionality can greatly reduce confusion for first time webmail users, and greatly speed the login process for frequent webmail users.
Finally, the new logindomainlist file offers a new tool to ease maintenance. Administrators can now use wildcards to "rewrite" the domain portion of the access URL to the mail domain equivalent. For example, the following record can rewrite the URL "mail.*.com" to the mail domain "*.com"
*.com:mail.*.com:@
This powerful wildcard functionality can ease the login process for most of your server's mail domains with just one or two logindomainlist records.
File Format
firstfield:secondfield:thirdfield
Above, we can see that the new logindomainlist records are made up of three fields delimited by colons. But what does each field do?
First Field - the first field contains the "mail domain" for which we would like the user to log in under. The mail domain is the part of an email address after the @ symbol. For example, in the email address "user@domain.com", "domain.com" is the mail domain.
Second Field - the second field contains the "access domain". The access domain contains an URL or IP address that is used to figure out which mail domain to use by default. For example, in the following logindomainlist record:
domain1.com:domain2.com
"domain2.com" is the "access domain" and "domain1.com" is the "mail domain". If the user logs into the following URL:
http://domain2.com/cgi-bin/sqwebmail
His default "mail domain" will be "domain1.com".
Third Field - the third field may contain a modifier. The modifier may be either a single character modifier, or a group identification string. The single character modifiers and the group modifier are described in detail below.
Finally, the logindomainlist file may also contain comments and empty lines. Empty lines can be used to group records visually, and comments can be used to explain why a certain record or group of records look the way they do.
If the first character of a line is a '#', then the entire line is considered a comment and is ignored. If the first character of a line contains whitespace, the entire line is assumed to be an empty line and is ignored.
Modifiers
domain1.com:domain2.com:firstgroup
domain3.com:domain4.com:firstgroup
domain5.com:domain6.com:firstgroup
domain7.com:domain8.com:secondgroup
domain9.com:domain10.com:secondgroup
http://domain4.com/cgi-bin/sqwebmail
He will see a drop down containing ONLY the following domains:
domain1.com
domain3.com
domain5.com
Wildcards
In the logindomainlist file, an asterisk (*) character in either the first and/or second field represents a wildcard. Any asterisk in the second field will be used to match an access domain. If an asterisk exists in the first field then any characters which the asterisk in the second field represents will replace the asterisk in the first field when sqwebmail determines the default mail domain. However, asterisks are not required in either the first or second fields. They are totally optional. For example, given the following logindomainlist record:
*.com:mail.*.com:@
If the user logs into sqwebmail with the following URL:
http://mail.mydomain.com/cgi-bin/sqwebmail
The asterisk in the second field will represent the string "mydomain". This string will then replace the asterisk in the first field to give the following default mail domain: mydomain.com
Similarly, if the following record exists in the logindomainlist file:
*:*:@
Then ANY URL the user uses to access sqwebmail will be automatically used for the default mail domain.
But the first field doesn't _HAVE_ to contain an asterisk. The following will work just fine:
mydomain.com:mydomain.*:@
The above example will allow the user to access the "mydomain.com" mail domain from any of the following URLs: "mydomain.org", "mydomain.net", "mydomain.us", etc...
And finally, the first field doesn't have to contain anything at all! If the first field is empty, that record will serve as an explicit no-default mail domain. No default mail domain will be specified if the second field matches the user's login URL. This is useful because the logindomainlist is searched from the top down. Any wildcard records at the bottom of the list will be overridden by records closer to the top. An "explicit no-default" record can be used to specify certain domains as "system account" domains so that no default mail domain is specified.
maildirfilterconfig
maildirshared
maildrop
This configuration file is initialized, by default, to point to the version of maildrop(1)[6] that's integrated with the Courier mail server. The integrated version of maildrop(1)[6] is configured slightly differently than the standalone version of maildrop(1)[6].
Although you can set the maildrop configuration file to point to some other version of the maildrop mail filter, you MUST set the maildropfilter configuration file (see below), to point to the integrated version of maildrop.
maildropfilter
This file is not installed by default. To activate mail filtering for local recipients, simply copy the contents of the maildrop configuration file to maildropfilter.
maildroprc
me
msgidhost
nochangingfrom
queuelo, queuehi, queuefill
queuehi specifies the maximum number of messages that are loaded into memory. The Courier mail server reads the mail queue on disk until either it reads all of it, or it reads the number of messages specified by queuehi. As messages are delivered they are removed from the memory and disk. Messages that are deferred for another delivery attempt are removed from memory, but kept on the disk.
When the number of messages in memory falls below queuelo, The Courier mail server goes back to disk and attempts to fill the memory queue to the top, again.
This is, basically, a capsule summary of the mail queue processing logic. Many small, low level details are omitted; this is just an executive overview. When new messages arrive during a large mail backlog, the new messages are also loaded into the memory queue, if there's room for them. Therefore, during a large mail backlog the Courier mail server simultaneously tries to clear the existing backlog, and process any new mail at the same time. Up to the Courier mail server 0.41, all of this generally translates to the Courier mail server giving priority to newly arrived mail, and processing the backed up mail queue if spare resources are available.
The queuefill setting was added in the Courier mail server 0.42, in an attempt to keep new mail from excessively delaying existing mail during a major queue backup. queuefill specifies a time interval. When the Courier mail server completely fills the memory queue it sets a timer. After the interval given by queuefill The Courier mail server will go back and re-fill the mail queue even if the number of messages did not fall below the low watermark. If the Courier mail server finds older messages in the mail queue they will be pushed to the top of the scheduling queue, and given priority.
Smaller queuefill time intervals means more frequent trips to the disk, and more overhead. But, in exchange for that, during a mail backlog the Courier mail server will spend more time handling a greater number of delayed messages. Larger queuefill time intervals means less frequent trips to the disk, and less overhead, in exchange for less "fairness" during large mail backlogs.
queuefill defaults to five minutes, if not specified. Explicitly setting it to 0 seconds turns off the queue re-filling completely, essentially reverting to pre-0.42 behavior. The default queuelo and queuehi values are computed at run time. queuelo defaults to the larger of 200, and the sum total of configured mail delivery slots, both local and remote. queuehi, if not explicitly set, defaults to the smaller of twice the queuelo, or queuelo plus 1000.
queuetime
retryalpha, retrybeta, retrygamma, retrymaxdelta
The Courier mail server will first make retrybeta delivery attempts, waiting for the time interval specified by retryalpha between each attempt. Then, the Courier mail server waits for the amount of time specified by retrygamma, then the Courier mail server will make another retrybeta delivery attempts, retryalpha amount of time apart. If still undeliverable, the Courier mail server waits retrygamma*2 amount of time before another retrybeta delivery attempts, with retryalpha amount of time apart. The next delay will be retrygamma*4 amount of time long, the next one retrygamma*8, and so on. retrymaxdelta sets the upper limit on the exponential backoff. Eventually the Courier mail server will keep waiting retrygamma*(2^retrymaxdelta) amount of time before making retrybeta delivery attempts retryalpha amount of time apart, until the queuetime interval expires.
The default values are:
retryalpha
retrybeta
retrygamma
retrymaxdelta
This results in the Courier mail server delivering each message according to the following schedule, in minutes: 5, 5, 5, 15, 5, 5, 30, 5, 5, 60, 5, 5, then repeating 120, 5, 5, until the message expires.
sizelimit
If sizelimit does not exist, and SIZELIMIT is not set, the maximum message size defaults to 10485760 bytes.
submitdelay
submitdelay specifies a time interval in the same format as queuetime.
usexsender
uucpme
uucpneighbors
uucprewriteheaders
vhost.ip-address, vhost.domain
warntime
This section describes how to set the various domain-related parameters incorporating the server's system-specified hostname. This makes it possible to create a canned, boilerplate set of Courier configuration files. The configuration files then get replicated, as is, to multiple servers. These servers have their system hostname externally managed, often via DHCP. The server's assigned hostname gets automatically incorporated into Courier's configuration.
me
*.example.com
locals, esmtpacceptmailfor/esmtpacceptmailfor.dir and hosteddomains
*.example.com
*
HTML output from the webmail server is generated from the template files in /usr/lib/courier/sqwebmail/html/en-us. It is possible to translate the webmail interface into another language simply by creating another subdirectory underneath /usr/lib/courier/sqwebmail/html, then meticulously translating each .html file. Each template file contains well-formed HTML, with dynamic content marked off by tags. Note that the large comment blocks in each HTML file need to be translated too, since they are inserted as dynamic content, elsewhere.
The directory /usr/lib/courier/sqwebmail/html/en-us also contains several configuration files, in addition to the HTML template files. Doing so allows this configuration information to be defined for each available language.
CHARSET
The default English HTML templates use strictly the “us-ascii” subset, and the CHARSET contains utf-8,iso-8859-1. When multiple character sets are listed, the first character set that's supported by the browser is picked, so with UTF-8 capable browsers the default webmail interface will use UTF-8, falling back to ISO-8859-1 for browsers that do not support UTF-8.
footer
ISPELLDICT
LANGUAGE
LANGUAGE_PREF
LOCALE
TIMEZONELIST
The Courier mail server can perform “Sender Policy Framework” checks on up to three addresses for each message. This is controlled by setting the following variables: BOFHSPFHELO, BOFHSPFMAILFROM, and BOFHSPFFROM. Each variable is set to a comma-separated list of the following keywords: “off” - SPF verification disabled (default); “none”, “neutral”, “pass”, “fail”, “softfail”, “error”, “unknown” - these keywords correspond to the possible results of an SPF check, the message is accepted for the listed SPF results only, any other SPF result is rejected; “all” - shorthand for all possible SPF results, use “all” to run SPF in informational mode only, recording the SPF status in the Received-SPF: header; “allowok” - automatically pass the SPF verification if the sender's IP address is found in a DNS access whitelist, any whitelist given in the -allow option to couriertcpd, see the “DNS ACCESS LISTS” section in couriertcpd(1)[14].
A rejected SPF result gets kicked back with a permanent error indication if the SPF result is listed in BOFHSPFHARDERROR, and a temporary error indication otherwise.
When enabling SPF checking, the keyword list should always include “pass” (it makes no sense to do otherwise) and “none”. The keyword list should also include “softfail”, “neutral”, and “unknown”. See the SPF draft for a description of these status results. At some distant future, the keyword list will only include “pass”, rejecting all senders without a stated policy. This might be desirable at some point in the future, but not right now.
The BOFHSPFFROM list may also include an additional keyword, “mailfromok”. BOFHSPFMAILFROM and BOFHSPFFROM are trade-offs. Using BOFHSPFMAILFROM is faster, and it does not require the entire message to be received, before running the SPF check. BOFHSPFFROM checking can only occur after the entire message is received, but it's more reliable. If “mailfromok” is listed, the From: is not checked if the MAIL FROM command was checked with the “pass” result.
In other words: the From: header is checked if MAIL FROM was empty, or did not pass the SPF checks. If MAIL FROM passed the SPF check the Courier mail server won't bother looking at the From: header.
A conservative policy should not reject failed SPF checks from the From:header, because it can be counterproductive in some situations. This is because when a sender from a domain with a published SPF policy sends a message to a mailing list, the message goes through the mailing list processor's IP address, and it will fail the SPF check unless the domain SPF explicitly authorizes the mailing list processor's IP address.
This is very unlikely. The end result is that domains with a published SPF record get punished, and domains without an SPF record get off scott free. Mailing lists should be encouraged to publish their own SPF records for mailing list traffic; then the “mailfromok” keyword can validate the mailing list's return address, and forego checking of the “From:” header from the mailing list, while still checking the “From:” header from everyone else.
Another alternative is to use opt BOFHSPFFROM=all for advisory purposes only. Post-delivery mail filters can key off the “Received-SPF” header.
The Courier mail server can add up to three “Received-SPF” headers of its own, one for each SPF check. The Courier mail server renames any existing “Received-SPF” header as “Old-Received-SPF”. All “Received-SPF” headers delivered to a local mailbox will always come from the Courier mail server.
The Courier mail server's default configuration listens on port 25 on all IP addresses. If the server has more than one IP address, Courier accepts connections on any IP address. Adjust the settings in the esmtpd configuration file to explicitly list which IP addresses Courier should listenson. This also applies to the ESMTP over SSL server on port 465 configured by esmtpd-ssl, and the MSA server on port 587, configured by esmtpd-msa.
That's for incoming EMSTP. For outgoing ESMTP connections, the Courier mail server does not specify an IP address by default, and lets the server select one. The server selects a default IP address based on a server's network configuration. The selection criteria is platform specific, and is typically based on the system's IP routing tables.
The ipout and ip6out configuration files set an explicit IP address for Courier's outgoing connections:
# echo "192.168.0.1" >/etc/courier/ipout # echo "fec0::230:48ff:fec4:429c" >/etc/courier/ip6out
This example specifies 192.168.0.1 as the IP address to make connections from for IPv4 destinations, and fec0::230:48ff:fec4:429c for IPv6 destinations.
If the Courier mail server runs on a host with two IPv4 addresses, 192.168.0.1, 192.168.1.1, the above example uses 192.168.0.1 to send the relayed message to IPv4 destinations even if Courier received the message from a client that connected to the other addresses.
If the Courier mail server accepts an ESMTP connection and a message from an authenticated client with relaying privileges, in a smarthost role, and forwards the message via ESMTP, Courier normally uses the server's default IP address, or the one set by ipout or ipout6. When the Courier mail servers runs on more than one IP address, it's possible to selectively set the outgoing IP address based on which one of those IP addresses the message was received at. A simple, basic configuration forwards the message from the same IP addresses it was received from, but it doesn't have to be, it can be a different one.
The first step is to enable a per-message, non-default configuration settings, like the outgoing IP address, by creating a zero-length vhost.ip-address file:
# touch >/etc/courier/vhost.192.168.0.1 # touch >"/etc/courier/vhost.fec0::230:48ff:fec4:429c"
This enables non-default settings for messages received from a client that connects to one of these IP addresses. These two IP addresses (one IPv4 and one IPv6 address) are, presumably, two of the server's IP addresses. This is not a client's IP address, these are the server's IP addresses. These may be the only two IP addresses the server has, or the server can have more IP addresses, but these are the only two IP addresses for which custom settings get enabled.
One such custom setting would be a different IP address for outgoing connections depending on the IP address of the connection the message was originally received from:
# echo "192.168.0.1" >/etc/courier/ipout.192.168.0.1 # echo "192.168.1.1" >/etc/courier/ipout.192.168.1.1
“ipout.address” sets the IP address for outgoing connections for messages received from a client connection to “address” only. Just an ipout applies to all other messages, except ones which have an ipout.address in existence. The above example specifies that, on a server with these two IP addresses, messages received from a client that's connected to either IP address get forwarded (from a client that normally authenticates and receives relaying privileges) using a connection from the same IP address. If the server has any other IP addresses, the IP address in ipout takes effect (or the default system-specified IP address).
For convenience, an empty ipout.address gets interpreted as if it contains the same address. The above example is equivalent to:
# touch /etc/courier/ipout.192.168.0.1 # touch /etc/courier/ipout.192.168.1.1
The formal configuration rules are as follows, for a message received from IP address “address”, which may be an IPv4 or an IPv6 address:
It is possible for the Courier mail server to receive a message from an IPv6 connection, and forward it to an IPv4 address, or vice versa. The address portion of /etc/courier/ipout.address and /etc/courier/ip6out.address, specifies the IP address the client used to connect to Courier and may be either an IPv4 or an IPv6 address, in both cases! For example:
# echo "192.168.0.1" >/etc/courier/ipout.192.168.0.1 # echo "fec0::230:48ff:fec4:429c" >/etc/courier/ip6out.192.168.0.1
This means that when a client connects to the Courier mail server using the IP address 192.168.0.1 and relays a message, if the message gets forwarded to an IPv4 address, Courier uses the same IP address, and if it gets forwarded to an IPv6 address Courier uses this IPv6 address. The above also probably means that:
# echo "192.168.0.1" >"/etc/courier/ipout.fec0::230:48ff:fec4:429c" # echo "fec0::230:48ff:fec4:429c" >"/etc/courier/ipout.fec0::230:48ff:fec4:429c"
So if an IPv6 client connects to Courier on this IPv6 address and relays a message, Courier uses the same IPv6 address, or 192.168.0.1 depending on the destination.
Notwithstanding the IP address set in an ipout or an ip6out file, the server's network configuration must be able to actually establish a network connection to the destination address from the explicitly specified IP address. Specifying an explicit IP address for outgoing connections implies that the IP addresses are fully and globally routable.
Additionally, for all other configuration files described in this manual page, the Courier mail server uses “filename.address” if it exists, in place of “filename” when processing messages received from “address”, either an IPv4 or an IPv6 address.
This is used in all contexts where it makes sense to do so:
# echo "relay.example.com" >/etc/courier/me.192.168.0.1 # echo "firewall.example.com" >/etc/courier/me.192.168.1.1
This example specifies “relay.example.com” as the contents of the me configuration file, described earlier in this manual page, when processing messages received by clients that connect to 192.168.0.1, and “firewall.example.com” for processing messages received by clients that connect to 192.168.1.1.
“me” is the default hostname for most common Courier mail server configuration settings, such as the server's name in the ESMTP greeting banner, what Courier calls itself in the ESMTP EHLO/HELO commands, and other contexts, unless overridden by a more specific setting.
The IP address-specific configuration settings get used only in the context of processing messages, and have no impact on other parts of the Courier mail server that do not have a direct relationship to a specific message. One such example would be when Courier authenticates a client's username or password. This is not directly related to any message the client may or may not send after it authenticates, so this happens in exactly the same way no matter which IP address the client connected to.
As described in the previous section, the existence of vhost.ip-address enables configuration settings only for messages that were received at one of the IP addresses that the Courier mail server accepts connections on.
It's possible to partially achieve the same end results by creating vhost.domain:
# touch >/etc/courier/vhost.example.com
This enables per-message specific configuration for messages received from authenticated clients whose authenticated ID ends with “@example.com”. If the server has more than one IP address, but, for whatever reason, only receives mail on one of them but wants to use the other one for outgoing mail for this domain:
# echo '192.168.0.1' >/etc/courier/ipout.example.com
This sets this IP address for all outgoing messages with a “@example.com” authenticated client. It's important to note the following limitations:
Flushing a single message will not work if the message queue is backed up. When that happens, your only available option is to flush the entire queue.
courier start fails if the Courier mail server has detected a fatal operational error. In this situation the top-level courierd daemon sleeps for a minute, before automatically restarting. During this sleep interval courier stop does not work.
cancelmsg(1)[12], maildirmake(1)[10], maildrop(1)[6], preline(1)[15], sendmail(1)[16], testmxlookup(1)[17], dot-courier(5)[4], authlib(7)[18], courierfax(8)[7], courierfilter(8)[5], filterctl(8)[5], courierldapaliasd(8)[9], courierpop3d(8)[19], courierpop3d(8)[19], couriertcpd(8)[14], courieruucp(8)[13], esmtpd(8)[20], imapd(8)[21], localmailfilter(7)[2], mailq(1)[1], makeacceptmailfor(8)[22], makealiases(8)[23], makehosteddomains(8)[8], makepercentrelay(8)[24], makesmtpaccess(8)[3], makeuserdb(8)[25], pw2userdb(8)[25], mkdhparams(8)[26], mkesmtpdcert(8)[27], mkimapdcert(8)[28], pop3d(8)[29], submit(8)[30], userdb(8)[31].
Sam Varshavchik
| 12/18/2020 | Courier Mail Server |