We outsource email to Zimbra, initially to Yahoo! and currently being hosted by 
Merit.

I was originally stumped on why FOPE would restrict forwarding...but than I 
remembered that Universities are kind of special when it comes to email.  How 
soon I forgot what life outside was like....  At previous job, the only 
outgoing mail was internally generated and from our domains.  There was no 
automatic forwarding allowed.  Though there were people that would find their 
way around the restrictions....I was using fetchmail/procmail for a while until 
shutdown pop access.  Before it was homegrown sendmail and pop (imap came 
later), but then they went exchange, but kept pop/imap around for 
transition....but eventually everybody was required to use outlook.  As we 
switched from our own Calendar product to using Exchange as the official 
calendar.  It was then that they finally got me something better than a 75MHz 
Pentium system for Windows.  Though eventually I had a really powerful Windows 
box, because our proprietary IDE only ran on Windows...even though our app was 
in a pr
 oprietary platform independent language and was available for Solaris and HP 
(Linux came later...after I had done the port of a different commercial 
offering to it, which at the time was available on a much wider selection of 
Unix systems and OpenVMS.)

Though what's really amazing is that one of my Linux servers is still checking 
into a system information site, which I had forgotten about until yesterday. 
(was also on linuxcounter, but the site change has stopped it from checking 
into that)....a Pentium II 400Mhz machine running RedHat 7.3.  Its the NIS 
slave server.  I heard the NIS master died about a year after I had been laid 
off, but they couldn't figure out how to use the recovery disks that I had left 
(mondorescue) or how to promote a slave to a master.  I didn't leave anything 
on that, but the O'Reilly NIS book covers it....and its what I used when I had 
to do it once.

But, we're doing a poor job on educating our users to not respond to phishing 
and having their accounts compromised or that its not funny to mark emails 
forwarded from their accounts in hotmail/gmail/etc. as spam just because they 
want it to go away.  Also to not mark forwarded spam as spam....  Just as Merit 
disabled the spam button in Zimbra for us.  A department mailing list was going 
into spam, I later heard that a bunch of people in the department joking that 
they were marking the messages as spam.  This was also causing problem for 
Athletics...who flood the students with emails quite regularly.  But, student 
tickets are electronic only....and those were getting lost in other student 
spam folders.  

It is university policy that if you forward your mail that you are do so at 
your own risk, which is why it is also recommended that they use the keep local 
option.  But, students don't think they should be penalized if emails are 
delayed or lost.  There are times where we have to track down headers to see if 
the student sent their assignment in on time, but it got delayed somewhere...or 
not.  Other times to find out if a student did in fact fail to receive 
assignment emails, or if the emails actually showed up in the wrong place.  
Misconfigured email filters can be a problem sometimes as well.

But, basically we've been blocked by Hotmail since the start of the fall 
semester, and there doesn't seem to be any sign of reliably getting unblocked.  
Our CIO sends an email to his wife's hotmail account every day....and some days 
it arrives and other days it doesn't.  Sometimes he'll get a bounce message and 
other times he won't.  And, senderscore doesn't seem to be the only factor in 
deciding...

I think they did a review and found that a large majority of students forward 
to gmail, in distant second is hotmail...though its very popular among our 
international student population.  And, then Yahoo! seems to clinging on to 3rd 
place. (I interviewed with Yahoo! Mail before coming to Kansas State 
University...it was quite the interview process, but it prepared me for the 
interview process at KSU ;)

