Re: Blocking POP3 and IMAP

[Paul Russell <prussell () ND EDU>]

On 10/11/2007 15:15, Geoff Nathan wrote:
> Should we be forcing TLS?  Of course.  Can we train 40K users to set up
> their clients to do that?  Probably not.  Especially when those users
> include the Provost, the Deans and most other Associate VP's, chairs and
> other high level officials.  It's a distant gleam in our eyes, but not
> something we're going to be doing soon, no matter how badly needed it
> might be. And your career won't get very far if you threaten to fire the
> Provost or the Dean of Liberal Arts and Sciences because they insist on
> using Eudora. ;-)

This can be done; we did it. It was not quick or easy, but there was no
bloodshed. Most modern email clients support the use of secure connections
for IMAP, POP, and SMTP, so the vast majority of our users were able to
continue using their email client of choice.

We have approximately 15,000 users. Our central mail servers have supported
secure IMAP, POP, and SMTPAUTH for nearly five years. We began promoting
the use of secure connections when we deployed these servers, and we
changed our email client setup documentation to show how to configure
clients to use secure connections. A relatively small segment of our user
community began using secure connections almost immediately. A few more
joined the club when they switched or upgraded their email clients, and had
to check the documentation to find out how to configure their clients. Most
folks did not make the switch until we forced the issue.

Most of our students use our webmail service as their primary email client,
so the impact was minimal when we reconfigured the SMTP servers to require
secure SMTPAUTH to send email from systems in the residence halls. The
story was a bit different when we attempted to "throw the big switch" for
faculty and staff. We had sent several notices advising users of the
impending change and instructing them to reconfigure their email clients.
A few complained about "more OIT spam"; most apparently ignored us. On the
designated day, we made the change, disenfranchised most of our email
users, and watched the Help Desk staff drown in a flood of calls from
angry users.

So, we backed out the change and regrouped to develop a different game
plan. We decided to deal with the situation on a building-by-building
basis. Network Engineering provided the information we needed to map
subnets to buildings, and our desktop support teams took on the task of
checking every workstation in every building to confirm that the email
clients were configured to use secure connections for both sending and
retrieving email. In some cases, clients had to be upgraded. In rare cases,
users had to switch clients, because the client they had been using did not
support secure connections. When we were notified that a given building (or
group of buildings) was ready, we updated the sendmail access list to
enforce the use of secure SMTPAUTH for the corresponding subnet(s). On the
day that we added the last subnet to the sendmail access list, we also
updated the host firewall rules on the IMAP/POP proxy servers to block all
connection attempts to ports 110 and 143.

Since we are using the sendmail access list to enforce the use of secure
SMTPAUTH, it is a simple matter to grant exceptions for systems running
line-of-business applications which send email, but which do not support
secure connections and/or SMTPAUTH.

--
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
prussell () nd edu