[Pkg-exim4-users] configuring exim4 smtp to use SSL

Discussion:

Gary Dale

2015-03-16 03:20:38 UTC

I'm running a Wheezy/64 server and am trying to get exim4 to send e-mail
using an SSL connection. My current configuration works when I use their
normal smtp port (which is 26, not 25) but fails when I use their
smtp/SSL port (465).

However Thunderbird is able to send e-mail from workstations to the same
server using port 465 and have SSL/TLS identified as the connection
security.

My update-exim4.conf.conf file is (replacing <remote host name> with the
actual name). If dc_smarthost has the port set to 26, mail gets sent.
However with it set to 465, it stays in the mailq.

dc_eximconfig_configtype='smarthost'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1'
dc_readhost='<remote host name>'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='<remote host name>::465'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

I did add tls_on_connect_ports = 465 to exim4.conf.localmacros, which is
supposed to cover the SSL on connect issue.

The log for an unsuccessful mail says:
2015-03-14 00:47:44 1YWdzE-0000l6-CR <= <sending e-mail address>
U=garydale P=local S=1665
2015-03-14 00:47:44 1YWdzE-0000l6-CR ** -***@localhost: Unrouteable address
2015-03-14 00:47:44 1YWdzE-0000l6-CR ** ***@extremeground.com
R=smarthost T=remote_smtp_smarthost: retry time not reached for any host
after a long failure period
2015-03-14 00:47:44 1YWdzE-0000l6-CR ** <sending e-mail address>
R=smarthost T=remote_smtp_smarthost: retry time not reached for any host
after a long failure period
2015-03-14 00:47:44 1YWdzE-0000lB-Ik <= <> R=1YWdzE-0000l6-CR
U=Debian-exim P=local S=2720
2015-03-14 00:47:44 1YWdzE-0000lB-Ik ** <sending e-mail address>
R=smarthost T=remote_smtp_smarthost: retry time not reached for any host
after a long failure period
2015-03-14 00:47:44 1YWdzE-0000lB-Ik Frozen (delivery error message)
2015-03-14 00:47:44 1YWdzE-0000l6-CR Completed

I use /etc/email-addresses to change garydale to <sending e-mail
address>. Otherwise the e-mail just bounces.

When I change to port 26 and leave everything else the same, the mail
goes through.

Any ideas?

Gary Dale

2015-03-16 14:54:41 UTC

Permalink

Post by Gary Dale
2015-03-14 00:47:44 1YWdzE-0000l6-CR <= <sending e-mail address>
U=garydale P=local S=1665
R=smarthost T=remote_smtp_smarthost: retry time not reached for any
host after a long failure period
2015-03-14 00:47:44 1YWdzE-0000l6-CR ** <sending e-mail address>
R=smarthost T=remote_smtp_smarthost: retry time not reached for any
host after a long failure period
2015-03-14 00:47:44 1YWdzE-0000lB-Ik <= <> R=1YWdzE-0000l6-CR
U=Debian-exim P=local S=2720
2015-03-14 00:47:44 1YWdzE-0000lB-Ik ** <sending e-mail address>
R=smarthost T=remote_smtp_smarthost: retry time not reached for any
host after a long failure period
2015-03-14 00:47:44 1YWdzE-0000lB-Ik Frozen (delivery error message)
2015-03-14 00:47:44 1YWdzE-0000l6-CR Completed

You need to force the delivery out of the queue or remove the hint.
Exim is not even trying to send here.

What do you mean? Why would Exim4 not be trying to send to port 465 when
it does if I'm sending to port 26? And what hint are you referring to?

And please do not obfuscate logs, it happens to often that there are
obvious hints in that kind of data.

On the other hand, my clients are entitled to their privacy. The e-mail
address is well formed, legitimate and hosted by the company whose smtp
server I am trying to reach. Again, the setup works when I change only
port 465 to port 26.

It might also help to run a delivery attempt from the command line
with debugging enabled.

