Re: [exim] [PATCH 2/2] Docs: state out why ssmpt is not obso…

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Ian Eiloart
Date:  
À: Exim Users
Sujet: Re: [exim] [PATCH 2/2] Docs: state out why ssmpt is not obsolete

> On 6 Aug 2015, at 23:02, Heiko Schlittermann <hs@???> wrote:
>
>>
>> This is also
>> trivial to do. Because so many MUAs are not behaving sane (opportunistic
>> starttls is as safe as no TLS), it is not a good idea to use port 587
>> and starttls as long as you can't make sure that no such clients are
>> being used.
>
> It should be about the same effort in the client's configuration for 'TLS
> required' as for TLS on port 465.


And, indeed, with Exim, it’s trivial to require encryption on any port. You can just say something like
"deny
! encrypted = *"
early in an appropriate ACL.


> As long as the client considers encryption as an opportunistic feature,
> we're out of luck anyway.


Actually, not so much. Encryption is there to protect two things (A) the sender’s password, and (B) the sender’s content.

It’s in our interest to protect the password, because it’s used for authentication, and it has no value to us as an authentication token if it’s available to everybody. Permitting authentication without encryption is almost pointless, so (hopefully) few sites do it.

It’s not particularly in our interest to protect the content, unless the content belongs to us: as is often the case for corporate email services. Encrypted content is a service that we offer to the user. It’s not close to end-to-end encryption, but it’s better than nothing.

Nevertheless, because we love our users, and it’s in their interest to encrypt if they can, we usually insist upon it when they’re connecting on 587. Some sites will make exceptions for local servers, especially because a lot of server software out there doesn’t know how to encrypt or authenticate. And some even make exceptions for end user clients when they’re located on premises, like a corporate or university campus, but that isn’t something you need to do.

If this is inbound (MTA not MSA) mail, then we can’t really insist on encryption, except where arranged. Too many sites don’t support it.

--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148