Re: [exim] Should MX offer TLS ?

Chris Edwards wrote:
> On Wed, 14 Nov 2007, Tony Finch wrote:
>
> | Yes, though you'd want to use client and server certificate verification
> | for the MTA-to-MTA links
>
> Preferably yes. But surely opportunistic encryption is better than
> sending in the clear.
>
>
> | which means you'd need a list of hosts that are members of this secure
> | federation to avoid interop problems. This seems to me like a fairly
> | obvious idea so I expect there are already companies doing it - though I
> | don't know of any.
>
> We have a department that wishes to do this (certificate checks)
> with other sites they collaborate with...
>
> --
> Chris Edwards, Glasgow University Computing Service
>

The 'majors' (banks, financials, IBM & other software firms, ATT & other telcos,
oil companies et al), have done this for years - first with actual private
networks and gateways, more commonly today with VPN & gateways, even s-code
generator dongles for login....

I would expect a university of any size to benefit from similar implementations
- especially to the extent one has, for example, engineering or science
departments that need to move CAD-CAM or similar large files / attachments
between themselves and remote collaborators that might be at odds with spam
scanning needs.

HOWEVER - much as you might like to provide a clear-channel for these, the fly
in the soup is what to do if the 'terminals' (PC's) on that net are otherwise
vulnerable to infestation via, for example, browsing or OTHER email accounts /
access.

As they almost certainly will be....

For one of our clients, we handle that (R&D CAD-CAM to-from contractors) with
protected upload/download areas on a bespoke web service.

Even with decent security, that has few guarantees, *either* (possibly infected
end points remain in the equation)

- but at least keeps any issues separate from the general-purpose email system.

A side benefit is that these large files need only a single server-side copy,
not 'many' in mail queues and mailstore.

HTH,

Bill