Sorry, but I find Exim4's command line man page to be opaque. When I try
to use exim4 from the command line using -bem
/var/log/exim4/msglog/<message id>, I get "Warning: no message headers
read" and a prompt for more input. Same if I add a -t option.

I'm not an exim guru. Can you provide a command line to do this?

Gary Dale

2015-03-16 16:17:20 UTC

Permalink

Post by Gary Dale

You need to force the delivery out of the queue or remove the hint.
Exim is not even trying to send here.

What do you mean? Why would Exim4 not be trying to send to port 465
when it does if I'm sending to port 26? And what hint are you
referring to?

See exim spec.txt chapter 3, especially 3.14, and chapter 32.

Post by Gary Dale

And please do not obfuscate logs, it happens to often that there are
obvious hints in that kind of data.

On the other hand, my clients are entitled to their privacy. The
e-mail address is well formed, legitimate and hosted by the company
whose smtp server I am trying to reach. Again, the setup works when
I change only port 465 to port 26.

Commercial support for exim is available through numerous sources.
Please consider buying some if you're using exim commercially and
can't figure things out by yourself.

Post by Gary Dale

It might also help to run a delivery attempt from the command line
with debugging enabled.

Sorry, but I find Exim4's command line man page to be opaque. When I
try to use exim4 from the command line using -bem
/var/log/exim4/msglog/<message id>, I get "Warning: no message
headers read" and a prompt for more input. Same if I add a -t
option.

Get the mail into the queue and try delivering with exim -M <msgid>
-D. If that is inconclusive, try -D+all

I don't think you looked carefully at the log. The message enters then
freezes. When sent to port 26, it enters and gets delivered. If I
unfreeze a message to port 465, it still doesn't get delivered. I need
to change back to port 26 to get delivery.

Post by Gary Dale
I'm not an exim guru.

If you're making money of it, you should either become one or hire one.

Alex King

2015-03-16 18:36:36 UTC

Permalink

Post by Gary Dale

This line, "retry time not reached for any host after a long failure
period" is telling you exim has given up and won't even try to send,
even for new emails arriving to be delivered for this address.

