[Pkg-exim4-users] smtps support in Stretch

Discussion:

Gary Dale

2016-04-11 00:23:52 UTC

I'm running stretch on and AMD64 system and an old problem resurfaced.
My ISP uses smtps on port 465 for encrypted smtp connections. I had
solved this a year ago by adding "protocol = smtps" to
/etc/exim4/exim4.conf.template and reconfiguring. However this now
doesn't seem to work.

According the Exim wiki at
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html,
I should be adding instead the line
tls_on_connect_ports = 465

but that doesn't seem to be helping. Mail still shows as frozen in the
queue.

I'm not sure at what point Exim4 stopped working because I don't use the
mail command very often.

The Debian documentation at https://wiki.debian.org/GmailAndExim4
suggests that I add the protocol line to
30_exim4-config_remote_smtp_smarthost in /etc/exim4/conf.d/transport,
which seems odd. I thought those would be overwritten when Exim4 is
reconfigured but after trying it, it doesn't seem to be happening - even
when I split the config into small files as per dpkg-reconfigure
exim4-conf. However it also didn't work - just like it didn't work a
year ago when I also tried it.

Any ideas?

Gary Dale

2016-04-12 18:26:07 UTC

Permalink

Hi
On Sun, 10 Apr 2016 20:23:52 -0400

Post by Gary Dale
I'm running stretch on and AMD64 system and an old problem resurfaced.
My ISP uses smtps on port 465 for encrypted smtp connections. I had
solved this a year ago by adding "protocol = smtps" to
/etc/exim4/exim4.conf.template and reconfiguring. However this now
doesn't seem to work.
According the Exim wiki at
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html,
I should be adding instead the line
tls_on_connect_ports = 465
but that doesn't seem to be helping. Mail still shows as frozen in the
queue.

No, that is for _receiving_ mails.

Post by Gary Dale
I'm not sure at what point Exim4 stopped working because I don't use
the mail command very often.
The Debian documentation at https://wiki.debian.org/GmailAndExim4
suggests that I add the protocol line to
30_exim4-config_remote_smtp_smarthost in /etc/exim4/conf.d/transport,
which seems odd. I thought those would be overwritten when Exim4 is
reconfigured but after trying it, it doesn't seem to be happening -
even when I split the config into small files as per dpkg-reconfigure
exim4-conf. However it also didn't work - just like it didn't work a
year ago when I also tried it.
Any ideas?

Look in your logs and _show_ us the actual problem.
What you said first should still work, btw, so it’s either a different
issue or you are doing something wrong.
Good luck
henk

Thanks Henk. Here's the entries in the mainlog:

2016-04-12 10:31:02 1apzLK-0005Sf-U8 <= ***@primus.ca U=root
P=local S=2277
2016-04-12 10:31:03 1apzLK-0005Sf-U8 ** ***@primus.ca R=smarthost
T=remote_smtp_smarthost: retry time not reached for any host after a
long failure period
2016-04-12 10:31:03 1apzLK-0005Sf-U8 ** -***@rahim-dale.org R=smarthost
T=remote_smtp_smarthost: retry time not reached for any host after a
long failure period
2016-04-12 10:31:03 1apzLK-0005Sf-U8 ** ***@rahim-dale.org R=smarthost
T=remote_smtp_smarthost: retry time not reached for any host after a
long failure period
2016-04-12 10:31:03 1apzLL-0005Si-1Z <= <> R=1apzLK-0005Sf-U8
U=Debian-exim P=local S=3877
2016-04-12 10:31:03 1apzLK-0005Sf-U8 Completed
2016-04-12 10:31:03 1apzLL-0005Si-1Z ** ***@primus.ca R=smarthost
T=remote_smtp_smarthost: retry time not reached for any host after a
long failure period
2016-04-12 10:31:03 1apzLL-0005Si-1Z Frozen (delivery error message)

The message is being sent via the listmail account to my garydale
account (both with Primus.ca).

Here is my update-exim4.conf.conf:

dc_eximconfig_configtype='satellite'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1'
dc_readhost='rahim-dale'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='smtp.primus.ca::465'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

Gary Dale

2016-04-12 20:05:59 UTC

Permalink

Post by Gary Dale
P=local S=2277
T=remote_smtp_smarthost: retry time not reached for any host after a
long failure period
T=remote_smtp_smarthost: retry time not reached for any host after a
long failure period
T=remote_smtp_smarthost: retry time not reached for any host after a
long failure period
2016-04-12 10:31:03 1apzLL-0005Si-1Z <= <> R=1apzLK-0005Sf-U8
U=Debian-exim P=local S=3877
2016-04-12 10:31:03 1apzLK-0005Sf-U8 Completed
T=remote_smtp_smarthost: retry time not reached for any host after a
long failure period
2016-04-12 10:31:03 1apzLL-0005Si-1Z Frozen (delivery error message)