At one time...it seemed like we were going to be switching the students to 
gmail during fall break, then during winter break...while keeping the 
faculty/staff on Zimbra until we figure out what to switch to (they seemed to 
feel a hosted exchange solution was most likely, but it would take longer to 
move our processes from Zimbra to another system.  When we initially moved to 
Zimbra, we kept Oracle Calendar as our official calendaring tool for a couple 
years before we made people switch.  Though a lot of people switched 
before....which caused some problems because how they solved resource 
management without being able to create resource objects was different than 
when we did, etc.  There are also other things that we've done in Zimbra that 
we'll need to figure out how to do in whatever we switch to.

The biggest problem with the split, was the president decreed that both 
students and faculty/staff would retain @ksu.edu/@k-state.edu addresses.  While 
Google has solutions on how to achieve this, getting Merit to consider any such 
proposals to changes to their system hasn't been very successful.

In fact whether we try FOPE or not, might come down to whether Merit will make 
the changes or not.

Though for sometime now, they've had talked about having out outgoing mail go 
through their ironport cluster....and do other things to help avoid us getting 
blocked.  Suddenly, they're rushing to finally implement this...they're going 
to do it for their own schools this weekend, and then us next weekend.  
Basically, it do spam scoring and good emails with sender @ksu.edu/@k-state.edu 
will go out from a small pool of IPs dedicated to us.  And, the rest will go 
out through the general pool.  Along with other policy enforcement that 
ironport can do.....  authenticate smtp has been a vector for exploiting 
compromised accounts for a while (though it wasn't before we had outsourced 
email), but they were using home grown scripts to logwatch for suspicious 
activity....

Yahoo! apparently had automatic tools to lockout accounts, but Merit has been 
slowly developing their own.

But, our CISO is still set on trying out FOPE.  He's currently talking about 
pointing out internal smtp server at it.  But, we don't have problems sending 
from that server, but it also doesn't test the one case that we're uncertain 
about.  And, the CISO's Microsoft contacts are also uncertain about.  I keep 
being omitted from the discussions though...because I was the only person that 
read the documentation, and pointed out what it said leading to why the CIO 
shot down his original request to make it happen before classes started on 
Tuesday.  But, the flu seems to be nasty this year...the CIO has been out this 
last week....

Anyways...it looks like we're leaning heavily towards going with 
Live@edu/Office365 for everybody.  Even though they did a campus wide survey, 
and overwhelmingly people wanted Gmail.  I think the choices were, Gmail, 
Microsoft Office365, staying on current Zimbra or finding a new hosting 
provider.

I think second place was stay put.  Because, despite all the vocal people 
complaining about Zimbra...there are people that will put up with it and don't 
like change.  Plus its been quite an improvement from when we were keeping our 
home grown system limping along on scrounged hardware. (the year I started, we 
got it into the school year...buy borrowing one of the E2900's from the new SIS 
system that Oracle had been developing for us....they ended up giving up on the 
project and instead acquired Peoplesoft and delivering that...)  The year after 
that we had give back the E2900....so we got them to loosen the purse strings 
and get us a couple T2000's, and later borrowed another pair of T2000's.  We 
had been serving up our mailspool by NFS from a pair of V440's, and going to an 
E2900 helped in keeping up.  The T2000's should've, though we didn't see 
it...but turned out interrupt handling is single threaded (though later we got 
a tweak to have a single core handle interrupts)...a
 lso ipf is single threaded....and is there even when its set to pass in/out 
all (another tweak to not have pf on all interfaces....the private nfs network) 
 We also started carving up the mailspool......first into 2 and then 4.

Though we had things broken out by first two letters...so picked a split based 
on size.  Not utilization.

We had originally planned to develop a system MDA/MUA and storage were on one 
box....proxies to direct you to the correct box and the ability to move 
mailboxes around or add more nodes as needed.  Kind of like Zimbra.  But, with 
no hardware and the project lead not wanting any help...it didn't get done in 
time.  Though later we had some weird things happen when production systems got 
rebooted....in that they reverted back to mail development systems.  Our 
datacenter DNS server did that one Friday night.  Building a new one from 
scratch by remote wasn't how I had intended to spend my Friday night.  He later 
explained that he had taken the original hardware out for maintenance and 
brought it up temporarily on the dev server...but then forgot about it.  But, 
then there were other servers where it happened...

But, after he had left...I had become the Email and DNS guy.... stuff I had 
done years before, but wasn't considered capable of doing when I started 
here...and now I'm the only one that knows these things here :)  Though I try 
not to.  But, my wiki pages don't hold the SA's hand.... some haven't been 
updated from when we used to use RCS and now use SVN...but the important part 
is still the same.

A couple years ago I spent some time writing my own rulesets in sendmail 
configuration language....that was fun.  Though redoing it in perl in 
mimedefang was somehow less satisfying.

Of course, wasting my Saturday on email problems wasn't what I had planned 
either....  Somehow most of the problems occur the week that I'm on call.

Guess I forgot to press send....

----- Original Message -----
> On Sun, 20 Jan 2013 18:37:10 -0500, John Slee <[email protected]>
> wrote:
> 
> > On 21 January 2013 00:58, Greg R <[email protected]> wrote:
> >> We had a regular flow of forward-to-gmail users wondering how mail
> >> from
> >> us
> >> ended up in the google spam bins, and getting told that's the
> >> price of
> >> not
> >> using the University mail-systems.
> >
> > Really? Did you ever stop to wonder _why_ Google might think they
> > were
> > spam, and that perhaps the root cause might well exist in the
> > university
> > net?
> 
> We knew very well why the Google thought we were sending them spam.
> The
> pre MS-Live student email system forwarded all email before it had
> been
> through the spam filters, so we WERE forwarding a lot of spam.
> Happily for
> us, their lexical checkers are good enough to let through most of the
> stuff we wanted through.
> 
> Our few Fac/Staff Exchange users who forwarded all mail off campus
> were
> known to our support staff and had largely accepted those losses as
> the
> price of getting an interface they wanted.
> 
> After the migration to MS-Live we still had people forwarding mail to
> outside sources. Acording to the helpdesk people who were helping
> people
> make this happen, there were two big reasons for WHY people were
> doing
> this:
> 
>   1. They hated Microsoft and everything it stood for.
>   2. They wanted all their mail in one inbox, which was somewhere
>   else.
> 
> This is all the price of attempting to service a campus of 23,000
> people.
> There are, guaranteed, to be at least 230 people who catagorically
> hate
> everything we're doing with email and will avoid it at all costs. We
> didn't have the money to satisfy everyone.
> 
> > The limited service guarantee you describe is reasonable, but
> > presumably
> > there was a reason for those folks using Gmail. An abhorrent uni
> > webmail
> > interface, for example.
> 
> Which is a very large part of the reason that the Associated Students
> voted to outsource student email off of (badly funded) Uni-managed
> systems
> and onto a "free" provider. To a lot of our surprise, considering the
> reputation of the companies at the time, they elected to go with
> Microsoft's service over Google's. This was because MS was able to
> answer
> the question of, "and what, exactly, are you doing with all of this
> tasty
> usage-data we're generating for you" to their satisfaction; Google
> handwaved too much.
> 
> So in a sense, the students voted to forward ALL student email off
> campus.
> Those of us in central services who had been fighting for adequate
> spam-fighting funds to protect student email (20,000 mailboxes
> requires a
> massive amount of money for a paid spam-service, the freeware stuff
> we'd
> been using was univerally viewed as Not Acceptable) cheered. So long
> as
> the FRPA requirements were met (they were) we were happy to let
> someone
> else manage that massive pile.
> 
> --
> Law of Probable Dispersal:
>       Whatever it is that hits the fan will not be evenly
>       distributed.
> _______________________________________________
> Discuss mailing list
> [email protected]
> https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
> This list provided by the League of Professional System
> Administrators
>  http://lopsa.org/
> 

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: [email protected]
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to