Re: Moving forward ...

>
> The analogy is good, but the parts of the message likely to be
> intercepted/modified might be different.  Also, sometimes you
> will want
> notifications to the end user, sometimes not -- doesn't have to be
> malware detection being done at the superids layer, could be
> anti-spam,
> or policy monitoring, in which case notification might make sense --
> but I expect the purpose of sticking headers in the email to some
> extent is that the system which is doing the identification/tagging
> might be a different system from the one which ultimately
> makes routing
> or other "what do I do with this message now that I know what it is"
> decisions.  So I can picture situations where the IDS would want to
> insert some headers in the message and pass it downstream for
> something
> else to decide how to handle it.

Agreed. Some sort of indicator that this message had some strange
characteristics which may not be apparent when simply analysing the
message. (like it was delivered in a connection which also attempted to
deliver to a lot of other addresses, all starting with 'r').

> C
>
> On Feb 26, 2004, at 3:07 PM, Jesse Dougherty wrote:
>
> > This is similar to the case where a virus is stopped at the gateway
> > and a notification of this event is delivered to the
> recipient to make
> > sure they're aware the communication was blocked.  Is this a decent
> > analogy? In this case a header may explain that all/part of the
> > communication was blocked for some reason.
> >
> > Not sure that this would apply to an IDS situation though,
> would it?
> > Like wormspew, the recipient probably doesn't want the
> notifications,
> > as the message is essentially spam.
> >
> > (though perhaps the spam filter at the next tier should catch that?)
>
>