Autor: Bill Hacker Data: A: exim Assumpte: Re: [exim] Setup for authenticated submission
Kjetil Torgrim Homme wrote:
> On Wed, 2006-01-18 at 22:53 +0800, Bill Hacker wrote:
>
>>Kjetil Torgrim Homme wrote:
>>
>>>there is NO good reason to use tls_on_connect on port 587. this will
>>>only cause interoperability woes.
>
>
>>>[...] an MTA set up to use port 587, ostensibly for security
>>>purposes! luckily we had put in a check for this and deny
>>>unauthenticated sending on ports other than 25 (we support 465 and 587
>>>as MSA).
>>
>>You just disproved your own first point, above, in showing that the
>>'interoperability woes' issue can contribute to preventing unexpected
>>abuse, at the very least by caling attention to it.
>
>
> uh. this doesn't make any sense. port 587 is to be used to
> authenticated SMTP. it should start out unencrypted.
Why should it not be encrypted from the outset?
'Coz there are inflexible MUA's? Easily fixed.
> what happens
> after initial EHLO handshake will depend on negotiations between server
> and client.
Only if you do not want it to begin life in an SSL 'tunnel'. We do.
> it is NOT required to use STARTTLS, many prefer to use
> CRAM-MD5 or similar schemes which aren't vulnerable to sniffing.
>
How, pray tell, is the know-long-ago-compromised MD5 less 'vulnerable'
than the
current higher-level releases of SSL/TLS?
>
>>Our use of 587 fits precisely our setup for specific-client MUA's. And
>>no others.
>>
>>Not proselytizing, but 'standards' apply to the part we do NOT control
>>(our MTA-MTA environment is very much more gracious).
>
>
> yes, your system, your rules. if you want to make configuration harder
> for your clients, feel free. but it is bad advice to pass out to
> others.
>
It might indeed be 'bad advice' to pose it as an alternative *standard*,
or even
generally attractive to public-serving ISP/ASP's.
Other corporate/institutional admins, of which we have many here, may
find it more useful.
We have many good reasons to control end-user environment, most of them
cost-driven
as well as security-driven.
Configuration is no 'harder' for the client than following any other set
of instructions.
(in any case, we actually do it for nearly all of them anyway -
'corporate', remember).
They put <something> in box 'a', <something else> in box 'b', etc. in
either case,
and 'convenience' is fully transparent once the setup is made.
Run your environment however you are allowed to/see fit/can justify....
