[Pkg-exim4-users] Exim4 home network configuration with smarthost but no local header rewrites
Dave Witbrodt
dawitbro at sbcglobal.net
Fri Mar 13 08:03:06 UTC 2009
At least 2 users have requested details on how I configured my home
network as indicated in the subject line. Instead of burying this
information in other threads, I decided to start a new thread. This may
also make it easier for people to locate it via Google in the future, etc.
Here is a copy of my home network map that I provided in a recent post here:
ISP <--> gateway/router____ desktop
\ \____ fileserver
\______ webserver
This network topology is temporary, and I will be rearranging it soon,
but all of my comments below apply to this arrangement.
In the current topology, I'm pretending that "webserver" is the gateway
to the outside world, even thought the map clearly shows that it is not.
This is in preparation for my final topology. In short, my ISP is the
smarthost for "webserver", and "webserver" is the smarthost for both
"desktop" and "fileserver". All of the Exim configuration steps listed
below apply ONLY to "webserver", then. (I pretty much left the Debian
Exim configuration alone on "desktop" and "fileserver", and just
answered the debconf questions on those machines to set "webserver" as
their smarthost.)
I do not use a DNS server on my home network, so I rely on /etc/hosts
(this file is identical on all 3 machines) to convert these one-word
"domain" names into IP addresses. That works just fine in my case.
The numbered steps below marked with a (*) indicate aggravating hoops I
had to jump through to get Exim4 to connect to my braindead ISP (AT&T)
using a non-standard protocol (SMTPS). These can probably be safely
ignored, unless you also have an ISP using SMTPS. I at least mention
all the changes I made to avoid leaving out something important, but I
leave out most of the details for the AT&T/SMTPS-specific aspects.
OK, here are the settings and changes I used on webserver's Exim
configuration:
*1) My ISP uses a non-standard protocol (SMTPS) unsupported by Exim4
for mail outgoing from my home network to the ISP. As a result, I had
to configure Exim4 to listen for mail on localhost port 25 (fetchmail)
and on the NIC's IP; and it has to send outgoing mail to an unused port
on localhost, in cleartext (!), where all data (handshaking protocols
and actual email) are encrypted using SSL thanks to a Debian package
called 'stunnel4'.
2) I answered the debconf question "Hosts to relay for" (dc_relay_nets)
to my home network's IP range: "A.B.0.0/16". I answered the question
"Domains to relay for" (dc_relay_domains) with the names of the machines
using "webserver" as their smarthost: "desktop;fileserver".
The machines in my network have static IP addresses assigned in the
gateway/router and also configured in /etc/network/interfaces. (For
example, desktop = A.B.0.x, fileserver = A.B.0.y, webserver = A.B.0.z
... these letters are actually numbers, and will most likely be
different from mine on your network, so I'm not providing any numbers at
all.)
*3) I modified my "smarthost" router stanza to allow Exim to send
outgoing mail to the same host (localhost) that Exim is running on (see
note 1), and I modified my "remote_smtp_smarthost" transport stanza to
allow cleartext over a specific port number (note 1). These issues only
affect people who want to use Exim to connect to AT&T (or some other
braindead ISP still using the non-standard SMTPS protocol). I was
hoping to get some help or advice with this here back in January, but no
interest was shown.
*4) I had to set AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS to "true" (note 1)
to make Exim believe it was sending password info in cleartext. (In
reality, all data passes through an SSL tunnel between "webserver" and
my ISP.)
5) I placed username and password for my ISP email account in
/etc/exim4/passwd.client, and I edited /etc/email-addresses so that my
ISP account email address could be used to overwrite my home network
email addresses for mail headed to my ISP.
What follows next is the interesting part -- how I modified the Debian
Exim configuration to rewrite headers for mail leaving my network, but
leave mail staying internal to my network with untouched headers. What
_you_ need to do could vary wildly from my approach since I have a very
small, 3-machine home network... so let the reader beware!
6) I created a new router just before "smarthost:"
home_network_hosts:
debug_print = "R: home_network_hosts for $local_part@$domain"
driver = manualroute
domains = ! +local_domains : +relay_to_domains
transport = remote_smtp
route_list = * $domain byname
same_domain_copy_routing = yes
no_more
This router will match any of the domains for which Exim is supposed to
relay mail (relay_to_domains... meaning "desktop" and "fileserver" in my
case), but it will not match "webserver" (local_domains). If the domain
matches a relay-to domain, then the domain IP is looked up by name (in
/etc/hosts, in my case) using the "remote_smtp" transport. (More about
"remote_smtp" below.)
7) I edited the "smarthost" router to NOT match relay_to_domains (as
well as not matching local_domains):
smarthost:
[...]
domains = ! +local_domains : ! +relay_to_domains
[...]
This means that messages are only sent to my ISP if they did not
originate on "webserver" or "localhost" (local_domains), and they did
not originate on "desktop" or "fileserver" (relay_to_domains).
8) I had to edit REMOTE_SMTP_HEADERS_REWRITE and
REMOTE_SMTP_RETURN_PATH -- this was tricky to work out -- so that
rewriting would happen for local_domains (webserver) and
relay_to_domains (desktop, fileserver). In other words, I wanted Exim
on webserver to rewrite headers on mail (from any of my 3 home network
machines) that is headed to the ISP.
The original macros looked like this:
REMOTE_SMTP_HEADERS_REWRITE=*@+local_domains $1 at DCreadhost frs : \
*@ETC_MAILNAME $1 at DCreadhost frs
REMOTE_SMTP_RETURN_PATH=${if match_domain{$sender_address_domain}\
{+local_domains}{${sender_address_local_part}@DCreadhost}\
{${if match_domain{$sender_address_domain}{ETC_MAILNAME}\
{${sender_address_local_part}@DCreadhost}fail}}}
... and my new versions look like this:
REMOTE_SMTP_HEADERS_REWRITE=*@+local_domains $1 at DCreadhost frs : \
*@ETC_MAILNAME $1 at DCreadhost frs : \
*@+relay_to_domains $1 at DCreadhost frs
REMOTE_SMTP_RETURN_PATH=${if match_domain{$sender_address_domain}\
{+local_domains}{${sender_address_local_part}@DCreadhost}\
{${if match_domain{$sender_address_domain}{ETC_MAILNAME}\
{${sender_address_local_part}@DCreadhost}\
{${if match_domain{$sender_address_domain}{+relay_to_domains}\
{${sender_address_local_part}@DCreadhost}fail}}}}}
9) At this point, since my network is behind a gateway/router with NAT,
the only time "remote_smtp" is used (on "webserver") is when sending
mail from one home machine to another. In that case, I don't want
headers rewritten at all. So I comment out the rewrite code in the
"remote_smtp" transport:
remote_smtp:
debug_print = "T: remote_smtp for $local_part@$domain"
driver = smtp
.ifdef REMOTE_SMTP_HOSTS_AVOID_TLS
hosts_avoid_tls = REMOTE_SMTP_HOSTS_AVOID_TLS
.endif
#.ifdef REMOTE_SMTP_HEADERS_REWRITE
# headers_rewrite = REMOTE_SMTP_HEADERS_REWRITE
#.endif
.ifdef REMOTE_SMTP_RETURN_PATH
return_path = REMOTE_SMTP_RETURN_PATH
.endif
.ifdef REMOTE_SMTP_HELO_FROM_DNS
helo_data=REMOTE_SMTP_HELO_DATA
.endif
(Mail headed outside my network uses another transport:
"remote_smtp_smarthost".)
This has been working for me since January without problems. I took me
about 10 days (off and on) of experimenting to finally get things to
this stage. I use standard mbox on desktop and fileserver; my ISP mail
all stays on webserver in Maildirs, and is served up via IMAP. There
are still some loose strings to tie up, like sorting the incoming mail
using the Exim .forward file (instead of 'procmail'), but that has such
a low priority that I still haven't done anything about it after nearly
3 months!
HTH,
Dave W.
More information about the Pkg-exim4-users
mailing list