On Wed, 27 Oct 2004, Alan J. Flavell wrote:
>
> In mitigation, I think I'd say that the original motive when
> authenticated submission was introduced here, had been to maintain
> minimal complexity (unsecured unauthenticated mail submission) for the
> on-campus majority, while offering an additional facility (requiring
> them to authenticate over a secure path) for an off-campus minority
> who would be willing to learn a new trick.
What we have done is provide TLS and AUTH as an additional facility
available everywhere, in addition to the traditional host-based
authorization. In ACL-speak:
deny message = No SMTP service for unauthorized users
!hosts = +relay_hosts
!authenticated = *
There are a number of reasons for this:
(1) It becomes a lot easier to persuade people to use secure settings if
they never have to reconfigure their software again. In the past they had
to reconfigure back and forth between our email servers and their ISP's
servers; with your model they have to reconfigure back and forth between
secure and insecure settings -- no perceived advantage. This is
particularly important for laptop users.
(2) Configuring clients with "optional" security opens up the possibility
of all sorts of mysterious ways to silently lose email. A particularly
nasty problem occurs if a network intercepts port 25 (e.g. Freeserve aka
Wanadoo). In this case the ISP's SMTP server doesn't offer TLS and AUTH so
the user's software falls back to insecure operation (because security
isn't required). When the message is delivered to us we reject it because
Freeserve's intercepting email servers are in the RBL+; we then reject the
bounce as well, and the message is lost.
(3) I'm working forward to more secure email transmission protocols such
as BATV and DomainKeys. These are very difficult to impose on everyone at
once because they require behaviour changes by our users: they will have
to consistently use our submission servers when sending email "from" an
address under our control, or the message will be rejected as a forgery.
It's much easier for us to allow users to opt in to a new facility like
this so it can be introduced gradually. But to do this we need to identify
the users so we know whether they are in or out, which implies
authenticated smtp.
> Since the sysadmins wouldn't touch some of the mail clients that they
> use, not even with an extremely long barge-pole, we really don't want
> the hassle of being expected to tell them which checkboxes to check,
> and how to cope with the fact that their client handles TLS in
> non-standard ways, and what to do about their root server
> certificates, and all that stuff that's liable to come up in practice.
We're lucky to have had a lot of help with documentation and support from
other members of staff, especially when it comes to the less savoury
software.
http://www.cam.ac.uk/cs/email/muasettings.html
Tony.
--
f.a.n.finch <dot@???>
http://dotat.at/
MALIN HEBRIDES: NORTHEAST 4 OR 5 INCREASING 6. RAIN LATER. GOOD BECOMING
MODERATE.
