Educause Security Discussion mailing list archives

Re: Email Forwarding


From: David Grisham <dgrisham () SALUD UNM EDU>
Date: Sat, 19 Feb 2011 08:59:57 -0700

My apologies in advance for a slightly different tangent on the same issue. Does either your Health Science Center 
and/or University Hospital have a separate stance on e-mail forwarding than the Main campus? As both of these areas 
have HIPAA and HITECH responsibilities to prevent and/or reduce ePHI data leakage.
I will gladly take responses specific to this question and provide a summary to the Listserv. Cheers.-grish
David Grisham, Ph.D., CISM
Manager ITSecurity, UNMH, HSC

"Volz, Donald D" <don.volz () TXSTATE EDU> 2/19/2011 8:21 AM >>>
We allow forwarding and even provide self-service tools to facilitate it.  We also employ many of the measures already 
discussed in this thread to reduce the risk that external mail providers will block mail from our domain. And I agree 
that the issue of internal spamming is separate and distinct.  We have many users who would not think of forwarding 
their mail to an external provider, but effectively use their Outlook or Entourage clients to filter/delete 
"announcement" type messages without ever reading them.  

Quite frankly, mail forwarding is such a core feature of any mail system (whether on the client side or server side, 
whether through automated rules or manual selection/forward) that I can think of no technical means to effectively 
prevent it from happening.  Thus, we decided against fighting that losing battle and now focus instead on educating 
users about the implications of mail forwarding for ALL users, such as:
- university NOT responsible for non-receipt due to spam blocks by external providers,  
- policy prohibits transmitting confidential information via unencrypted email, 
- message recall functionality is crippled and therefore unreliable,
- personal/external email accounts of those who forward are by default "in-scope" for records preservation orders and 
e-Discovery requests/subpoenas, etc.

With apologies to Quinn for somewhat hijacking his thread, I have a related question that I think is germane. 

For those of you that allow automated mail forwards, what happens to the forward when the owning user separates from 
your institution and their email account is de-provisioned?  Is the forward deactivated at the point of 
de-provisioning?   Do you allow the forward to persist for some period of time, such as for departing faculty members 
or recent degree recipients who may have broadly published their campus email address as part of ongoing research 
activities?  Are their different rules or practices for different affiliates, such as alumni, retirees, fired 
employees, etc.? 

Best,
Don
______________________________________________
 
Don Volz
Special Asst to the VPIT
Texas State University
Email: don.volz () txstate edu 
Voice: 512-245-9650
FAX: 512-245-1226


-----Original Message-----
From: Joel Rosenblatt [mailto:joel () COLUMBIA EDU] 
Sent: Friday, February 18, 2011 11:41 AM
Subject: Re: Email Forwarding

We support email forwarding on demand as a self service function.

Our email forwarding occurs after our spam filtering, which I would highly recommend as a good thing :-)

As far as "locally generated" spam, our policy is that all official communication from the University will come from 
and be sent to the University supplied email address - not reading your university email is not an excuse for not 
knowing something.

I have gotten requests to get off University email lists (for example, an email sent do all employees from HR about a 
HR issue) - my response to those is get another job - if you work for the University, you will get email from the 
University.

My 2 cents

Joel Rosenblatt

Joel Rosenblatt, Manager Network & Computer Security Columbia Information Security Office (CISO) Columbia University, 
612 W 115th Street, NY, NY 10025 / 212 854 3033 http://www.columbia.edu/~joel Public PGP key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90BD740BCC7326C3 



--On Friday, February 18, 2011 8:04 AM -0800 Joe St Sauver <joe () OREGON UOREGON EDU> wrote:

Geoffrey mentioned:

# At Wayne State we do allow forwarding, and this has indeed caused us 
grief on # occasion, but it's unlikely we'll turn it off any time soon. 
I maintain a blog # on internal IT-related things, and suggested, a few 
months ago, that we forbid # forwarding. You can  read the comments--they are instructive:
#
# http://blogs.wayne.edu/proftech/2010/are-you-part-of-the-problem/ 

Looking at that article and comments, I'm seeing two key themes, I think:

-- forwarding was causing problems for Wayne State because forwarding
   was happening pre-filtering, and when spam was forwarded to third
   party providers, and then reported by users, it was "charged" against
   Wayne State, even though all you did was dutifully forward the user's
   mail as they'd asked you to do

-- some users preferred third party accounts because of things like
   excessive amounts of "intra-spam" to which they'd been involuntarily
   subscribed

We dealt with the first issue in part here at UO by offering users the 
ability to forward AFTER spam filtering had happened (e.g., via 
procmail rather than via a traditional .forward file). That approach 
really knocks forwarded spam down to trivial levels, assuming you have 
an effective filtering solution in place.

The second issue, intra-spam, is one that each site needs to wrestle 
with themselves, but I think policies that mandate either (a) 
confirmed opt-in lists only, or (b) approval by a designated very 
senior person (for rare involuntary 
everyone-gets-this-one-whether-they-want-it-or-not
mailings) can do a lot to eliminate issues with unwanted intra-spam.

Regards,

Joe

Disclaimer: all opinions strictly my own




Joel Rosenblatt, Manager Network & Computer Security Columbia Information Security Office (CISO) Columbia University, 
612 W 115th Street, NY, NY 10025 / 212 854 3033 http://www.columbia.edu/~joel Public PGP key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90BD740BCC7326C3


Current thread: