domain being filtered, defaults set to no

We support a domain nlr.net here. What I am seeing is that
mail to
addresses within the nlr.net domain is getting filtered for
spam,
despite the fact that the main page for the domain has spam
filtering
disabled. This problem does not occur for our main ucar.edu
domain.
Does anyone have any idea what I could look at to debug
this? It turns
out that some people within the nlr.net domain get messages
from travel
agencies and so forth that have a lot of marketing fluff in
them and get
flagged as spam. 

What I can see is that, in the policy table, spam_lover is
set to "N"
when the account is auto-created, which seems contrary to
the admin
policies set for the domain and is not what happens to
accounts
auto-created in the ucar.edu domain.

Am I missing something obvious?

Thanks,
--Greg


_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

Greg Woods wrote:
> We support a domain nlr.net here. What I am
seeing is that mail to
> addresses within the nlr.net domain is getting
filtered for spam,
> despite the fact that the main page for the domain has
spam filtering
> disabled. This problem does not occur for our main ucar.edu
domain.
> Does anyone have any idea what I could look at to debug
this? It turns
> out that some people within the nlr.net domain get messages
from travel
> agencies and so forth that have a lot of marketing
fluff in them and get
> flagged as spam. 
> 
> What I can see is that, in the policy table, spam_lover
is set to "N"
> when the account is auto-created, which seems contrary
to the admin
> policies set for the domain and is not what happens to
accounts
> auto-created in the ucar.edu domain.

The thing to remember about bypassing spam filtering (or
virus filtering
for that matter) is that a scan can only be avoided if /all/
the
recipients want it bypassed.  If at least one of the
recipients wants
the scanning done, it's going to get done, even if the
other recipients
don't want any scanning performed.  What I'll guess, then,
is that these
items that are "getting filtered for spam" are
addressed to more than
one recipient, and that at least one of those recipients
wants spam
filtering to be performed.

