On 2019-11-28 1:59 p.m., Gary Dale via Exim-users wrote: >
> On 2019-11-28 1:28 p.m., Adam D. Barratt wrote:
>> On Thu, 2019-11-28 at 14:00 +0000, Andrew C Aitchison via Exim-users
>>> On Thu, 28 Nov 2019, Gary Dale via Exim-users wrote:
>>>> It looks like the remote smarthost thinks I'm not using TLS.
>>> No. TLS is about encryption. The 1iaJ5F-00053v-JS log says that the
>>> remote smarthost thinks you are not *authenticating* (which should,
>>> but may or may not be, encrytped).
>> Given the configuration in the original mail, this is likely due to the
>> fact that mail.rossland.dental is a CNAME, and reverse DNS for the
>> eventual target resolves to "web152.dnchosting.com".
>> Debian's Exim packaging describes the use of the passwd.client file in
>> exim4-config-files(5), which in part says (with apologies for the
>> longish quote):
>> Please note that target.mail.server.example is currently the value
>> that exim can read from reverse DNS: It first follows the host name of
>> the target system until it finds an IP address, and then looks up the
>> reverse DNS for that IP address to use the outcome of this query (or
>> the IP address itself should the query fail) as index into
>> This goes inevitably wrong if the host name of the mail server is a
>> CNAME (a DNS alias), or the reverse lookup does not fit the forward
>> Currently, you need to manually lookup all reverse DNS names for all IP
>> addresses that your SMTP server host name points to, for example by
>> using the host command.
>> You may minimize this trouble by using a wild card entry or
>> regular expressions, thus reducing the risk of divulging the password
>> to the wrong SMTP server while reducing the number of necessary
>> lines. For a deeper discussion, see the Debian BTS #244724.
>> Thus, the hostname in passwd.client wants to be web152.dnchosting.com,
>> not mail.rossland.dental. (Or potentially a regex or wildcard if the
>> "152" is expected to change.)
> I'm aware of that issue and therefore have my passwd.client file
> provide credentials for both *.dnchosting.com and *.rossland.dental.
> I finally figured it out by checking an error message that I'm getting
in the exim4 log lately. Apparently Exim4 keeps some files in
/var/spool/exim4/db that were keeping e-mail from even attempting to be
sent. Clearing the directory allowed mail to proceed.
This message was posted to the following mailing lists: