Re: Custom issues

From: Sterling Hanenkamp (
Date: Wed 19 Sep 2001 - 20:06:44 UTC

  • Next message: Bjarni R. Einarsson: "Re: Logs, hooks, and sublogs"

    <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><>
     Sterling Hanenkamp
     Software Consultant
     Network Resource Group, Inc.
     1105 Hylton Heights
     Manhattan, KS  66502
     (785) 776-5878

    >>> 09/14/01 12:39PM >>> > Sender notification is not a simple problem. Many forms of malware > do things like trojanize Winsock imposing their own SMTP client, > which *forges* the From: address. In some cases I've been able to > infer a sender by putting together information (by eyeball!) from > Received: and From: headers; in other cases users have been able to > recognize who they communicate with at the domain in a Received: > header and have been able to tell me the right E-mail address to > notify. For critters like Hybris, the best I'm typically able to do > is infer the ISP from the Received: header, send a message to abuse > at the main domain of the ISP, and just *hope* they don't /dev/null > the thing.

    I would certainly tend to agree with you that this is not a simple problem. I've been working on it for about 2 months. I would very much prefer to only send out notifications to our own users. However, politics being what they are between consultants and clients, my manager would rather we take the risk of sending false notifications to people in the case of forgers. (My manager is an CNE working on his MCNE, so he does understand the issue and I don't have the typical "Dilbert" managerial snaffus.) Anyway, because my boss wants it, I'm doing it, so it's a matter of "how" to me, not "if."

    > Of course this is a horse of a different radish if the main thing > you're trying to accomplish is to notify *your own* users on outbound > mail -- there you've got a lot more information to go on. But even > in that case if they catch something nasty, you could have a hell of > a time knowing who the real sender is.

    The point of notification is twofold: (1) notify our users they have been infected and probably sending out infectious email without knowing it and (2) notify those sending in that either (a) their message was mangled because it violated the company's attachment policy or (b) their message mangled because it appeared to contain a virus. I am very pleased with the idea of the first, but wary of the second because of some of the issues you've raised and others having to do with issues of notifying automated mailing lists and other originators.

    > What *I'd like* is the ability to snag all of the mail headers based > on what happens with various policies. That would save me *lots* of > time.

    Are you saying you'd like to see notification sent to *you* the administrator based upon policy violations? That would be pretty easy to arrange once I got my system assembled. It'd be just another option hacked into the notification configuration file. For our purposes, this would probably be relatively useless until we already knew of a serious problem. We simply have too many people to monitor that closely--and I'm talking about just a few small businesses in a small town! About the only thing I can think of doing with such a feature is dumping it into a mail folder for review if we discover a problem that this repository of information might be helpful with. OR another possibility would be to write a bot that would analyze the information and look for patterns and then it could preemptively notify us or even the abuse@... addresses of potential issues--that'd be a nifty program to have.

    As an important note about the notification process, the previous version of the notification system was broken and was actually poorly thought out. I realized shortly after writing it that I had made a rather nasty mistake of just trying to send out a normal email message to whatever address was closest to the Errors-to: address--inside of MIMEStream this is the $engine->{"common"}->{"errorsto"} variable. However, this would cause MAJOR irritation to those running mailing lists and could have the potential of creating all kinds of chaos. I don't want to be the author for a mail agent that causes others trouble, even if it alleviates my troubles or my client's troubles. This time, I rewrote the system to send only a single notification message (instead of one per error) and then instead of sending a common message I took the time to read RFC1893 and RFC1894 to send a properly formatted DSN returning a successful delivery notification, but warning the user of a possible security concern (DSN code 2.7.0). This will then provide the user with a useful message for his/her information and will provide automated user agents enough information to process the message (and probably ignore it since it's a 2.x.x).

    It's certainly an interesting debate.

    Cheers, Sterling

    hosted by