Smtpserver Configuration

ZMailer: The Manual; v1.99.20
Prev |  | Next

# Chapter 12. Smtpserver Configuration

The smtpserver is ZMailer's component to receive incoming email via SMTP protocol. Be it thru TCP channel, or thru Batch-SMTP.

The smtpserver program actually has several operational modes. It can operate as a stand-alone internet service socket listener, which forks off childs that do the actual SMTP-protocol service.

It can be started from under the control of the inetd(8) server, and it can there fulfill most of the the same roles as it does in the stand-alone mode.

It can even be used to accept Batch-SMTP from incoming files (UUCP, and BITNET uses, for example).

The runtime command-line options are as follows:

smtpserver [-46aignvBV] [-p `port`] [-l `logfile`] [`-s `'strict'``] [-s `[ftveR]`] [-L `maxloadaver`] [-M `SMTPmaxsize`] [-P `postoffice`] [-R `router`] [-C `cfgfile`] [-T `IPv4/IPv6-address-literal`]

The most commonly used command line options are:

     smtpserver [-aBivn] [-s ehlo-styles] [-l logfile] [-C cfgpath]

Without any arguments the smtpserver will start as a daemon listening on TCP port 25 (SMTP).

The options are:

-a

  Query IDENT information about the incoming connection. This information (if available at all) may, or may not tell who is forming a connection.

-B

  The session is Batch-SMTP a.k.a. BSMTP type of session. Use of "-i" option is needed, when feeding the input batch file.

-i

  This is interactive session. I/O is done thru stdin/stdout.

-v

  Verbose trace written to stdout for use in conjunktion with "-i", and "-B".

-n

  This tells that the smtpserver is running under inetd(8), and that the stdin/stdout file handles are actually network sockets on which we can do peer identity lookups, for example.

-s ehlo-style

  Default value for various checks done at SMTP protocol MAIL FROM, RCPT TO, VRFY, and EXPN commands. These are overridden with the value from EHLO-patterns, if they are available (more below)

-s 'strict'

  Special value directing the system to be extremely picky about the incoming SMTP protocol — mainly for protocol compliance testing, usually way too picky for average (sloppy) applications out there...

-l logfilepath

  Filename for the smtpserver input protocol log. This logs about everything, except actual message data...

-l 'SYSLOG'

  This tells smtpserver that it shall send all incoming smtp protocol transactions via syslog facility to elsewere. Used syslog parameters are: FACILITY=mail, LEVEL=debug.

  This option may be used in addition to the preceding file logging variant. Double-use of file referring variant uses the last defined file, but this doesn't affect files at all.

-C configfilepath

  Full path for the smtpserver configuration in case the default location can not be used for some reason.

-M SMTPmaxsize

  SMTPmaxsize defines the absolute maximum size we accept for incoming email. (Default: infinite) (This is a local policy issue.)

-T IPv4-or-IPv6-address-literal

  address literal is used in interactive test mode to check how

# 12.1. `smtpserver.conf`

If the system has file `$`MAILSHARE`/smtpserver.conf` (by default), that file is read for various parameters, which can override most of those possibly issued at the command line.

Example configuration is is in figure Figure 12-1.

Figure 12-1. Sample `smtpserver.conf` file

    #PARAM maxsize          10000000    # Same as -M -option
    #PARAM max-error-recipients    3    # More than this is propably SPAM!
    #PARAM MaxSameIpSource        10    # Max simultaneous connections from
    #                                   # any IP source address
    #PARAM ListenQueueSize        10    # listen(2) parameter
    #
    PARAM help -------------------------------------------------------------
    PARAM help  This mail-server is at Yoyodyne Propulsion Inc.
    PARAM help  Our telephone number is: +1-234-567-8900, and
    ....
    PARAM help -------------------------------------------------------------

    # The policy database:  (NOTE: See  'makedb'  for its default suffixes!)
    PARAM  policydb   btree  /opt/mail/db/smtp-policy

    #
    # HELO/EHLO-pattern     style-flags
    #               [max loadavg]
    #
    localhost           999 ftveR
    some.host.domain    999 !NO EMAIL ACCEPTED FROM YOUR MACHINE

    # If the host presents itself as:  HELO [1.2.3.4], be lenient to it..
    # The syntax below is due to these patterns being SH-GLOB patterns,
    # where brackets are special characters.

    [*]                 999 ve

    # Per default demant strict syntactic adherence, including fully
    # qualified addresses for  MAIL FROM, and RCPT TO.  To be lenient
    # on that detail, remove the "R" from "veR" string below:

    *                   999 veR

