[Mimedefang] Justifying greylisting to management

[Matthew S. Cramer]

On Sun, Feb 26, 2006 at 02:56:10PM -0500, Jeff Rife wrote:

> This is why I turned to this group of experienced mail admins.  I need 
> a way to justify occasionally delaying good e-mail to people who have 
> already said that occasionally *blocking* good e-mail (and thus 
> *really* delaying it) is acceptable.

That shouldn't be too hard.

Here's what I do to handle the PHB concerns.  We are a big company so
we have a dedicated helpdesk staff and my goal when designing a
solution and then putting it into production is to use the helpdesk as
much as possible so that never, ever, ever do I have to talk to a
user.  Especially a PHB.  :)

Calls go into our helpdesk and they handle them one of a few ways:

1. "I got a spam and I want it blocked."  The helpdesk tells them to
   delete it and if it a recurring subject line (like an agressive
   opt-out "oh we lost it pls opt out again", "oh and pls opt out
   again" newsletter) then they help the user create a rule in their
   MUA to delete.
2. "I never got an email because of the spam filter."  This doesn't
   happen, we only drop egregious spam, and flag anything else so
   users can filter with their MUA if they choose.  SO I told the
   helpdesk to treat it as a user error operating the MUA and it
   always is...
3. "I got an email that was flagged as spam but isn't."  HD knows how
   to handle this "whitelist request" - asks user for enough header
   info to open a ticket to a sysadmin to add a line to our
   whitelist.cf which RulesDuJour grabs each night.
4. "Why didn't my email come instantly????"  Helpdesk explains
   greylisting then instructs user to have email resent by sender THIS
   TIME then opens a similar ticket to above so sysadmin can whitelist
   the IP block.
5. We hacked the MIMEDefang move to URI code to do a couple of extra
   things, as we save the executable attachments to one directory and
   then quarantine them for 24 hours before moving them to where users
   can download.  We were getting burned a few times each year by new
   viruses that got on our network before the virus vendors had
   updated their signatures.  We built a web interface so HD can
   immediately "publish" the executable but user has to jump through a
   few hoops - answer some questions indicating they know the sender,
   requested it, and called the sender to verify the exe they received
   was actually what was sent.  It is a big enough PITA to keep the
   idiots who click and drool from hurting our network yet getting
   patches and things like that to develoeprs right away if they need
   it.

We keep stats on this stuff so I can show management "we got this many
calls, which is 1% of all attachments we received."  "Only 20% of exe
attachments are ever even downloaded."  "We got 2 calls this month for
whitelists from FP spam and 1 call for FP from greylisting."  Etc.

So basically, arm yourself with a process you can use to give the
users what they need.  And also a way to track it, so PHB can know the
impact and make the call to back out.

We also publish publish publish anything we do on our Intranet.

Most of the battle is getting people out of the "instantaneous email
delivery from anywhere to anywhere is business critical" paradigm to
the "quality email is business critical" paradigm, where they accept
spam filtering as long as it is handled in an enterprise fashion.

I've taken to making a monthly report, putting cost around my service
including amortization and depreciation of hardware, time, etc., so
management can compare it to the enormous sums service companies
charge for it (MessageLabs - $3.00/user/month; Our system:
$.06/user/month).

Your PHB is worried about pissing off *HIS* PHB so arm him with what
he needs to be proud of and defend the service.  Mine gets stats so
that when CEO complains that "the spam filtering sucks" due to his
single anecdote from some other executive concerning an email about a
golf outing that got delayed by 10 minutes, he can produce a doc
showing our stunning low costs, lack of FPs, etc.

A co-worker writes for Sys Admin and he covers a lot of this here:

http://www.samag.com/documents/s=9767/sam0513a/0513a.htm

[Plug alert - a quote from me is the money-shot of his article...]


HTH,

Matt

-- 
Matthew S. Cramer <mscramer at armstrong.com>          Office: 717-396-5032
Project Manager, Planning and Service Management    Fax:    717-396-5590
Armstrong World Industries, Inc.                    Cell:   717-917-7099