You can change your rules to forward spam to separate user quarantine mailbox (not a subfolder or sub-mailbox) that does not have forwarding setup. You just cannot make the rules forward (or move)the spam to a sub-mailbox like [EMAIL PROTECTED] on an account that is forwarded.
Craig > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rick Robeson > Sent: Thursday, September 01, 2005 1:17 PM > To: [email protected] > Subject: RE: [sniffer] can auto-forward be disabled when spam > is detected? > > I think I see the problem, though not a quick solution. > > Mxguard merely handles traffic between imail and sniffer and > calculates its spam score and probability. IT has no override > capability excepting its own white and black lists blocking > calling for sniffer processing. > > IMail's processing order of activies (as listed in > http://www.ipswitch.com/support/imail/guide/imailug8.1/Chapter > %204%20process > ing2.html#47027 > ) > show that forwarding instructions are handled before domain > or user incoming rule execution. > > It is the domain and user incoming rule execution that is the > first level of being able to pick up sniffer/mxguard > instructions (via x-header presence/value). Only connection > or content filtering is used by imail prior to the forwarding > process. I don't see any way to have mxguard or sniffer > affect the connection or content filtering rules unless they > were somehow able to (for example) add a dummy url to the > content of the email which would trigger the content > filtering url blacklist. > > Ipswitch probably considers the current forwarding processing > order a feature (after all it allows another external mail > server rulebase to inject it's rules). Unfortunately, in > large quantity, lumping multiple aliases from multiple sites > to a one or more users who then want auto-forward to another > email server for internet mail (i.e. gmail) makes it look > like my server is generating spam to gmail/yahoo/etc. > > Ideas? > > > Rick Robeson > getlocalnews.com > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil > Sent: Thursday, September 01, 2005 8:44 AM > To: Rick Robeson > Subject: Re: [sniffer] can auto-forward be disabled when spam > is detected? > > > On Thursday, September 1, 2005, 9:12:17 AM, Rick wrote: > > RR> I'm using Sniffer with MXGuard, and Ipswitch Imail Server. > RR> > RR> For accounts who have auto-forwarding setup to transfer > mail to a > RR> remote mail account, I've noticed that they're transferring all > RR> mail, including detectable spam. Is there a way to block > forwarding > RR> when spam is detected? > > That's an mxGuard question. SNF makes no distinctions on > where the message is going in an IMail environment... My > guess is that mxGuard is either not scanning these messages, > or that it either can't or doesn't take action in those cases. > > If I had to guess it's probably most likely that IMail > doesn't give mxGuard a chance to effect these messages, or > that in a similar way mxGuard doesn't effect them due to the > "split envelope" problem. > > Please let me know what you find out. > > Thanks, > > _M > > PS: Split Envelop Problem - When the SMTP envelope of a > messages indicates multiple recipients, and one of the > recipients has rules that would dispose of the message in > some way there is an inherent conflict. It goes against RFCs > to deliver the message to one recipient and not the other > (though that is probably desirable and may be/become the best > practice) since that would require "splitting the envelope" > and the message into two copies with each copy following a > different path. > > In a strict interpretation of email processing rules the > message must be either delivered to all recipients on the > envelope or not delivered. In many cases the final rule turns > out to be: "If anyone is supposed to receive this message > then everyone must. Once they have received it they can > discard it if they wish, but an MTA shouldn't make that call > since it has essentially 'signed up' to be responsible for > delivering the message as is." > > > This E-Mail came from the Message Sniffer mailing list. For > information and (un)subscription instructions go to > http://www.sortmonster.com/MessageSniffer/Help/Help.html > > > This E-Mail came from the Message Sniffer mailing list. For > information and (un)subscription instructions go to > http://www.sortmonster.com/MessageSniffer/Help/Help.html > This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
