Re: [Exim] TLS Problem

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Łukasz Grochal
日付:  
To: exim-users
題目: Re: [Exim] TLS Problem
Hmm, I though there was some discussion on what I wanted to ask
in this thread. Now - when I have time to read it - I see there
wasn't :) So here's my $00.2 on this topic:

Philip Hazel <ph10@???> writes:

> It depends on what you mean by "TLS session fails". If the server
> rejects the "STARTTLS" command, Exim will attempt to send the message
> unencrypted (in the absence of hosts_require_tls). However, if STARTTLS
> is accepted, but there is a problem in setting up the session (which
> will happen if the certificate doesn't match, but can also be caused by
> other problems), Exim gives up, because the state of the SMTP connection
> is undefined. (The server end doesn't know what the state is either.)


There are numbers of broken MTA's (mostly Lotus Notes/Dominos,
sometimes others) all over the Internet that close connection right
after the STARTTLS (mostly because their clueless admins didn't care
to generate certificates). When Exim talks to such hosts, it gives up
and retries later (and eventually gives up, as those servers are just
broken all right).

As far as I can tell, the only way to deliver mail to such servers from
a TLS-enabled Exim is to use hosts_avoid_tls option. That unfortunately
requires constant maintenance of config file and is quite a PITA for
users who send mail to such sites and have it returned back undelivered
some time later (no, they're users - they don't read DSN messages ;)

It would be nice and helpful if Exim - after the session broke right
after STARTTLS or if STARTTLS gave a permanent error, started another
delivery attempt, avoiding TLS at this time. Unless of course the host
is in hosts_require_tls. Perhaps it could log a warning then too?

Is there any chance for such a functionality? In Exim 4 perhaps?

Regards,

--
(-) Łukasz Grochal                                  lukie@???
                                                  (for PGP key visit:)
_____________________________________________ http://www.rotfl.eu.org/ __
... all in all it's just another rule in the firewall.       /Ping Flood/