Outbound filtering – part 2

In my previous post, I mused about what it takes to do outbound spam filtering.  If customers use us for outbound mail and start relaying spam, it damages our reputation and credibility.  Ergo, we need to come up with a solution wherein we don't deliver spam.  But the problems are not trivial:

  • How do we actually filter outbound mail? Do we assume it works the same as inbound? For example, suppose one part of our filters tends to be overly aggressive. Should we leave it as the same behaviour as inbound filtering? Skip that filter? Raise the threshold at which point we make a decision that a message is spam?

  • Suppose that we decide that the filter should be different for outbound as for inbound.  This means we have to maintain two different roles for mail filter deployment.  This means we have to engage Network Operations who run our deployment and tell them to pay special attention to outbound filters.  Do we want to go through all that trouble?  Is there a better technical solution?
  • What should we do with mail we identify as spam? Quarantine it? Bounce it? Drop it?  All three have implications that need to be dealt with.
  • How do we notify the user that we are identifying their mail as spam? By email? How many times per day? As soon as we identify it, should we notify the user?  Or, should we wait a period of time?
  • Are there exceptions to spam filtering? Should certain senders (like a Legal team discussing a spam website for which we have a delete-all-spam-if-URL-is-mentioned rule) always be allowed to send? In other words, is there an outbound Safe Senders?

These are the major issues surrounding policy.  We're still in the beginning stages of how we want to treat outbound spam - we can either implement policies that behave upon individual spam messages and senders, or we can implement policies that affect the domain and sending IP as a whole.

Comments (3)
  1. Norman Diamond says:

    "What should we do with mail we identify as spam? Quarantine it? Bounce it? Drop it?"

    Bounce it.  Prepare for complaints, some of which will be well earned, and accept them.  Here are reasons for bouncing 100% of the time:

    (a)  It’s a false positive.

    (a1)  It was an important message, the user needs to know that the message wasn’t delivered, and they’ll find another way to communicate.  Expect the user to swear at you.  Accept it.  Fix your bugs.

    (a2)  It wasn’t an important message, but it’s still better to inform the user than to deceive the user.  Expect the user to swear at you.  Accept it.  Fix your bugs.

    (b)  It’s really a spam.  The user will get lots of well-earned bounces.  They’ll discover that they’re infected.  90% of the time, expect the user to swear at you.  Tell them if they send another spam they’ll be TOS’ed.  If they send another spam then TOS them.

    "is there an outbound Safe Senders?"

    And what about outbound Safe Recipients?  I’m hardly a Legal team member, but if a spam reaches me then I report it to the administrators of the ISPs that sent it and that serve the spam websites or drop boxes.


    My complaints should be bounced by spam-only ISPs who bounce reports of their spams because they correctly detect that their spams are spams


    and should not be bounced back to me by my own ISP.

    So yes, you have to do different work for outbound spams than for inbound spams.  If one sender is sending up to maybe 10 copies of a spam, it might not be spamming.

  2. Benoit Vidil says:

    How do we actually filter outbound mail? Do we assume it works the same as inbound?

    i think there is two options:

    no filter fo outgoing emails if it comes from your internal users and if they signed an antispam chart

    otherwise same inbound filter (more restictive)

  3. Norman Diamond says:

    > and if they signed an antispam chart

    Unfortunately that’s not good enough.  A 0-day exploit could still join them to a botnet without their knowledge.  Outbound servers still have to count the number and kinds of messages from each user and inform the user if things look suspicious.

Comments are closed.

Skip to main content