## 12.1.1. `smtpserver.conf`; PARAM keywords

The PARAM keywords and values are:

maxsize nn

  Maximum size in the number of bytes of the entire spool message containing both the transport envelope, and the actual message. That is, if the max-size is too low, and there are a lot of addresses, the message may entirely become undeliverable..

max-error-recipients nn

  In case the message envelope is an error envelope (MAIL FROM:<>), the don't accept more than this many separate recipient addresses for it. The default value is 3, which should be enough for most cases. (Some SPAMs claim to be error messages, and then provide a huge number of recipient addresses...)

MaxSameIpSource nn

  (Effective only on daemon-mode server — not on "-i", nor "-n" modes.) Sometimes some systems set up multiple parallel connections to same host (qmail ones especially, not that ZMailer has entirely clean papers on this - at least up to 2.99.X series), we won't accept more than this many connections from the same IP source address open in parallel. The default value for this limit is 10.

ListenQueueSize nn

  This relates to newer systems where the listen(2) system call can define higher limits, than the traditional/original 5. This limit tells how many nascent TCP streams we can have in SYN_RCVD state before we stop answering to incoming SYN packets requesting opening of a connection.

  There are entirely deliberate denial-of-service attacks based on flooding to some server many SYNS on which it can't send replies back (because the target machines don't have network connectivity, for example), and thus filling the back-queue of nascent sockets. This can also happen accidentally, as the connectivity in between the client host, and the server host may have a black hole into which the SYN-ACK packets disappear, and the client thus will not be able to get the TCP startup three-way handshake completed.

  Most modern systems can have this value upped to thousands to improve systems resiliency against malicious attacks, and most likely to provide complete immunity against the accidental "attack" by the failing network routing.

help 'string'

  This one adds yet another string (no quotes are used) into those that are presented to the client when it asks for "HELP" in the SMTP session.

PolicyDB dbtype dbpath

  This defines the database type, and file path prefix to the binary database containing policy processing information. More of this below. Actual binary database file names are formed by appending type specific suffixes to the path prefix. For example NDBM database appends ".pag" and ".dir", while BSD-Btree appends only ".db". (And the latter has only one file, while the first has two.)

  For an operative overview, see Section 12.2, and for deeper details, see Section 17.4.

## 12.1.2. `smtpserver.conf`; ``EHLO-style options''

    \index{smtpserver!{\tt smtpserver.conf}; ``EHLO-style options''}

All lines that are not comments, nor start with uppercase keyword ``POLICY'' are ``EHLO-style patterns''. This is the oldest form of configuring the smtpserver, and as such, it can be seen...

Behaviour is based on glob patterns matching the HELO/EHLO name given by a remote client. Lines beginning with a ``#'', or whitespace are ignored in the file, and all other lines must consist of two tokens: a shell-style (glob) pattern starting at the beginning of the line, whitespace, and a sequence of style flags. The first matching line is used. As a special case, the flags section may start with a ! character in which case the remainder of the line is a failure comment message to print at the client. This configuration capability is intended as a way to control misbehaving client software or mailers.

The meanings of the style flag characters are as follow:

f

  Check ``MAIL FROM'' addresses through online processing in router

t

  Check {\tt RCPT TO} addresses through online processing in router

v

  Allow execution of {\tt VRFY} command online at attached router

e

  Allow execution {\tt EXPN} command online at attached router

R

  Require addresses to be in fully qualified (domained) form: ``local@remote'' (strict 821)

