|
|
|
date: Thu, 2 Mar 2006 07:29:43 -0800,
group: microsoft.public.exchange2000.general
back
Re: Delaying SMTP Outbound Messages???
[Please, don't send multiple independent posts to multiple newsgroups.
You can address the _same_ post to multiple newsgroups if you
absolutely need to. The latter ensures that responses go to all
groups, not wasting people's energy.]
>Sure, the reason we are doing this is to be able to "get back" an email if
>accidently sent. We have sent a few confidencial documents the last 1/2 year
>and now the CEO is jumping up and down. We turned autofil off on everyones
>outlook, but that is causing major commotion. So if we could have all
>message wait and queue for 5 mins we could stop an accident from happening.
This is a curious business case. Presumably, you are talking about
users who, nanoseconds after they hit send, both realize _and_ confess
that they have done a bad deed. It's not typical that compliance
systems rely on users' self-reported non-compliance. Rather, they
rely on keyword filtering of outgoing mail and/or "moderation" of
outgoing mail (i.e. forcing mail from lower-downs to be approved by
higher-ups). If you are really in a compliance crisis, you should
really look into something more robust.
Nonetheless, I do have another suggestion in addition to Nick's good
pointer of using scheduled queue runs to hold the queue and reduce
your exposure (or, at least, reduce the exposure of mail sent early in
the queue interval). The problem with his technique is that it gives
a variable delay depending on when a given message was originated, in
order to widen the overall window for auditing/deleting messages, and
some of those delays are much shorter than 5 minutes, some longer.
What I'd suggest looking into is using greylisting internally. If you
don't know what greylisting is, it's a spamfighting technique (a very
accurate one, as long as you acknowledge its consequences, but in fact
its negative consequences as an incoming anti-spam measure are exactly
what makes it a good fit as an outgoing anti-disclosure measure). With
greylisting, an SMTP server keeps track of a "triplet" for each
incoming connection. The triplet is the connecting IP, the sender's
address, and the recipient's address. If the server is seeing a
triplet for the first time, it will send back a temporary SMTP
failure, indicating that the connecting IP should retry after one
retry interval. Upon retry, the server notes that it's already seen
the triplet and lets the SMTP connection complete.
So, what you would do is set up a secondary IIS SMTP virtual server
that the primary virtual relays all outgoing messages to; this
secondary VS could be on the same server as the primary. On the
second VS, you enable greylisting, with something like a 5-minute
blocking period and a 1-minute unblock period. On the first VS, you
set a 5-minute retry timer. The triplets that the second VS keeps
track of will always have the same IP, but the sender/receiver combos
will be different. The first attempt with a given triplet will be
delayed and left in the queue: there's your 5-minute retry. The
second attempt will be allowed. Several inexpensive (<$100) anti-spam
and port tunneling products feature greylisting and would fill the
bill, if you're intrigued. I'm certain that they could be tweaked to
do close what you prescribed, for the strange situation you described.
Still, I think the business case here is for a real compliance
package, not a strange band-aid wherein users are still expected to
police themselves, and there's no real oversight process. My 2 on
that.
--Sandy
date: Fri, 03 Mar 2006 03:33:01 -0500
author: Sanford Whiteman
|
|
