I'm nearly finished with my custom version of a sanitize.pl replacement that will perform automatic sender notification. However, I do have a couple issues to bring up. The new logging system makes knowing when a sender needs to be notified easy, but know who needs to be notified is definitely not easy. This is related to the fact that the Sanitizer engine holds the MIMEStream message completely internal to the sanitize() sub.
There is an obvious and simple solution to this problem. You could add a "message" attribute that pointed to the current MIMEStream object for use by the custom hook. This way, the subroutine could just access the "common" elements to determine what the "errorto" value is and send errors there. There may be a better way, but that's the best way I can see.
In the meantime, I will continue using my own work around, which is to prescan the header for the addresses that we might need to send an error to.
Related to this, we also would like to have the ability to use different configurations depending on the sender or recipient. That is, we may want to scan some, but not all mail going out from our host depending on who sent it. Not only that but we would like different configurations depending on who sent or is recieving it--we handle multiple clients who each might want slightly differing policies. This isn't too critical, but it is something we've considered.
Scanning based on recipient is easy because Sendmail can just tell us who the mail is being delivered to. However, the only way I can get it to work going the other way is to do the prescanning I mentioned above. Even if the logging issue was fixed in the way suggested, I would still have to prescan the header to determine the configuration to use before sanitize is called. This might be implausible to solve and I can't think of any practical way of getting to a solution without rewriting the way MIMEStream and Sanitizer work. Rewriting code is unacceptable because my boss wants to be able to upgrade Sanitizer in the future with only minimal rewriting of the code. This is especially true since I am going to grad school in January and won't be able to work for him anymore except on a as-needed-and-I-have-time basis.
Anyway, I just thought I'd raise those issues to you. Though, you've anticipated and been ahead of me all the way so far. ;)
-- <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> Sterling Hanenkamp Software Consultant Network Resource Group, Inc. 1105 Hylton Heights Manhattan, KS 66502 (785) 776-5878 firstname.lastname@example.org