"Steve" == Steve Thomas <[EMAIL PROTECTED]> writes: Steve> Steve> If the forwarding is being done via .forward, why not just use Steve> procmail instead and check the message, then either drop it in your Steve> spool dir or forward it if it's not spam?
I'm not sure I understand what you're proposing here. At what point would this happen? I don't think I can do anything with procmail once sendmail determines that a particular message isn't bound for local delivery. Steve> If you're using aliases or virtual user tables, you may want to Steve> have a look at one of the milters. I'm not a sendmail guru by any Steve> stretch of the imagination, but I don't know if a rule could be Steve> used since SA typically gets the message after sendmail has Steve> released it. I'm already using the milter interface to call the spamd incarnation of SA. Since I'm seeing SA headers being added to all messages, I know that everything is being scanned. If the message is destined for local delivery, procmail is looking for the "X-Spam-Status: Yes" header and putting the locally-delivered spam in a special area. My problem is that messages that aren't destined for local delivery due to forwarding never make it to the procmail LDA; they are sent on ahead by sendmail, complete with the SA headers identifying the message as spam. I could rewrite or ignore my users' .forward files, but I'd rather do it transparently, and not give them the opportunity to screw it up. :-) I have thought of disabling .forward files in my sendmail.cf (which would trigger local delivery), then honoring the .forward from within procmail if the message is not spam. This might work, but it seems somewhat inelegant if the same thing could be done from within sendmail. I'm not sure if this or a similar mechanism would work for aliases map entries. Steve> You could also use some sort of shell script which your alias would Steve> point to. The script could filter thru SA and take the appropriate Steve> action. E.g.: Steve> Steve> bob: [EMAIL PROTECTED] Steve> ed: [EMAIL PROTECTED] Steve> Steve> in your aliases file could become: Steve> Steve> bob: |"/path/to/somescript [EMAIL PROTECTED]" Steve> ed: |"/path/to/somescript [EMAIL PROTECTED]" Steve> Steve> where "somescript" takes the message on STDIN, runs SA on it, then Steve> either stores it in your spool dir or forwards it to the address Steve> supplied as the argument. Be careful about locking your files if Steve> taking this approach. This might work, maybe even with procmail as I mentioned above. I'll have to look at it more closely. Steve> I don't know if virtual user tables have the same ability to pipe Steve> to a program - haven't had a need for it yet. I'm not at all familiar with these. Again, something for me to look at. Thanks for the feedback. You've given me some ideas. I was hoping someone would post a sendmail rule set to do special handling depending on the 'X-Spam-Status:' header, but maybe that's a harder nut to crack than I realize. -- Mike Scheidler [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
