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

[Alex King]

On 17/03/15 17:28, Gary Dale wrote:
> On 16/03/15 02:36 PM, Alex King wrote:
>>
>>
>> On 17/03/15 05:17, Gary Dale wrote:
>>> On 16/03/15 11:56 AM, Marc Haber wrote:
>>>> On Mon, Mar 16, 2015 at 10:54:41AM -0400, Gary Dale wrote:
>>>>> On 16/03/15 04:10 AM, Marc Haber wrote:
>>>>>> On Sun, Mar 15, 2015 at 11:20:38PM -0400, Gary Dale wrote:
>>>>>>> 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 ** -r at localhost: 
>>>>>>> Unrouteable address
>>>>>>> 2015-03-14 00:47:44 1YWdzE-0000l6-CR ** gary at extremeground.com
>>>>>>> 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