bing tech leftist search bofh home prawda security links etext music chemistry feminist guatemala home kaestner news study emu my stuff a/v
Shameless plug für die ÖH-Wahl: GNULI - Open Source und Freeware für die ÖH!
In this day and age, ISPs everywhere turn paranoid, decide they like you even less than ORBS and firewall the hell out of your precious network. You are stuck with a dozen mail and dns Domains, and your buddy outside is all willing to help you out with bandwidth and configuration, but can't give you root on his/her system, much less provide accounts for your zillion users. However reconfiguration of sendmail and BIND are not a problem.
If the scenario above rings a bell, this document is for you. Its aim is to route crucial traffic through, above or below any firewall you should encounter and provide easy-to-use recipes for standard systems and services like sendmail and BIND on debian GNU/Linux.
This recipe assumes you have at least one hole in your firewall you can route your mail through. The most consistent possibility is a cleartext channel over a port other than 25, but any kind of tunnel (rsa-key authenticated ssh tunnels on your external machine, ...) should be possible, although the ipchains-transparent-proxying solution appears to be more elegant as it preserves the IP address of your external MX machine. YMMV.
There are several possible setups, according to how restrictive your firewall is and whether most of the hosts sending you mail are behind the firewall (although mailertable entries at those should enable them to deliver directly to your machine as well).
If you choose to have your internal relay announced by MX and use this unformation in the external relay setup (i. e. don't use the 0 flag in the mailer definition), it is crucial that it have the lowest MX preference number (or at least lower than your relay), or the external machine will probably choke with mail loops. Adding a 0 (don't lookup MXs) to the F= flags equate should prevent this problem, though.
So your DNS Setup should look something like this:
@ 86400 IN MX 10 external.relay.domain.
And if you want to get a chance of receiving mail directly, possibly the following:
IN MX 0 your.server
86400 MX 10 external.relay.domain.
Please note that names not trailed by the . of the root domain are considered relative to your domain, like your.server in the example!
This cookbook recipe assumes at least the following features be present in your sendmail setup:
makemap btree /etc/mail/mailertable < /etc/mail/mailertable
The mailertable syntax is quite straightforward: domain<whitespace>mailer:server<crlf> eg
yourdomain portmixsmtp986:your.host.yourdomain
if you use ssh for tunneling, of course you'll have to replace your.host.yourdomain with the ssh tunneling origin.
Mportmixsmtp986, P=[IPC], F=mDFMuXa08, S=11/31, R=21, E=\r\n, L=2040, T=DNS/RFC822/SMTP, A=IPC $h 986
relay> grep ^FR /etc/mail/sendmail.cf FR-o /etc/mail/relay-domains %[^\#]
This assumes that you have access to the m4 source directories (probably a valid assumption, since they most likely won't have more restrictive permissions than the sendmail.cf you are hacking) and willing to make modifications to it. If one of the assumptions does not hold true skip to the sendmail.cf modification section, which however won't work unless you have the mailertable feature (grep for it in sendmail.cf ... if you know how to modify ruleset 0 without the need for the mailertable rules this document probably isn't for you anyways <g>).
Update: if you have transparent proxying enabled on your external mail relay, you could can all mailertable and portmix-peculiarities (at least if your internal host is configured as lowest priority mx, otherwise you would at least have to declare an esmtp or relay mailer for the domain) and redirect with an ipchains rule (thx hvr):
ipchains -A input -d your.hosts.ipaddress/255.255.255.255 25 -p tcp -j REDIRECT 986
grep for mailertable in your sendmail.cf (or make sure the domain to be tunneled is routed to your special mailer in ruleset 0 or ipchains-redirected to the correct port of your real, lowest priority MX), copy the esmtp mailer to portmixsmtp986 (lines starting with M are mailers) and add 0 to the flags if you decided not to make your real mailhost the lowest number MX, then add the port number (986 in this example) as the third argument to the argv A= equate (traditionally the last equate, although sendmail 8.8 and above would allow it to be inserted anywhere in the line)
Assure that your host receives mail on the appropriate port. If your external host has a ssh tunnel to your internal machine, no special configuration is needed. If you do not intend to receive mail on port 25, you can just insert the following line in your sendmail.cf:
ODaemonPortOptions=Port=987
However, afaik sendmail does not honor multiple port equates, so you would lose regular email connectivity doing this (recent sendmail versions might have corrected this).
Probably the most elegant solution is transparent proxying. You must use linux and have your kernel configured with CONFIG_FIREWALL=y, CONFIG_IP_FIREWALL=y and CONFG_IP_TRANSPARENT_PROXY=y for this to work and execute the following command (make sure this rule is also installed at system startup, eg in the network startup script or rc.local):
ipchains -A input -p tcp -d 0.0.0.0/0 986 -j REDIRECT 25
This has the advantage that the IP address of your external relay is preserved over solutions like forwardd/proxyd etc in your inetd.conf.
To reliably test this setup, make sure mails don't pass over regular port 25. You can either firewall this port using e. g. ipchains, or sniff the wire on either side to detect the ports used:
(on the external host)
ipchains -A output -s 0/0 -d your.hosts.ipaddress/255.255.255.255 25 -p tcp -j DENY
(on your firewalled mail exchanger)
ipchains -A input -s external.relay.domain/255.255.255.255 -d 0/0 25 -p tcp -j DENY
- or -
tcpdump ( host your.host.yourdomain or external.relay.domain ) and ( port 25 or 986 )