Re: [exim] the great TLS mystery

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim-users
Assumpte: Re: [exim] the great TLS mystery
Phil Pennock wrote:
> On 2011-02-23 at 17:45 -0800, WJCarpenter wrote:
>> My server is configured to advertise authentication only to localhost
>> and TLS connections. (I can show those configs if it comes to that, but
>> I don't think it's necessarily relevant.) After configuring his client
>
> I do -- could we please see the authenticators and and setting with
> "tls" in the name? Including the output of running:
>
>    % exim -bV
>    % exim -bP | fgrep tls

>
>> I know what you are thinking ... something screwy with my
>> auth_advertise_hosts macro or my server_advertise_condition. I spent a
>> bunch of time staring that those before I happened to notice this in my
>> log files: "SMTP command timeout on TLS connection from...." Every
>> time he connected from his DOS telnet or from his Thunderbird and let
>> the connection timeout, the Exim log line indicates that the connection
>> was using TLS. I have plenty of other command timeouts that are not TLS
>> (my own tests, plus the usual door-knockers).
>
> Are you 100% sure that the error message corresponds to the telnet
> sessions, not just Thunderbird?  I suspect something like:
>    tls_on_connect_ports = 465
> and Thunderbird configured with SSL, not TLS: this being Mozilla-speak
> for "encryption on connect, instead of using STARTTLS".


Which can get more interesting/obtuse yet, as port setting is independent and
won't always follow other successive changes even if not set manually.

By design here, by accident otherwise, one can have selected:

- 'legacy' SSL, but for port 587 not 465

- or 'modern' TLS but for port 465 insetad of 587.

- or who-knows-what on port 25...

>
>> So, my question is ... what could make Exim believe that a certain
>> connection was using TLS when (as far as I can tell) it really was not?
>
> To see that message, the internal variable tls_active must be set>= 0
> (to match the file descriptor corresponding to the connection). This
> means that tls_server_start() has been called, which means that
> something has happened to enable SSL/TLS.
>
> -Phil
>


Turning up log_selector = *AND* adding a 'warn' or so that ID's the protocol and
AUTHED state/or NOT ... can help:

Here's a typical entry of the 'listener' (PID 48461) and child (PID 56055) for
one of my arrivals with added warn 'log_message = ' in the acl's:

====

2011-02-24 03:24:51 [48461] SMTP connection from [61.10.57.220]:50234
I=[203.194.153.81]:587 (TCP/IP connection count = 1)

2011-02-24 03:24:51 [56055] H=cm61-10-57-220.hkcable.com.hk (loki.localhost)
[61.10.57.220]:50234 I=[203.194.153.81]:587 Warning: H1
cm61-10-57-220.hkcable.com.hk 61.10.57.220 submission client arriving on port
587 with smtp

2011-02-24 03:24:51 [56055] H=cm61-10-57-220.hkcable.com.hk (loki.localhost)
[61.10.57.220]:50234 I=[203.194.153.81]:587 Warning: R0
cm61-10-57-220.hkcable.com.hk 61.10.57.220 is authenticated using esmtpsa

====

NB: tls_on_connect in use here for port 587 - not quite 'vanilla', but the
logs will show one wot's wot.

HTH,

Bill