Re: [exim] mysql authentication problem...

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim-users
Subject: Re: [exim] mysql authentication problem...
Ted Cooper wrote:
> On Sat, 2009-10-10 at 10:47 +0800, W B Hacker wrote:
>> Ted Cooper wrote:
>>> I've found I can't use this method with Outlook clients - if I don't
>>> advertise all the time, Outlook will never attempt to authenticate even
>>> after it has started an encrypted session.
>> I've not seen that.
>
> Google "outlook bug STARTTLS 587"
> <quote>
> Note Outlook will only do STARTTLS on port 25, not 587. Since many
> providers now block use of the that port, people who use Outlook and
> need to use encryption and authenticated SMTP should use SSL and port
> 465 as an Advanced Setting
> </quote>
>
> Which kinda holds true - as I said, if you advertise LOGIN before
> STARTTLS, outlook will do STARTTLS on port 587. One buggy big expensive
> program.
>


Mea Culpa - My Irish Alzheimer's again.

'I've not seen that' is because we use:

tls_on_connect_ports = 587

Then tell an(y) MUA to use port 587 and SSL
(rather than TLS or TLS-if-available)

Outlook has not had an issue with THAT scenario.


>> > My end solution was to allow
>>> users to authenticate without encryption but reject all authenticated,
>>> non-encrypted attempts in acl_smtp_mail.
>>>
>> Bass-ackwards, IMNSHO.
>>
>> First you encourage en-claire exposure of the UID:PWD ,,, then (little else
>> matters...)
>
> I don't encourage it, hence rejecting all mail from clients that have
> provided their details in the clear. It was just the only way I could
> get Outlook and all the other mail clients to work properly.


See above. Akin to using 465 & SSL, but since 465 was reassigned to Cisco, I'd
rather not use that port.

No one should be arriving on our 587 but ourselves anyway, so it is no one
else's business what we offer there or how. The RFC recognizes that, BTW.

> The only
> attempts I've had of credentials in the clear have been brute force
> attempts by bots.
>


While the attacks would be fruitless in either case, we saw the same pattern of
attempts with 587 and TLS. When 587 was configured with SSL, OTOH, there are
near-zero attacks. Since we have to pay for bandwidth, the rest was easy.

Bill