On 4/26/2004 8:24, "Mike Richardson" <doctor@???> wrote:
> On Mon, Apr 26, 2004 at 08:56:37AM -0600, Craig Kelley wrote:
>> On Mon, 2004-04-26 at 15:43 +0100, Peter Bowyer wrote:
>>
>>> Not sure I agree - it only takes one extra ACL test to listen on both and
>>> reject on 587 if not authenticated - something like this which was posted by
>>> Bruce Richardson on 11th April:
>>>
>>> accept hosts = +auth_relay_hosts
>>> condition = ${if eq {$interface_port}{587} {yes}{no}}
>>> endpass
>>> message = relay not permitted, authentication required
>>> authenticated = *
>>
>> Now for another wrench that we ran into... Is there a way to get Exim
>> to do traditional SSL on 587? We don't want to send auth data in
>> cleartext, and the major email clients can't do TLS except on port 25.
>> I've used Thunderbird with TLS on non-25 ports -- but Outlook and Apple
>> Mail seem to use this algorithm:
>>
>> If (ssl && port 25)
>> TLS
>> Else If (ssl)
>> Raw SSL
>> Else
>> SSL Disabled
>
> I have evidence (exim logs) in front of me which say that "Microsoft Office
> Outlook, Build 11.0.5510" can use port 587 with TLS. Also "Microsoft
> Outlook, Build 10.0.6626" can use port 465 with TLS, As can Mozilla.
Those look like recent Outlook versions. Good luck getting a group of
paying customers to upgrade.
And the Outlook Express version (detail provided a couple of days ago)
associated with XP Service Pack 2, in common with earlier versions, will
not. (And more of the paying customers use that.)
It's good to hear that Microsoft has caught up with mid-1990s
standards...perhaps in another 10 years we can forget about tls-on-connect.
Then there's Netscape 4, which demands a password be provided upon first
sending with authentication in use, each launch of the program. The
customers don't like that ("I never had a password!") That's what keeps us
from advertising SMTP AUTH in one situation where we'd like to.
--John