This basically says "I has not been working for a long time, so I'm
not going to even try". We need to see the log entries after the last
successful messages.
That being said, Google makes it really hard to use their services
with a fully-fledged Unix MTA. They don't seem to want that kind of
usage.
Greetings
Marc

Don't have any logs of it working. The oldest one still around just
shows frozen messages. I mainly use this for some system messages, not
daily use. However I can send messages through the same remote server
using Icedove.

I'm not using Google for this. The remote smarthost is Primus.

Gary Dale

2016-04-12 21:44:15 UTC

Permalink

Post by Gary Dale
Don't have any logs of it working. The oldest one still around just
shows frozen messages. I mainly use this for some system messages, not
daily use. However I can send messages through the same remote server
using Icedove.

Try exim -qf to force delivery and show more logs. Recommended reading
also spec.txt, the chapter titled "how exim delivers mail", and/or
README.Debian.gz, Chapter 2.2.1, titled "Exim 4 as TLS/SSL client",
saying "TLS on connect is not natively supported." As long as upstream
doesn't change this, the Debian package is unlikely to change as well.
Greetings
Marc

Remembered I had a Jessie server running exim4. While it's got a lot of
frozen messages in the queue, it seems to be working so I looked at the
differences and modified update-exim4.conf.conf to fit. There were three
differences. Here are the lines after I changed them and successfully
sent a test e-mail:

dc_eximconfig_configtype='internet'
dc_other_hostnames='transponder.rahim-dale; transponder'
dc_local_interfaces='127.0.0.1; ::0'

I don't think the first line was important and I'm not sure what the ;
::0 does in the third line. Possibly it's the dc_other_hostnames that
did the trick?

Gary Dale

2016-04-12 22:08:41 UTC

Permalink

Post by Gary Dale

Remembered I had a Jessie server running exim4. While it's got a lot of
frozen messages in the queue, it seems to be working so I looked at the
differences and modified update-exim4.conf.conf to fit. There were three
differences. Here are the lines after I changed them and successfully
dc_eximconfig_configtype='internet'
dc_other_hostnames='transponder.rahim-dale; transponder'
dc_local_interfaces='127.0.0.1; ::0'
I don't think the first line was important and I'm not sure what the ;
::0 does in the third line. Possibly it's the dc_other_hostnames that
did the trick?

Spoke too soon. After one successful message, all subsequent messages
seem to be stuck in the queue. They aren't frozen (yet). I can still
send mail through Jessie (same local network, same sender account, same
remote server) but now the messages aren't going through on my Stretch box.

Gary Dale

2016-04-13 04:38:48 UTC

Permalink

Post by Gary Dale

Remembered I had a Jessie server running exim4. While it's got a lot of
frozen messages in the queue, it seems to be working so I looked at the
differences and modified update-exim4.conf.conf to fit. There were three
differences. Here are the lines after I changed them and successfully
dc_eximconfig_configtype='internet'
dc_other_hostnames='transponder.rahim-dale; transponder'
dc_local_interfaces='127.0.0.1; ::0'
I don't think the first line was important and I'm not sure what the ;
::0 does in the third line. Possibly it's the dc_other_hostnames that
did the trick?

Figured out why only some messages are getting through. Messages that go
to another primus.ca account are working but not ones that go to a
different domain. Any ideas on how to correct that?

Gary Dale

2016-04-13 13:43:00 UTC

Permalink

Post by Gary Dale
Figured out why only some messages are getting through. Messages that go
to another primus.ca account are working but not ones that go to a
different domain. Any ideas on how to correct that?

I can just guess that you're not authentication and your SMTP server
is also MX for primus.ca and is thus accepting mail for primus.ca
without authentication.
This is my last answer for you until you have at least tried to give
more information other than "it doesn't work". Googling for "esr smart
questions" might help.
Greetings
Marc

Here's the log entries for sending two message - one to a primus.ca
account which worked and one to a different domain. Both are valid
e-mail addresses.

