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
RR> to a remote mail  account, I've noticed that they're transferring
RR> all mail, including  detectable spam. Is there a way to block
RR> forwarding 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

Reply via email to