[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

One way to send emails to LAN hosts and to ISP, was Re: Permissions and delivery of LAN email by exim



On Sat 17 Aug 2019 at 07:20:45 (-0000), Curt wrote:
> On 2019-08-16, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> > On Fri, Aug 16, 2019 at 02:20:09PM -0500, David Wright wrote:
> >> AIUI exim should be able to deliver emails into a user's mbox, but
> >> I'm confused about how exim is meant to do that, because it runs as
> >> user Debian-exim, but mailbox permissions are normally group:mail.
> >
> > I don't know much about exim4, but:
> >
> > -rwsr-xr-x 1 root root 1241412 Jul 20 07:35 /usr/sbin/exim4
> >
> > That setuid bit means it *can* become you in order to deliver a message
> > to your inbox.
> >
> 
> That's exactly what the docs say is supposed to happen:
> 
>  Local message deliveries are normally run in processes that are setuid
>  to the recipient, and remote deliveries are normally run under Exim’s
>  own uid and gid.

Sure, but "local" messages are those from hostS to hostS, and
hostR to hostR; not those from hostS to hostR, which are remote.
And that doesn't seem difficult until you realise that with the
smarthost configuration on hostS, either all your email by default
is sent to hostR, or all is sent to your ISP. It's not very useful
to send logwatch reports to debian-user, nor this list's postings
to hostR.

So the question is really: how to set up a host configured to send
email to your ISP's smarthost, but still be able to send emails to
other hosts on the LAN; and BTW not to forward all its received
LAN emails to the ISP. All this has to happen on a LAN that has no
DNS Server at the router (and, of course, no MX records anywhere).

(Note that nothing here involves extra-LAN *incoming* email. The
LAN is firewalled, and all my email from the world is hosted
externally and read through their IMAP server.)

My mistake when I posted the OP was trying to overspecify actions
in /etc/exim4/hubbed_hosts, rather than using the relaying options.
This, plus the fact that the copious exim4 documentation is not
applicable directly to Debian systems, and Debian's own documentation
doesn't seem to cover this case. Debian focuses (justifiably) on
getting email sent out to an ISP smarthost successfully, and (a
little less justifiably) getting emails to internal hosts on
"real" LANs that have MX records.

So there were a few false trails to eliminate in coming up with a
solution that works. Rather than bother with these, I'll just post
my solution, with a few notes to explain my setup (where necessary
for understanding things).
My hostnames/IPs don't mean much to others so I mangled them:
hostS is the host that Sends emails to the Smarthost, and is
IP .5, whereas hostR, .44, is a typical LAN host that's not involved
in extra-LAN email at all.

(However, hostR must be able to send emails to hostS. And my having a
singular hostS is just a personal preference rather than a necessity.)

99% of the configuration information is, as usual, in
/etc/exim4/update-exim4.conf.conf and is presented here. Like so much
Debian configuration, if you edit the file as shown here, then
running   sudo /usr/sbin/dpkg-reconfigure exim4-config   will
show you what to type into the various Q&A screens in order to get
that file content.

So, these are my files. Note:
. The domain name is "corp" and the LAN is a typical 192.168.1.0/24 one.
. My external emails appear to come "From: <localname@my-own-domain.tld>"
  rather than any host on my LAN.
. However, my HELO/EHLO is the LAN host's FQDN, as shown below.
. AIUI the minimaldns setting prevents abortive DNS requests interfering
  with using hubbed_hosts as the resolver instead.
. AFAICT no changes are necessary here if you use things like maildrop:
  exim will use .mailfilter, .forward, etc as it finds them.
. Including   COMMONOPTIONS='-d'   in /etc/default/exim4 will log exim's
  deliveries in /var/log/daemon.log, in *gruesome* detail.

/etc/mailname (on hostS; others are similar, with their own name):

hostS.corp

/etc/exim4/update-exim4.conf.conf (on hostS only):

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='hostS.corp;hostS'
dc_local_interfaces='127.0.0.1 ; ::1 ; 192.168.1.5'
dc_readhost='my-own-domain.tld'
dc_relay_domains=''
dc_minimaldns='true'
dc_relay_nets='192.168.1.0/24'
dc_smarthost='smtp.my-own-domain.tld::12345;smtp.my-ISP.net::587'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

/etc/exim4/update-exim4.conf.conf (on hostR and the other LAN hosts):

dc_eximconfig_configtype='internet'
dc_other_hostnames='hostR.corp;hostR'
dc_local_interfaces='127.0.0.1 ; ::1 ; 192.168.1.44'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='true'
dc_relay_nets='192.168.1.0/24'
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

/etc/exim4/hubbed_hosts (same on all hosts, EXCEPT eliminate each host itself)

hostS:      192.168.1.5         ← not in hostS's version
hostS.corp: 192.168.1.5         ← not in hostS's version
hostR:      192.168.1.44        ← not in hostR's version
hostR.corp: 192.168.1.44        ← not in hostR's version
foo:        192.168.1.31                 etc
foo.corp:   192.168.1.31
bar:        192.168.1.32
bar.corp:   192.168.1.32
baz:        192.168.1.33
baz.corp:   192.168.1.33

/etc/exim4/exim4.conf.localmacros (on hostS, as noted above; optional elsewhere):

# Force the HELO/EHLO used for all mail submission
# MAIN_HARDCODE_PRIMARY_HOSTNAME value will do
REMOTE_SMTP_HELO_DATA=MAIN_HARDCODE_PRIMARY_HOSTNAME

/etc/exim4/passwd.client (on hostS, nothing unusual in here):

smtp.my-own-domain.tld:username@domainname:secret-password
smtp.my-ISP.net:username@domainname:secret-password

Obviously I generate hubbed_hosts automatically from a master copy.
The individual update-exim4.conf.conf files can be generated
similarly.
Annoyingly, dpkg-reconfigure exim4-config   removes world-readability
from update-exim4.conf.conf; no idea why.

Any improvements, particularly simplifications, are welcome.

Cheers,
David.


Reply to: