2 spam checking issues...

[Julian Field]

    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "US-ASCII" character set.  ]
    [ Some characters may be displayed incorrectly. ]

Bob Jones wrote:

> Julian Field wrote:
>
>>> 2.  The second is with skipping spam checks for certain addresses.  It
>>> seems that if an address we have added to the ruleset to skip spam
>>> checks is listed in the CC or BCC fields (maybe the TO field as well,
>>> but haven't seen an example of this yet), that message isn't scanned
>>> for
>>> *any* of the recipients.  Is this the expected behavior?  Is there a
>>> way
>>> to work around this issue?
>>
>>
>>
>> There is a workaround. Currently, when faced with a message with
>> multiple headers, some of which want spam checks and some of which
>> don't, it uses the answer for the first recipient. You can change this
>> so that it uses any of the recipients by editing
>> /usr/lib/MailScanner/MailScanner/ConfigDefs.pl. Look for the line
>> starting "SpamChecks". If you look backwards (towards the start of the
>> file) from there, you will see that it is in the [First,YesNo] section.
>> Move that line into the [All,YesNo] section, then stop and restart
>> MailScanner.
>
>
> Okay, this is not what we are seeing at all.  I checked the
> ConfigDefs.pl file and we have not changed everything, the entry is
> still in the [First,YesNo] section.  We have run various tests sending a
> message to 2 addresses.  One address is listed in the ruleset to not be
> scanned as spam (noscan designation) and the other is not listed, so
> should be scanned.  We user virtusertables here, so we tried tests with
> and without virtusertables, and with and without aliases.  So, in the
> data below a native address is one that is user at host, a
> virtusertable-native address is a virtualaddress such as user at domain
> which points to a native address such as user at host and finally a
> virtusertable-aliases address is a virtualaddress such as user at domain
> which points to a file in /etc/mail/aliases.  The NO and YES entries at
> the end of each line list whether the message received by that account
> was scanned for spam or not.  I hope that makes sense.  Here's the data:
>
> native:noscan, native:scan                                      NO, NO
> native:scan, native:noscan                                      NO, NO
>
> virtusertable-native:scan, virtusertable-native:noscan          NO, NO
> virtusertable-native:noscan, virtusertable-native:scan          NO, NO
>
> virtusertable-aliases:scan, virtusertable-aliases:noscan        NO, NO
> virtusertable-aliases:noscan, virtusertable-aliases:scan        NO, NO
>
> virtusertable-aliases:noscan, virtusertable-native:scan         NO, NO
> virtusertable-native:scan, virtusertable-aliases:noscan         NO, NO
>
> native:noscan, virtusertable-native:scan                        NO, YES
> virtusertable-native:scan, native:noscan                        YES, NO
>
> If you'll noticed, in the first 4 rounds of testing, the order the
> address appeared on the line did not impact whether or not any of the
> messages were scanned, whereas from what you wrote above it seems you
> are saying that the first address on the TO line should determine if any
> of the messages are scanned.  Am I just being dense here and missing
> something?

It's not the order on the To: line that counts, it is the order of the
recipients in the message envelope.

>
> Also of note is the last test, where mixing a native and virtualized
> address seems to also break what you mention above, but in a different
> way.
>
> So, I'm sure I'm just missing something here and hopefully someone can
> point it out.
>
>
>> May be this might be a better place for the option.
>> What do you think?
>> What does anyone else think?
>
>
> As for opinions on the matter, it makes sense to me that the default
> behavior for a message to multiple recipients with some wanting scanning
> and some not, we should scan those that want it and not scan those that
> don't want it.

There is an option in MailScanner.conf which may well achieve the
settings you want:

# When trying to work out the value of configuration parameters which are
# using a ruleset, this controls the behaviour when a rule is checking the
# "To:" addresses.
# If this option is set to "yes", then the following happens when checking
# the ruleset:
#   a) 1 recipient. Same behaviour as normal.
#   b) Several recipients, but all in the same domain (domain.com for
example).
#      The rules are checked for one that matches the string "*@domain.com".
#   c) Several recipients, not all in the same domain.
#      The rules are checked for one that matches the string "*@*".
#
# If this option is set to "no", then some rules will use the result they
# get from the first matching rule for any of the recipients of a message,
# so the exact value cannot be predicted for messages with more than 1
# recipient.
#
# This value *cannot* be the filename of a ruleset.
Use Default Rules With Multiple Recipients = no

--
Julian Field
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store
Professional Support Services at www.MailScanner.biz
MailScanner thanks transtec Computers for their support

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654

------------------------ MailScanner list ------------------------
To unsubscribe, email jiscmail at jiscmail.ac.uk with the words:
'leave mailscanner' in the body of the email.
Before posting, read the MAQ (http://www.mailscanner.biz/maq/) and
the archives (http://www.jiscmail.ac.uk/lists/mailscanner.html).

Support MailScanner development - buy the book off the website!