This is my setup for mail to/from my ITS system. It depends on having an external “hardened” mail server around, but requires minimal changes to the ITS mail server. You will have to adapt it to your system.

I take no responsibility for any problems you get by using my advice below, but please let me know so I can update it!

• ITS runs on a Fedora Core Linux host, with the IMP device using a tunnel interface to Linux.
• I use the same name for both the Linux host and the ITS system. (The configuration is probably easier if you have separate names.)
• The Linux host runs the Postfix mailer.
• There is an external “hardened” mail server which handles spam/relaying/viruses etc. If you don't, you can make “shortcuts” in the configuration below, but you will want to harden your Postfix configuration.
• I'm friends with the mail and domain administrators.

NOTE: Below, all occurrences of xy should be replaced with your host name, and its.os.org should be replaced with your domain. my.external.mail.server and aaa.bbb.ccc.ddd should be replaced with the name and address of your external mail server.

1. Don't open the firewall to ITS mailer
2. Name tunnel interfaces (at both ends)
3. Configure COMSAT
4. Configure Postfix
5. Configure MX and external mail server
6. Open firewall for external mail server

Do not open the firewall to allow general external access to the ITS mail server (COMSAT). COMSAT was written back in the days before spam, viruses and the abuse of poorly configured mail servers to forward spam, viruses etc. If you let just anyone connect, you will quickly be overloaded with requests to forward spam and viruses, which COMSAT will (try to) do, and you risk being shut down by your ISP or similar.

Supposing the ITS end of the tunnel has address 192.168.0.203 and the Linux host end has address 192.168.0.200, you need

in SYSHST;H3TEXT

1. add the ITS address to the ITS host,
2. add the alias ITS-XY.ITS.OS.ORG to the ITS host (probably not needed if you have separate names for Linux and ITS systems)
3. add an entry for the Linux host, e.g.

           HOST : 192.168.0.200 : ITS-GW.ITS.OS.ORG : PC : LINUX : : 

4. run SYSHST;H3MAKE BIN to compile the host table to binary format.

in /etc/hosts on the Linux host

1. add an entry for the ITS end of the tunnel, e.g.

       192.168.0.203    its-xy.its.os.org 

You have probably already done this, as described in distrib.its:

• Set TCPGAT to 192.168.0.200. This is where all non-Chaos mail is sent.
• Set DOMGAT to 192.168.0.200. This is where all mail is sent for which ITS can't find the address. (Mail will be sent to TCPGAT, but this address is what gets noted as the relay; see rewrites below.)

These are the changes I needed to do to the default Postfix configuration in Fedora Core.

inet_interfaces = all

By default it only listens on localhost, but now we need it to accept connections from both ITS (on the tunnel interface) and from the external mail host (on an ethernet interface)

mydestination = ..., its-gw.its.os.org

You need to add the name the ITS system uses for the Linux end of the tunnel.

mynetworks = aaa.bbb.ccc.ddd/32, 192.168.0.203/32

Only accept connections from the ITS system and from the external mail server, whose address is aaa.bbb.ccc.ddd.

relayhost = my.external.mail.system

Outgoing mail should be sent to (the MX of) my.external.mail.server

transport_maps = hash:/etc/postfix/transport

The file needs to contain a line saying to send mail to the ITS system directly, not through $relayhost. See below.

canonical_maps = regexp:/etc/postfix/canonical

We need to do some rewriting of what COMSAT uses for mail addresses. See below.

local_header_rewrite_clients = static:all

needed to make canonical_maps work in Postfix 2.2 and newer (see documentation).

alias_maps = ..., hash:/etc/postfix/its-aliases

This file is where you list all valid ITS mail addresses. You can maybe use another directive to simply send everything Linux doesn't know about to ITS:

    luser_relay = $local@its-xy.its.os.org

which is easier to administer (since you don't forget to add new users/addresses in the file), but may also have disadvantages:

• You have to set local_recipient_maps = (empty)
• You may get a lot of junk mail to ITS
• ITS may handle this junk in a less efficient and secure way than Linux?

header_checks = regexp:/etc/postfix/header_checks

IF you have an external spam filter (e.g. spamassassin) running on my.external.mail.system, this seems to be the easiest way of filtering it out. See below.

its-xy.its.os.org smtp:[its-xy.its.os.org]

This tells Postfix to send mail directly to ITS, rather than through $relayhost.

/^"(.+@.+)"@its-gw.its.os.org/i ${1}

COMSAT sends mail to e.g. Bjorn.Victor@it.uu.se to “Bjorn.Victor@it.uu.se”@ITS-GW.ITS.OS.ORG, which here gets rewritten to just the thing within the quotes. The same goes for sender addresses, e.g. COMSAT@XY.ITS.OS.ORG becomes “COMSAT@XY.ITS.OS.ORG”@ITS-GW.ITS.OS.ORG.

If you figure out why ITS does this silly thing, and how to avoid it, please let me know! The “…”@ITS-GW… appears also on the ITS end, e.g. in local CC copies of the mail.

Add a line

foo:  foo@its-xy.its.os.org

for each valid mail address foo on the ITS system. Run postalias /etc/postfix/its-aliases when you've edited the file.

If you added the header_checks line to main.cf, then here add the lines

/^X-Spam-Level:[[:space:]]+\*\*\*\*\*\*\*/
  DISCARD Spam level 7 or above detected

to filter spamassasin level 7 and above (adjust as you like).

You need to tell the world how to deliver email to your ITS system. This is done by adding an MX record to the DNS entry for your host pointing at the “hardened” external mail server, e.g.

XY MX 0 my.external.mail.server.

That makes the external mail server the “end delivery point” of mail to your system, so you need to configure the external mail servert so it delivers mail the next step, to your Linux host. If it's a Postfix system, the transport_map is the right place.

It probably works just as well to have two MX records, one primary to your Linux host and a secondary (with a higher preference value) to the external mail server. Since external systems (except for the mail server) cannot connect to your SMTP server, mail will be sent to the external mail server, which will automagically forward it to your Linux host.

Finally, when everything is configured, your Linux host needs to open the firewall to let the external mail server connect to the SMTP port on your Linux system (not the ITS system!). With iptables, do

iptables -I RH-Firewall-INPUT -s aaa.bbb.ccc.ddd -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT

(replacing the chain name if necessary).

NOTE that if you allow other external hosts to connect to your SMTP server, you will want to harden it.