The only practical solution in that case is to set the
bypass_spam_checks and spam_lover columns to 'Y' for the
users who don't
want spam to be filtered.  In other words, set "Spam
Filtering" to
"Disabled" and set "Detected spam should
be..." to "Labeled".  This
won't /always/ prevent the mail from being spam-checked,
but at least it
will ensure that no mail is /blocked/ for those users, even
if spam is
detected.  (Note that there will still be spam cached in
that case, for
false-positive reporting purposes, but it's not a true
"quarantine",
it's just like the non-spam cache.)

Another possibility is that in spite of having set proper
defaults for
the nlr.net domain, the individual users with email
addresses in that
domain may have overridden those defaults for their own
addresses,
enabling spam filtering on an individual basis.  Basically,
take a look
at the recipient lists for these items that are getting
filtered, and
check the settings for those recipient addresses.

-- 
Robert LeBlanc <rjlrenaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamail
guard.com/>

_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

On Wed, 2006-08-30 at 16:29 -0700, Robert LeBlanc wrote:
>  What I'll guess, then, is that these
> items that are "getting filtered for spam"
are addressed to more than
> one recipient

In this case, I am certain that my problem is not due to
multiple
recipients. It's due to how the entry in the policy table
is created. I
have a number of examples, but here's one:

Aug 30 06:00:23 nscan2 postfix/smtp[13416]: 9CF70309C00B:
to=<membershipnlr.net>, relay=127.0.0.1[127.0.0.1],
delay=6,
status=sent (250 2.7.1 Ok, discarded, UBE, id=12149-09) 
Aug 30 06:04:58 nscan3 amavis[9901]: (09901-04)
ESMTP::10024 /var/amavis/tmp/amavis-20060830T055232-09901:
<kdghskghghhotmail.com> -> <membershipnlr.net> Received: SIZE=1521
from nscan3.ucar.edu ([127.0.0.1]) by localhost
(nscan1.ucar.edu
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id
09901-04 for
<membershipnlr.net>; Wed, 30 Aug 2006 06:04:58
-0600 (MDT) 
Aug 30 06:04:58 nscan3 amavis[9901]: (09901-04) Checking:
[124.63.177.47] <kdghskghghhotmail.com> ->
<membershipnlr.net> 
Aug 30 06:05:00 nscan3 amavis[9901]: (09901-04) SPAM,
<kdghskghghhotmail.com> -> <membershipnlr.net>, Yes, hits=6.733 tag=3
tag2=3 kill=3 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_TAGS,
SPF_SOFTFAIL, SUBJ_ILLEGAL_CHARS, quarantine spam-1444449
(maia-spam-quarantine) 
Aug 30 06:05:00 nscan3 amavis[9901]: (09901-04) Blocked
SPAM,
[124.63.177.47] [72.177.209.139] <kdghskghghhotmail.com> ->
<membershipnlr.net>, Message-ID: <m$j-e8fi0-1$6
$611trz1pid0b1l6.82qukg>, Hits: 6.733, 1832 ms 
Aug 30 06:05:00 nscan3 postfix/smtp[10866]: 8EC63230C060:
to=<membershipnlr.net>, relay=127.0.0.1[127.0.0.1],
delay=4,
status=sent (250 2.7.1 Ok, discarded, UBE, id=09901-04) 


Only one recipient. Scanned and found to be spam, and
blocked.

Now, this particular message is not the real problem,
because this
message undoubtedly *was* spam, so we did them a favor by
blocking it.
The problem is that some other nlr.net addresses are getting
false
positives.

Here is the policy table entry for membershipnlr.net:

id      policy_name     virus_lover     spam_lover
banned_files_lover      bad_header_lover       
bypass_virus_checks
bypass_spam_checks      bypass_banned_checks   
bypass_header_checks
discard_viruses discard_spam    discard_banned_files
discard_bad_headers     spam_modifies_subj     
spam_quarantine_to
spam_tag_level  spam_tag2_level spam_kill_level
34950   membershipnlr.net      N       N       N       N    
  N
N       N       N       Y       N       Y       Y       N   
   NULL
3       3       3

"spam_lover" and
"bypass_spam_checks" are both set to
"N", so naturally
the mail is being scanned for spam, and
"discard_spam" is set to "N", so
any false positives are getting quarantined. The system is
doing what
this policy entry is telling it to do.

So the question is, how did the entry get created this way?

I found one error. The nlr.net domain entry did not have
auto-create
set. If that is the case, why is there even a policy entry
at all for
this address? Could the auto-create setting being off
explain why the
policy entry doesn't match the domain settings? Would a
previous message
with multiple recipients create the policy table entry even
if
auto-create were not set for the domain? The real question
is, how did
this policy entry get there and why is it wrong? (There is
no domain
administrator for nlr.net who could have created it).


> The only practical solution in that case is to set the
> bypass_spam_checks and spam_lover columns to 'Y' for
the users who don't
> want spam to be filtered.  In other words, set
"Spam Filtering" to
> "Disabled" and set "Detected spam
should be..." to "Labeled". 

I'll have to do this with SQL commands I think. Part of the
problem is
that this nlr.net domain was forced onto us for political
reasons and I
had zero time to prepare properly for it. We use an external
authentication script which assumed that the left hand side
of all
addresses was a UCAR username to authenticate against. Until
I have a
chance to modify this script, I can't even log in as
"membershipnlr.net", I get logged in as
"membership" and there are no
addresses linked to the account, so right now I can't
access the
membershipnlr.net account via the web page. 

> Another possibility is that in spite of having set
proper defaults for
> the nlr.net domain, the individual users with email
addresses in that
> domain may have overridden those defaults for their own
addresses

Obviously, from above, this isn't possible either. There is
no way for a
nlr.net user to authenticate.

What I want is a solution that will make "no spam
filtering" the default
for the nlr.net domain. We have linked a few nlr.net
addresses to
local user accounts here because we *wanted* them filtered.
This seems
to work fine. One person who was complaining about not
receiving the
messages from the travel agency, I linked that address to my
account
just so that I could find and forward the false positives.
This person
is truly amazing; almost all the messages she gets have a
positive spam
score (although most of them are below 3; it seems that only
the
messages from one particular travel agency go over the
threshold).
Linking her address to my account works, but obviously this
will not
scale well. I could also probably come up with an SQL query
that would
set all addresses in nlr.net to spam_lover=Y and
bypass_spam_checks=Y,
but that would also set all the addresses that have already
been linked
to other accounts here, so that's no good either (maybe I
could manually
reset the filters by logging in as the users here who have
these
addresses linked). Even if I did all this, newly-created
addresses may
have the same problem in the future if I don't find out how
this
happened in the first place.

--Greg



_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

Greg Woods wrote:

> "spam_lover" and
"bypass_spam_checks" are both set to
"N", so naturally
> the mail is being scanned for spam, and
"discard_spam" is set to "N", so
> any false positives are getting quarantined. The system
is doing what
> this policy entry is telling it to do.
> 
> So the question is, how did the entry get created this
way?

Since you say there's no administrator for the nlr.net
domain, the only
answer is that it was created with those settings in the
first place.
When a new domain is created, it inherits whatever settings
the
system-default user (.) has.  It's then up to an administrator
(or the
superadmin) to manually change the domain's settings as
desired.


> I found one error. The nlr.net domain entry did
not have auto-create
> set. If that is the case, why is there even a policy
entry at all for
> this address? Could the auto-create setting being off
explain why the
> policy entry doesn't match the domain settings? Would
a previous message
> with multiple recipients create the policy table entry
even if
> auto-create were not set for the domain? The real
question is, how did
> this policy entry get there and why is it wrong? (There
is no domain
> administrator for nlr.net who could have created it).

With or without the user-autocreation feature, users can
always create
accounts for themselves by logging in and authenticating
properly for
the first time.  It's conceivable that someone logged in
with that
address and supplied the proper credentials, which would
trigger the
creation of the account.

It's also possible that the user-autocreation feature /was/
enabled at
one time, but was later disabled.  This would have to have
been done
manually, however, and since there are no domain
administrators
involved, it would have to have been done by the superadmin.

A final possibility is that the address was added manually
on the
Admin->Users page.  Since no one else has administrative
privileges on
the nlr.net domain, the superadmin would have to have
been the one to
do so.


> What I want is a solution that will make "no spam
filtering" the default
> for the nlr.net domain. 

The domain-default account's settings are the ones you want
to tweak,
then, since those are the ones that get inherited by any new
user
accounts created with addresses in that domain.  Go to
Admin->Domains,
select the nlr.net domain, and configure it to have "Spam
Filtering"
set to "Disabled", and "Detected spam
should be..." set to "Labeled".
This won't have any effect on accounts that have already
been created,
but any /new/ addresses in the nlr.net domain will inherit
these defaults.

-- 
Robert LeBlanc <rjlrenaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamail
guard.com/>

_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users