This information is kept in the hints db. Marc correctly pointed you to
the documentation which explains what is happening and how to progress
the issue. See spec chapter 32
(http://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html),
particularly 32.10, Long-term failures.

To manage your hints db (which should not be necessary in normal use),
check out exim_ dumpdb and exim_tidydb. (Executables on your system with
man pages).

HTH,
Alex

Post by Gary Dale

Post by Gary Dale
2015-03-14 00:47:44 1YWdzE-0000l6-CR ** <sending e-mail address>
R=smarthost T=remote_smtp_smarthost: retry time not reached for any
host after a long failure period
2015-03-14 00:47:44 1YWdzE-0000lB-Ik <= <> R=1YWdzE-0000l6-CR
U=Debian-exim P=local S=2720
2015-03-14 00:47:44 1YWdzE-0000lB-Ik ** <sending e-mail address>
R=smarthost T=remote_smtp_smarthost: retry time not reached for any
host after a long failure period
2015-03-14 00:47:44 1YWdzE-0000lB-Ik Frozen (delivery error message)
2015-03-14 00:47:44 1YWdzE-0000l6-CR Completed

You need to force the delivery out of the queue or remove the hint.
Exim is not even trying to send here.

What do you mean? Why would Exim4 not be trying to send to port 465
when it does if I'm sending to port 26? And what hint are you
referring to?

See exim spec.txt chapter 3, especially 3.14, and chapter 32.

Post by Gary Dale

And please do not obfuscate logs, it happens to often that there are
obvious hints in that kind of data.

On the other hand, my clients are entitled to their privacy. The
e-mail address is well formed, legitimate and hosted by the company
whose smtp server I am trying to reach. Again, the setup works when
I change only port 465 to port 26.

Commercial support for exim is available through numerous sources.
Please consider buying some if you're using exim commercially and
can't figure things out by yourself.

Post by Gary Dale

It might also help to run a delivery attempt from the command line
with debugging enabled.

Sorry, but I find Exim4's command line man page to be opaque. When I
try to use exim4 from the command line using -bem
/var/log/exim4/msglog/<message id>, I get "Warning: no message
headers read" and a prompt for more input. Same if I add a -t
option.

Get the mail into the queue and try delivering with exim -M <msgid>
-D. If that is inconclusive, try -D+all

Post by Gary Dale
I'm not an exim guru.

If you're making money of it, you should either become one or hire one.

I don't make money supporting exim4. I support small/home offices. I
use Debian for servers and Exim4 to deliver system messages to me. In
over a decade this is the about only Exim problem I've not been able
to work out.
_______________________________________________
Pkg-exim4-users mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-exim4-users

Gary Dale

2015-03-17 04:28:54 UTC

Permalink

Post by Alex King

This line, "retry time not reached for any host after a long failure
period" is telling you exim has given up and won't even try to send,
even for new emails arriving to be delivered for this address.
This information is kept in the hints db. Marc correctly pointed you
to the documentation which explains what is happening and how to
progress the issue. See spec chapter 32
(http://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html),
particularly 32.10, Long-term failures.
To manage your hints db (which should not be necessary in normal use),
check out exim_ dumpdb and exim_tidydb. (Executables on your system
with man pages).
HTH,
Alex

Would that be on a port basis? Mail sends fine to the same server using
port 26.

The retry rule that I get for that host: is Retry rule: * * F,2h,15m;
G,16h,1h,1.5; F,4d,6h;

Looking in the db files, I get basically less information than I get
with mailq and the exim4 log. Tidydb just removes records, which I can
also do by changing the port to 26 and running exim -M <message>, which
then sends the message.

Alex King

2015-03-18 00:00:15 UTC

Permalink

Post by Gary Dale

Post by Alex King

Post by Gary Dale
2015-03-14 00:47:44 1YWdzE-0000l6-CR <= <sending e-mail address>
U=garydale P=local S=1665
Unrouteable address
R=smarthost T=remote_smtp_smarthost: retry time not reached for any
host after a long failure period

This line, "retry time not reached for any host after a long failure
period" is telling you exim has given up and won't even try to send,
even for new emails arriving to be delivered for this address.
This information is kept in the hints db. Marc correctly pointed you
to the documentation which explains what is happening and how to
progress the issue. See spec chapter 32
(http://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html),
particularly 32.10, Long-term failures.
To manage your hints db (which should not be necessary in normal
use), check out exim_ dumpdb and exim_tidydb. (Executables on your
system with man pages).
HTH,
Alex

Would that be on a port basis? Mail sends fine to the same server
using port 26.
The retry rule that I get for that host: is Retry rule: * * F,2h,15m;
G,16h,1h,1.5; F,4d,6h;
Looking in the db files, I get basically less information than I get
with mailq and the exim4 log. Tidydb just removes records, which I can
also do by changing the port to 26 and running exim -M <message>,
which then sends the message.

I didn't see a failed attempt to connect to a remote system in the
original log you posted. The tidy_db command (or removing the hints
(/var/spool/exim4/db/*, see Spec 32.1 Changing retry rules) would allow
you to test sending again with the failing configuration (ie, not port
26), so you can see what the actual failure is.

Also, viewing the hints with
exim_dumpdb /var/spool/exim4/ retry

will show the failure reason (which will be in the logs as well, but not
for every delivery attempt if the address has been failing for so long
that the cutoff time for the last retry algorithm has been reached).

Cheers,
Alex

Gary Dale

2015-03-18 03:59:59 UTC

This line, "retry time not reached for any host after a long failure
period" is telling you exim has given up and won't even try to send,
even for new emails arriving to be delivered for this address.
This information is kept in the hints db. Marc correctly pointed
you to the documentation which explains what is happening and how to
progress the issue. See spec chapter 32
(http://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html),
particularly 32.10, Long-term failures.
To manage your hints db (which should not be necessary in normal
use), check out exim_ dumpdb and exim_tidydb. (Executables on your
system with man pages).
HTH,
Alex

Would that be on a port basis? Mail sends fine to the same server
using port 26.
The retry rule that I get for that host: is Retry rule: * *
F,2h,15m; G,16h,1h,1.5; F,4d,6h;
Looking in the db files, I get basically less information than I get
with mailq and the exim4 log. Tidydb just removes records, which I
can also do by changing the port to 26 and running exim -M <message>,
which then sends the message.

I didn't see a failed attempt to connect to a remote system in the
original log you posted. The tidy_db command (or removing the hints
(/var/spool/exim4/db/*, see Spec 32.1 Changing retry rules) would
allow you to test sending again with the failing configuration (ie,
not port 26), so you can see what the actual failure is.
Also, viewing the hints with
exim_dumpdb /var/spool/exim4/ retry
will show the failure reason (which will be in the logs as well, but
not for every delivery attempt if the address has been failing for so
long that the cutoff time for the last retry algorithm has been reached).

mainlog shows only (after I cleared the queue and retry db) then sent
fresh e-mail:
2015-03-17 11:49:08 1YXsvN-0004wQ-2C Remote host sunspot.dnchosting.com
[199.7.109.2] closed connection in response to initial connection
along with multiple start and end queue runs and retry time not reached
for any host messages.

while exim_dumpdb shows
T:sunspot.dnchosting.com:199.7.109.2:465 -18 65 Remote host
sunspot.dnchosting.com [199.7.109.2] closed connection in response to
initial connection
17-Mar-2015 10:49:11 17-Mar-2015 22:49:08 18-Mar-2015 03:52:53

Again, I am able to send to this host and port using Thunderbird. It
does take encrypted connections.

Alex King

2015-03-18 06:01:29 UTC

This line, "retry time not reached for any host after a long
failure period" is telling you exim has given up and won't even try
to send, even for new emails arriving to be delivered for this
address.
This information is kept in the hints db. Marc correctly pointed
you to the documentation which explains what is happening and how
to progress the issue. See spec chapter 32
(http://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html),
particularly 32.10, Long-term failures.
To manage your hints db (which should not be necessary in normal
use), check out exim_ dumpdb and exim_tidydb. (Executables on your
system with man pages).
HTH,
Alex

Would that be on a port basis? Mail sends fine to the same server
using port 26.
The retry rule that I get for that host: is Retry rule: * *
F,2h,15m; G,16h,1h,1.5; F,4d,6h;
Looking in the db files, I get basically less information than I get
with mailq and the exim4 log. Tidydb just removes records, which I
can also do by changing the port to 26 and running exim -M
<message>, which then sends the message.

I didn't see a failed attempt to connect to a remote system in the
original log you posted. The tidy_db command (or removing the hints
(/var/spool/exim4/db/*, see Spec 32.1 Changing retry rules) would
allow you to test sending again with the failing configuration (ie,
not port 26), so you can see what the actual failure is.
Also, viewing the hints with
exim_dumpdb /var/spool/exim4/ retry
will show the failure reason (which will be in the logs as well, but
not for every delivery attempt if the address has been failing for so
long that the cutoff time for the last retry algorithm has been reached).

mainlog shows only (after I cleared the queue and retry db) then sent
2015-03-17 11:49:08 1YXsvN-0004wQ-2C Remote host
sunspot.dnchosting.com [199.7.109.2] closed connection in response to
initial connection
along with multiple start and end queue runs and retry time not
reached for any host messages.
while exim_dumpdb shows
T:sunspot.dnchosting.com:199.7.109.2:465 -18 65 Remote host
sunspot.dnchosting.com [199.7.109.2] closed connection in response to
initial connection
17-Mar-2015 10:49:11 17-Mar-2015 22:49:08 18-Mar-2015 03:52:53
Again, I am able to send to this host and port using Thunderbird. It
does take encrypted connections.

OK, so sunspot.dnchosting.com is closing the connection. It could be a
fault/configuration at the remote site. Is thunderbird on the same IP
address as your exim? Maybe they've blacklisted your exim box. Either
way, try connecting using openssl s_client, or swaks. You can use these
to debug the ssl connection and confirm you can get a raw connection to
the remote server.

Cheers,
Alex

Gary Dale

2015-03-18 15:18:28 UTC

This line, "retry time not reached for any host after a long
failure period" is telling you exim has given up and won't even
try to send, even for new emails arriving to be delivered for this
address.
This information is kept in the hints db. Marc correctly pointed
you to the documentation which explains what is happening and how
to progress the issue. See spec chapter 32
(http://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html),
particularly 32.10, Long-term failures.
To manage your hints db (which should not be necessary in normal
use), check out exim_ dumpdb and exim_tidydb. (Executables on your
system with man pages).
HTH,
Alex

Would that be on a port basis? Mail sends fine to the same server
using port 26.
The retry rule that I get for that host: is Retry rule: * *
F,2h,15m; G,16h,1h,1.5; F,4d,6h;
Looking in the db files, I get basically less information than I
get with mailq and the exim4 log. Tidydb just removes records,
which I can also do by changing the port to 26 and running exim -M
<message>, which then sends the message.

I didn't see a failed attempt to connect to a remote system in the
original log you posted. The tidy_db command (or removing the
hints (/var/spool/exim4/db/*, see Spec 32.1 Changing retry rules)
would allow you to test sending again with the failing configuration
(ie, not port 26), so you can see what the actual failure is.
Also, viewing the hints with
exim_dumpdb /var/spool/exim4/ retry
will show the failure reason (which will be in the logs as well, but
not for every delivery attempt if the address has been failing for
so long that the cutoff time for the last retry algorithm has been
reached).

OK, so sunspot.dnchosting.com is closing the connection. It could be
a fault/configuration at the remote site. Is thunderbird on the same
IP address as your exim? Maybe they've blacklisted your exim box.
Either way, try connecting using openssl s_client, or swaks. You can
use these to debug the ssl connection and confirm you can get a raw
connection to the remote server.

Did that already. I can connect, send a HELO or EHLO and MAIL FROM: but
RCPT-TO: gives an error:

RENEGOTIATING
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST
Network, CN = USERTrust RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:0

Thunderbird clients use local IP addresses but would go out on the same
routeable IP address. There is only one router in the office. Moreover,
I can access the same remote server using port 26 (their unencrypted
smtp port) using the same exim box - only the port changes.

Gary Dale

2015-03-24 03:48:06 UTC

This line, "retry time not reached for any host after a long
failure period" is telling you exim has given up and won't even
try to send, even for new emails arriving to be delivered for
this address.
This information is kept in the hints db. Marc correctly pointed
you to the documentation which explains what is happening and how
to progress the issue. See spec chapter 32
(http://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html),
particularly 32.10, Long-term failures.
To manage your hints db (which should not be necessary in normal
use), check out exim_ dumpdb and exim_tidydb. (Executables on
your system with man pages).
HTH,
Alex

Would that be on a port basis? Mail sends fine to the same server
using port 26.
The retry rule that I get for that host: is Retry rule: * *
F,2h,15m; G,16h,1h,1.5; F,4d,6h;
Looking in the db files, I get basically less information than I
get with mailq and the exim4 log. Tidydb just removes records,
which I can also do by changing the port to 26 and running exim -M
<message>, which then sends the message.

I didn't see a failed attempt to connect to a remote system in the
original log you posted. The tidy_db command (or removing the
hints (/var/spool/exim4/db/*, see Spec 32.1 Changing retry rules)
would allow you to test sending again with the failing
configuration (ie, not port 26), so you can see what the actual
failure is.
Also, viewing the hints with
exim_dumpdb /var/spool/exim4/ retry
will show the failure reason (which will be in the logs as well,
but not for every delivery attempt if the address has been failing
for so long that the cutoff time for the last retry algorithm has
been reached).

mainlog shows only (after I cleared the queue and retry db) then
2015-03-17 11:49:08 1YXsvN-0004wQ-2C Remote host
sunspot.dnchosting.com [199.7.109.2] closed connection in response
to initial connection
along with multiple start and end queue runs and retry time not
reached for any host messages.
while exim_dumpdb shows
T:sunspot.dnchosting.com:199.7.109.2:465 -18 65 Remote host
sunspot.dnchosting.com [199.7.109.2] closed connection in response
to initial connection
17-Mar-2015 10:49:11 17-Mar-2015 22:49:08 18-Mar-2015 03:52:53
Again, I am able to send to this host and port using Thunderbird. It
does take encrypted connections.

OK, so sunspot.dnchosting.com is closing the connection. It could be
a fault/configuration at the remote site. Is thunderbird on the same
IP address as your exim? Maybe they've blacklisted your exim box.
Either way, try connecting using openssl s_client, or swaks. You can
use these to debug the ssl connection and confirm you can get a raw
connection to the remote server.

RENEGOTIATING
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST
Network, CN = USERTrust RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
Thunderbird clients use local IP addresses but would go out on the
same routeable IP address. There is only one router in the office.
Moreover, I can access the same remote server using port 26 (their
unencrypted smtp port) using the same exim box - only the port changes.
_______________________________________________
Pkg-exim4-users mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-exim4-users

The problem seems to have been the location of the protocol = smtps
line. I had it originally in
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost.
Moving it to /etc/exim4/exim4.conf.template seems to have done the trick.

Jens Schüßler

2015-03-24 14:43:45 UTC

Permalink

Post by Gary Dale
The problem seems to have been the location of the protocol = smtps
line. I had it originally in
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost.
Moving it to /etc/exim4/exim4.conf.template seems to have done the trick.

This is no big surprise, since your first post stated you use
dc_use_split_config='false'.......

Nick Guerette

2015-03-24 19:25:10 UTC

Permalink

Post by Jens SchÃ¼Ãler

This is no big surprise, since your first post stated you use
dc_use_split_config='false'.......

Is there a good reason for the package to offer the option of either
split or monolithic config files? I'm a fan of the split arrangement
since it allows more modular changes, but providing both just seems to
be asking for this kind of confusion. https://xkcd.com/1172/

Andreas Metzler

2015-03-26 18:49:11 UTC

Permalink

Nick Guerette <***@mosaic-industries.com> wrote:
[...]

Post by Nick Guerette
Is there a good reason for the package to offer the option of either
split or monolithic config files? I'm a fan of the split arrangement
since it allows more modular changes, but providing both just seems to
be asking for this kind of confusion. https://xkcd.com/1172/

--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

linuxthefish

2015-03-26 18:51:25 UTC

Permalink

Hello,

The split files config is horrid, how could anyone use this!?

So confusing!

Post by Andreas Metzler
[...]

I think there is a good reason, yes.
- Modular works good at minimizing the number of dpkg-conffiles
prompts. However it breaks horribly when there are more invasive
changes in the configuration like reordering routers when
local changes are present.
- Monolithic will show prompts more often but will not end up with a
breaking mixture of "new" and "old" configuration.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
_______________________________________________
Pkg-exim4-users mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-exim4-users

Paul E Condon

2015-03-29 03:24:52 UTC

Post by Gary Dale
2015-03-14 00:47:44 1YWdzE-0000l6-CR <= <sending
e-mail address>
U=garydale P=local S=1665
Unrouteable address
R=smarthost T=remote_smtp_smarthost: retry time not
reached for any
host after a long failure period

This line, "retry time not reached for any host after a long
failure period" is telling you exim has given up and won't even
try to send, even for new emails arriving to be delivered for
this address.
This information is kept in the hints db. Marc correctly
pointed you to the documentation which explains what is
happening and how to progress the issue. See spec chapter 32 (http://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html),
particularly 32.10, Long-term failures.
To manage your hints db (which should not be necessary in normal
use), check out exim_ dumpdb and exim_tidydb. (Executables on
your system with man pages).
HTH,
Alex

Would that be on a port basis? Mail sends fine to the same server
using port 26.
The retry rule that I get for that host: is Retry rule: * *
F,2h,15m; G,16h,1h,1.5; F,4d,6h;
Looking in the db files, I get basically less information than I
get with mailq and the exim4 log. Tidydb just removes records,
which I can also do by changing the port to 26 and running exim -M
<message>, which then sends the message.

I didn't see a failed attempt to connect to a remote system in the
original log you posted. The tidy_db command (or removing the
hints (/var/spool/exim4/db/*, see Spec 32.1 Changing retry rules)
would allow you to test sending again with the failing configuration
(ie, not port 26), so you can see what the actual failure is.
Also, viewing the hints with
exim_dumpdb /var/spool/exim4/ retry
will show the failure reason (which will be in the logs as well, but
not for every delivery attempt if the address has been failing for
so long that the cutoff time for the last retry algorithm has been
reached).

Did that already. I can connect, send a HELO or EHLO and MAIL FROM: but
RENEGOTIATING
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST
Network, CN = USERTrust RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
Thunderbird clients use local IP addresses but would go out on the same
routeable IP address. There is only one router in the office. Moreover, I
can access the same remote server using port 26 (their unencrypted smtp
port) using the same exim box - only the port changes.
_______________________________________________
Pkg-exim4-users mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-exim4-users

The problem seems to have been the location of the protocol = smtps line. I
had it originally in
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost. Moving it
to /etc/exim4/exim4.conf.template seems to have done the trick.

For those who can contemplate not having to configure exim4 at all, look
at package msmtp. Exim4 is used by Debian installer to put in place a
proper MTA, but if your sysadmin skills are not up to the task of handling
its complexities, msmtp works fine for dummies like me ;-). I'm using it
to send this post.

HTH,

--
Paul E Condon
***@mesanetworks.net

Nick Guerette

2015-03-16 20:18:48 UTC

Permalink

Post by Gary Dale
I did add tls_on_connect_ports = 465 to exim4.conf.localmacros, which
is supposed to cover the SSL on connect issue.

The option tls_on_connect_ports is for incoming connections to your
server, from clients that do not support STARTTLS. In order to enable
the use of TLS on connect, or "SMTPS" when sending outgoing messages
from your server through another SMTP server (smarthost) you need to add
the following to the remote_smtp_smarthost section of the exim4 config
file template(s) - either /etc/exim4/exim4.conf.template or
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost (in my
case, Debian Jessie; do not know if it's changed from Wheezy), and
regenerate the config file with dpkg-reconfigure:

protocol = smtps

See the description of the "protocol" option here:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_smtp_transport.html

This took me a day or two to figure out. "SMTPS" was deprecated so hard
that port 465 was officially reassigned, but it seems common for ISPs to
still run SMTP servers that do not support STARTTLS.

Gary Dale

2015-03-17 03:24:54 UTC

Permalink

Post by Nick Guerette

Post by Gary Dale
I did add tls_on_connect_ports = 465 to exim4.conf.localmacros, which
is supposed to cover the SSL on connect issue.

The option tls_on_connect_ports is for incoming connections to your
server, from clients that do not support STARTTLS. In order to enable
the use of TLS on connect, or "SMTPS" when sending outgoing messages
from your server through another SMTP server (smarthost) you need to
add the following to the remote_smtp_smarthost section of the exim4
config file template(s) - either /etc/exim4/exim4.conf.template or
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost (in
my case, Debian Jessie; do not know if it's changed from Wheezy), and
protocol = smtps
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_smtp_transport.html
This took me a day or two to figure out. "SMTPS" was deprecated so
hard that port 465 was officially reassigned, but it seems common for
ISPs to still run SMTP servers that do not support STARTTLS.

I actually added that line days ago and it hasn't made any difference.