2016-04-13 09:15:27 1aqKdj-0007Qm-Po <= ***@primus.ca U=garydale
P=local S=397389
2016-04-13 09:15:27 1aqKdj-0007Qq-QC <= ***@primus.ca U=garydale
P=local S=397387
2016-04-13 09:15:33 1aqKdj-0007Qm-Po == ***@dalefamily.org R=dnslookup
T=remote_smtp defer (-44) H=mx2.r4l.com [192.99.3.191]: SMTP error from
remote mail server after RCPT TO:<***@dalefamily.org>: 450 4.7.1 Client
host rejected: cannot find your hostname, [108.63.184.104]
2016-04-13 09:15:33 1aqKdj-0007Qq-QC => ***@primus.ca R=dnslookup
T=remote_smtp H=primus.ca.inbound10.mxlogic.net [208.65.145.3]
X=TLS1.2:RSA_AES_128_GCM_SHA256:128 CV=no
DN="C=US,postalCode=75024,ST=TX,L=Plano,street=5000 Headquarters
Dr,O=McAfee\, Inc.,OU=IT,OU=Hosted by McAfee Inc.,OU=PlatinumSSL
Wildcard,CN=*.mxlogic.net" C="250 Backend Replied
[0764e075.0.13311539.00-1939.25532478.s12p02m065.mxlogic.net]: OK
id=1aqKdo-0003qG-Jj (Mode: norma"
2016-04-13 09:15:33 1aqKdj-0007Qq-QC Completed

J G Miller

2016-04-13 14:23:52 UTC

Permalink

At 09:43h, on Wednesday, April 13, 2016,
in message <***@torfree.net>,
on the subject of "Re: [Pkg-exim4-users] smtps support in Stretch",

450 4.7.1 Client host rejected: cannot find your hostname, [108.63.184.104]

Well that would appear to be your problem -- the remote mail service is
refusing to accept your mail because it looks like it is trying a
reverse name look up on 108.63.184.104 and failing, even though

host 108.63.184.104

104.184.63.108.in-addr.arpa domain name pointer host-108-63-184-104.static.primus.ca.

See

<http://serverfault.com/questions/654462/450-4-7-1-client-host-rejected-cannot-find-your-hostname>

Also for exim4 configuration for SSL connecton upstream you should have a look at

<http://askubuntu.COM/questions/167043/how-do-i-configure-exim4-to-send-mail-through-a-password-protected-ssl-smtp-mail>

especially if your ISP provided e-mail server allows use of port 587 as well as 465.

Gary Dale

2016-04-13 14:01:23 UTC

Permalink

The same behaviour seems to be happening on Jessie as well. The change
happened in mid September, 2015. The last e-mail my Jessie server
successfully sent was September 17, 2015 but I only check for/install
updates weekly.

Gary Dale

2016-04-13 13:51:05 UTC

Permalink

Post by Gary Dale

Remembered I had a Jessie server running exim4. While it's got a lot of
frozen messages in the queue, it seems to be working so I looked at the
differences and modified update-exim4.conf.conf to fit.

Exim 4 has never supported tls-on-connect as a client, upstream-wise.
This mechanism has never been part of any standard and is not up to
today. Providers who demand that their customers use this are
violating internet standards.

Agreed about smtps but apparently the practice is quite common. However
Exim4 does support tls-on-connect according to the docs at exim.org.
Notably at
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html,
part 1 tells you how to do it. There is even a tls_on_connect_ports
config option.

Post by Gary Dale
There were three differences. Here are the lines after I changed them
dc_eximconfig_configtype='internet'
dc_other_hostnames='transponder.rahim-dale; transponder'
dc_local_interfaces='127.0.0.1; ::0'
I don't think the first line was important

No, it's totally unimportant. It just chooses the major mode of
operation of your Exim.
Did you ready any of the fine docs we prepare in the package?

Yes but they don't really help when you're a non-expert trying to make
something work. I think this goes double for when you are trying to make
something work that is non-standard.

Post by Gary Dale
and I'm not sure what the ;
::0 does in the third line. Possibly it's the dc_other_hostnames that
did the trick?

Without showing any useable logs, there is no way to judge that.
Nothing of your config snippets has anything to do with TLS operation
as a client.

J G Miller

2016-04-13 15:22:01 UTC

Permalink

At 16:35h, on Wednesday, April 13, 2016,
in message <***@torres.zugschlus.de>,
on the subject of "Re: [Pkg-exim4-users] smtps support in Stretch", you wrote -

The information that this is for exim as a _server_ , when it is
_receiving_ mail, has been given to you in this thread at least twice.

Notwithstanding, in my insignificant opinion, Exim4 configuration and documents
could be greatly improved by the naming of parameters to reflect their role in
being used by Exim4 in a client (sending to another MTA) role or in a server
(receiving from another MTA) role.

When I did my configuration for the first time I was certainly confused and
mistaken over whether some TLS parameter was for sending or receiving,
eg tls_cerficate refers to the local host certificate but tls_verify_certificates
refers to the certificate of the remote host. This could be made immediately
obvious with names like tls_local_certificate and tls_remote_verify_certificates.

Confusion about tls_on_connect could be eliminated by renaming to something like
tls_on_incoming_connection.

Perhaps the Debian macro (uppercase) names could be made more obvious
by a suitable rename with appropriate "part-prefix" where appropriate?

As the question of host name lookups as come up again, may I tangentially
inquire if any consideration has been given to lobbying for Exim4 to change
from the obsolete gethostbyname to getaddrinfo, as mentioned some months ago?