2 spam checking issues...
bob.jones at USG.EDU
Mon Mar 28 20:59:38 IST 2005
[ 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. ]
Julian Field wrote:
> Bob Jones wrote:
>> 1. We received a message that bypassed the spam check. The relevant
>> header info is:
>> Received: from 22.214.171.124 ([126.96.36.199])
>> by hermes.bor.usg.edu (8.12.11/8.12.11) with SMTP id
>> j2NEuQkB002299; Wed, 23 Mar 2005 09:56:35 -0500 (EST)
>> The IP address of our mailserver (hermes.bor.usg.edu) is 188.8.131.52.
>> It seems that the spammer used our IP address as his HELO during the
>> SMTP connection. The *actual* IP address of the spammer is within the
>> () in the next field. To determine if a ruleset applies, is mailscanner
>> doing a simple grep? It seems to me that it should be grepping for what
>> is within the () and ignore what the HELO was as that can be forged. Or
>> is there an issue here I'm not grasping.
> With sendmail, MailScanner uses the IP address at the far end of the
> SMTP connection, which should be the real address unless they are doing
> some IP spoofing attack (which looks unlikely as it gives away the
> 220... IP address). It doesn't just use the "Received" address at all.
I went back and looked at this message again and noticed that it was a
red herring, the issue with this one is the same issue as the next one
mentioned. It also had an address in the CC field listed in the don't
>> 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
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
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.
Also, just to clarify, the ruleset I'm using is for the Spam Checks=
line of the config file.
------------------------ 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!
More information about the MailScanner