Configuring a D2S Gateway Server

Enterprise Edition  >  SMTP Gateway Server  >  Configuration

These installation notes describe the basic configuration of a Death2Spam gateway server, running an SMTP filtering service and an HTTP user interface/admin server.

SMTP Gateway/Proxy Server

SMTP server configuration is implemented by modifying the following entries in the config/smtp.config file:

• proxy.smtp.host=<the SMTP server's hostname or domain>
  Note that if this property is empty, the server will bind to the host designated in the system.config file.
• proxy.smtp.port=25 designates the port on which this service listens. If the mail server is started by a non-root user, this port must be above 1024, e.g. 2525. NAT can then be used at the firewall, to translate inbound requests on port 25.
• proxy.smtp.mode=1 causes spam to be "subject-line tagged" during transit. If this property has a value of 2, spam is silently retained on the server, i.e. not forwarded to the destination mail server. With a value of 3, spam is rejected via a 554 response during the DATA transaction (but is ghosted on the D2S server).
• proxy.smtp.max.data.size=10000000 the maximum permitted message size, in bytes (leave empty for no message size restriction).
• proxy.smtp.classifier.maxsize=1000000 classifier maximum message size (larger messages are relayed direct).
• proxy.smtp.create.accounts=true configures the server to automatically create a new user account when inbound (non-spam) mail arrives for an address.
• proxy.smtp.access.scanner=true configures the server to periodically scan the access directory for updated account and alias files.
• proxy.smtp.virus.scanner=true activates probabilistic virus scanning against incoming mail (requires a current virus database).

SMTP Relaying/Forwarding

SMTP relaying/forwarding translations can be effected by adding entries to the smtp-proxy.config file. Fields (columns) within an entry are delimited by white space, and each is terminated by a standard unix or Windows line terminator.

The first field is an email address or domain, representing the RCPT TO entity, the second field is the server to which a message should be forwarded following classification. An optional third field provides for POP server authentication when a user logs into the protected web pages for their account.

Note that if the SMTP server is exposed to the Internet, there should (at least) be a local postmaster account available, routed using, e.g.
    postmaster@death2spam.net   postmaster@death2spam.net

If desired, the routing for all other local mailboxes can be declared using a wildcard entry such as
    death2spam.net   death2spam.net

These local mailboxes can be accessed via POP3 (assuming that service is running), in the normal manner. Local mail accounts must be created prior to use, via the Server Administration screens.

Remote Mail Host Forwarding

Relaying (forwarding) on to domains can be declared using entries such as
    foobar.com   207.44.234.89   pop3.foobar.com

The first column contains the target domain, the second declares the target mail host (as an IP address in this case), and the authenticating POP server is optionally declared in the third field.

Individual mail accounts can be relayed using config entries such as
    uzer.foobar.com@death2spam.net   uzer@foobar.com
which causes inbound messages for the designated recipient to be forwarded after classification to the designated mailbox (in field #2).

Classifier Access Control

The SMTP access directory, optionally located under the application home directory (e.g. d2s/access), holds any Classifier Access Control tables. These are simple ASCII control files, designed to support loose (portable) coupling with customer accounts and billing databases. Such address tables provide an alternative mechanism for improved access control. Note that a D2S gateway server can function perfectly well without them.

The Aliases Table

The SMTP aliases table (access/aliases) holds a list of email address pairs, delimited by white space, one pair per line. For example, an entry like
    abc@foobar.com   xyz@foobar.com
specifies that inbound mail for the abc@foobar.com address will be classified and logged against the xyz@foobar.com D2S user account.

When this user queries their account history, they log into D2S web pages as xyz@foobar.com, and will be able to review mail filtered for abc@foobar.com in the account folders. Aliasing may also be used to collapse multiple email addresses into a single D2S review/training account, while retaining transparent MTA operations.

The aliases table is normally generated automatically from a customer accounts database. This file (if it exists) is regularly scanned to detect whether it has been modified, and is reloaded if necessary.

The Accounts Table

The accounts table (access/accounts) contains email addresses for all the users who are to obtain SMTP gateway filtering from D2S. These files are scanned for a changed last-modification-date every 5 minutes, and reloaded if necessary.

Support for Virtual SMTP Hosts

Domain subdirectories (e.g. "foobar.com") under the access directory provide support for independently controlling access per domain, on a virtual SMTP host basis. The same "aliases" and "accounts" files may exist within such virtual host directories, and (if present) are incorporated into D2S's access control list.

As a convenience, email addresses in a domain's accounts table do not need to be fully-qualified as to realm (since we can assume that the directory declares the domain name), so these entries can take the form of "postmaster" instead of "postmaster@foobar.com".

Configuration

The smtp.config file contains a proxy.smtp.access.scanner flag, which controls whether the access directory is periodically scanned for updated Classifier Access Control files.

Conversely, the proxy.smtp.create.accounts flag, controlling whether the server automatically creates new user accounts, is cleared (set to false) if classification is being controlled via the "accounts" mechanism. Such a configuration dictates that D2S user accounts will only be created for email addresses which exist in the access table(s).