S

  Allow Sloppy input for systems incapable to respect RFC 821 properly; WinCE1.0 does: ``MAIL FROM:user@domain'' :-(

# 12.2. Policy Based Filtering

    \index{smtp!policy filtering, overview}

The policy database that smtpserver uses is built with policy-builder.sh script, which bundles together a set of policy source files:

      DB/smtp-policy.src          The boilerplate
      DB/localnames               ('= _localnames')
      DB/smtp-policy.relay        ('= _full_rights')
      DB/smtp-policy.mx           ('relaytargets +')
      DB/smtp-policy.spam         ('= _bulk_mail')
      DB/smtp-policy.spam.manual  ('= _bulk_mail')

FIXME: {\tt smtp-policy.spam} source

FIXME: {\tt smtp-policy.spam.manual} source

{\em If you want, you can modify your {\tt smtp-policy.src} boilerplate file as well as your installed {\tt policy-builder.sh} script.} {\bf In fact you SHOULD modify both to match your environment!}

Doing {\tt make install} will overwrite {\tt policy-builder.sh}, but not {\tt smtp-policy.src}.

Basically these various source files (if they exist) are used to combine knowledge of valid users around us:

localnames

  Who we are — ok domains for receiving.

smtp-policy.relay

  Who can use us as outbound relay.

  Use {\em\verb/[/ip.number\verb/]//maskwidth} here for listing those senders (networks) we absolutely trust. You may also use domains, or domain suffixes so that the IP-reversed hostnames are accepted (but that is a it risky thing due to ease of fakeing the reversed domain names):

        [11.22.33.00]/24
        ip-reversed.host.name
        .domain.suffix

  Server sets its internal ``always_accept'' flag at the source IP tests before it decides on what to tell to the contacting client. The flag is not modified afterwards during the session.

  Usage of domain names here is discouraged as there is no way to tell that domain ``foo.bar'' here has different meaning than same domain elsewere — at ``{\tt smtp-policy.mx}'', for example.

smtp-policy.mx

  Who really are our MX clients. Use this when you really know them, and don't want just to trust that if recipient has MX to you, it would be ok\ldots

  You can substitute this knowledge with a fuzzy feeling by using ``acceptifmx -'' attribute at the generic boilerplate. List here domain names.

       mx-target.dom
       .mx-target.dom

  You CAN also list here all POSTMASTER addresses you accept email routed to:

       postmaster@local.domain
       postmaster@client.domain

  these are magic addresses that email is accepted to, even when everything else is blocked.
smtp-policy.spam, smtp-policy.spam.manual

  Those users, and domains that are absolutely no-no for senders, or recipients no matter what earlier analysis has shown. (Except for those senders that we absolutely trust..)

       user@domain
       user@
       domain

  The ``{\tt policy-builder.sh}'' builds this file from external sources.

At the ```smtp-policy.src`'' boiler-plate file there is one particular section containing default setting statements. See figure Figure 12-2 for the salient details concerning this.

Figure 12-2. The `smtp-policy.src` file default settings fragment

    ...
    #|-----------
    #|
    #| Default handling boilerplates:
    #|
    #|   "We are not relaying between off-site hosts, except when ..."
    #|
    #| You MUST uncomment one of these default-defining pairs, or the blocking
    #| of relay hijack will not work at all !
    #|
    #| -- 1st alternate: No MX target usage, no DNS existence verify
    #|    Will accept for reception only those domains explicitely listed
    #|    in ``smtp-policy.mx'' and  ``localnames''  files.  Will not do
    #|    verifications on validity/invalidity of source domains:<foo@bar>
    #
    # .             relaycustomer - relaytarget -
    # [0.0.0.0]/0   relaycustomer - relaytarget -
    #
    #| -- 2nd alternate: No MX target usage, DNS existence verify
    #|    Like the 1st alternate, except will verify the sender (MAIL FROM:<..>)
    #|    address for existence of the DNS MX and/or A/AAAA data -- e.g. validity.
    #
    # .             relaycustomer - relaytarget - senderokwithdns +
    # [0.0.0.0]/0   relaycustomer - relaytarget - senderokwithdns +
    #
    #| -- 3rd alternate: MX relay trust, DNS existence verify
    #|    For the people who are in deep s*...  That is, those who for some
    #|    reason have given open permissions for people to use their server
    #|    as MX backup for their clients, but don't know all domains valid
    #|    to go thru...  Substitutes accurate data to user's whimsical DNS
    #|    maintenance activities.  Vulnerable to inbound MX resource abuse.

    .               relaycustomer - acceptifmx - senderokwithdns +
    [0.0.0.0]/0     relaycustomer - acceptifmx - senderokwithdns +

    #| -- 4th alternate: Sender & recipient DNS existence verify
    #|    This is more of an example for the symmetry's sake, verifies that
    #|    the source and destination domains are DNS resolvable, but does not
    #|    block relaying
    #
    # .             senderokwithdns - acceptifdns -
    # [0.0.0.0]/0   senderokwithdns - acceptifdns -
    #
    #|
    #|  You may also add  ``test-dns-rbl +''  attribute pair to [0.0.0.0]/0 of your
    #|  choice to use Paul Vixie's  http://maps.vix.com/  MAPS RBL system.
    #|
    #| These rules mean that locally accepted hostnames MUST be listed in
    #| the database with ``relaytarget +'' attribute.
    #|
    #|-----------
    ...

Prev | Home | Next
The Queue | Up | Router Configuration