Re: [exim] Configuring exim to use an non-TLS connection to …

Top Page
Delete this message
Reply to this message
Author: Jeremy Harris
Date:  
To: exim-users
Subject: Re: [exim] Configuring exim to use an non-TLS connection to port 587.
On 11/04/2023 17:43, Peter via Exim-users wrote:
> Hello again,
>
> In absence of progress to have exim apply TLS-on-connect to server port
> 465 I'm trying non-TLS to port 587 as a simpler first objective.  =8~/
>
> Configuration specifications of the server are here.
> https://islandhosting.com/knowledgebase/21/How-do-I-configure-my-email-client.html
>
> This is the result of "dpkg-reconfigure exim4-config".
>
> $ tail -n 15 /etc/exim4/update-exim4.conf.conf
> # This is a Debian specific file
>
> dc_eximconfig_configtype='smarthost'
> dc_other_hostnames=''
> dc_local_interfaces='127.0.0.1'
> dc_readhost='easthope.ca'
> dc_relay_domains=''
> dc_minimaldns='false'
> dc_relay_nets=''
> dc_smarthost='158.69.159.172::587'
> CFILEMODE='644'
> dc_use_split_config='false'
> dc_hide_mailname='true'
> dc_mailname_in_oh='true'
> dc_localdelivery='mail_spool'
> $
>
> The consequent eximdebug.txt is here.
> http://easthope.ca/eximdebug.txt
>
> I noted this line.
> 20:33:40  1656 read response data: size=213
> The lines following it suggest the server attempts to apply STARTTLS
> whereas the instructions on the Web page cited above are "Non-SSL
> Settings ... SMTP Port: 587".  What is the reality?


A little before that line:

    20:33:40  1656 158.69.159.172 in hosts_avoid_tls? no (option unset)
    20:33:40  1656   SMTP>> STARTTLS


The transport checked it's option "hosts_avoid_tls" and found nothing set.
So it tried to use STARTTLS. If you don't want it to even try
(and then fallback to plaintext), then you need somthing in that option.
If you're only ever talking to this smarthost, it could even be "*" to
have that apply to all target hosts.

Whether or not the Debian configurator has a way of doing that for you
I don't know.


> What is the crux of failure?


20:33:41 1656 TLS: checking peer certificate
20:33:41 1656 TLS certificate verification failed: cert name mismatch
20:33:41 1656 TLS session fail: (certificate verification failed)

- they presented a server certificate that we don't like; specifically,
the list of systems that are supposed to use the cert did not include
the name we think the server has (the one we made a TCP connection to).
It's possible to turn that security check off, and you might have to
in order to get a TLS connection to this provider (either STARTTLS or
TLS-on-connect).





However, your debug run did continue with a plaintext attempt after
failing on the STARTTLS, and we see

20:33:41 1656 158.69.159.172 in hosts_require_auth? no (option unset)

- which seems bogus given your provider's need for login/password authentication

followed by

    20:33:41  1656   failed to expand "<; ${if exists{/etc/exim4/passwd.client} {${lookup{$host}nwildlsearch{/etc/exim4/passwd.client}{$host_address}}}{} }" while checking a list: failed to open /etc/exim4/passwd.client for linear search: Permission denied (euid=106 egid=113)


- which is clearly an error that needs fixing, and should be self-explanatory apart from
"euid" and "egid" which are the values of user and group that the exim transport process was
operaing as at the time of trying to open that file. Check the file permissions,

I would guess that this file is created by the Debian configurator, but I don't
know that. If it was, then it should just work with their config, unless someone
has manually fiddled with things.

>
> FOOTNOTE
> In the transcript, eximdebug.txt, the direction of transmission is
> unclear.  A common notation is "c:" indicating client transmission and
> "s:" indicating server transmission. It would add only 2 or 3
> characters per line while removing uncertainty.  =8~)


The debug from exim uses "SMTP>>" to say "I sent this" - eg:

    20:33:40  1656   SMTP>> EHLO imager.hitronhub.home


and it uses "SMTP<<" to say "I received this" - eg:

    20:33:40  1656   SMTP<< 250-hornby.islandhosting.com Hello s0106a84e3f6ccb23.gv.shawcable.net [24.108.14.249]



Separately:
Given what your presentation of the debug output to us has done with the UTF-8
content (as I mentioned before), you might want to experiment with the debug option "+noutf8"
so that ascii-art is used instead.
--
Cheers,
Jeremy