1

As described in the title. If mydomain.com is THE local domain, why would exim attempt delivering mail by contacting it, rather than just storing it in a local mbox? I.e. when I do echo hello | mail root, it sends an email to [email protected] by contacting an MX listed in mydomain.com. The configs are the default Debian stable.

Incidentally, this behavior is what I actually want, as mydomain.com uses Google Apps, so I want all mail to be delivered to an MX listed there, but I also want a server of mine to behave like it's its own name too (i.e. its locally sent mail should be from @mydomain.com). Should I be configuring exim differently then?

2 Answers 2

1

Exim doesn't necessarily assume any magic about your system - it will route exactly where you tell it to.

That said, a default configuration file will normally populate the local_domains domain list with the value of @, which simply means "The domain name of this host". Then, later on, the dnslookup router might specifically exclude local domains by saying domains = ! +local_domains, which would prevent any mail addressed to a domain listed in local_domains to not be forwarded remotely over SMTP.

To troubleshoot your issue, I'd look in two places. Firstly, although you may have /etc/mailname populated, that doesn't mean that the @ value in the exim config is being expanded to the correct local domain name. Check that you've got the right fqdn listed in /etc/hosts and that dnsdomainname (I think that exists on Debian) returns what you expect.

Secondly, I'd double-check the exim config, following all the routers in order through to the transports and make sure nothing is missing.

0

I had exactly the same issue as the OP - I was trying to work out why Exim was treating all local deliveries (ie messages generated by cron for example destined for a local mail box, or the output of 'echo "test" | mail ') as non-local.

Typical log entries from a command like:

echo "test" | mail userfoo

would look like:

2013-03-20 12:44:02 1UIIN7-0004t9-8R <= [email protected] H=localhost (hostname.example.com) [127.0.0.1] P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256 S=811 [email protected]

when they should simply look like:

2013-03-20 17:49:17 1UIN8X-0005iz-4Y <= [email protected] U=root P=local S=323

In my case the issue was with the way my mail wrapper was configured - on my OS - FreeBSD - you configure the mail wrapper in /etc/mail/mailer.conf, and I had neglected to change the various 'aliases' within that file to use Exim instead of the default sendmail binary. As a result I think the issuing of mail commands on the commandline meant the sendmail binary was being used instead of exim, resulting in a delivery attempt via ESMTP rather than local piped delivery.

Changing the mail wrapper config file /etc/mailer.conf from:

sendmail        /usr/libexec/sendmail/sendmail
send-mail       /usr/libexec/sendmail/sendmail
mailq           /usr/libexec/sendmail/sendmail
newaliases      /usr/libexec/sendmail/sendmail
hoststat        /usr/libexec/sendmail/sendmail
purgestat       /usr/libexec/sendmail/sendmail

to:

sendmail          /usr/local/sbin/exim
send-mail         /usr/local/sbin/exim
mailq             /usr/local/sbin/exim -bp
newaliases        /usr/bin/true

had the desired effect of replacing sendmail as the default mailer binary for local deliveries. Bit of a school boy error really, I remember that being one of the first things I'd changed back when I first set up Exim 5-10yrs ago on FreeBSD, but since then haven't had any need to mess around with it!

Hope it helps someone anyway, this was about the only result that exactly covered my issue.

Cheers.

References:

Replacing another MTA with Exim

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .