You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Roy McMorran <mc...@mdibl.org> on 2005/12/05 22:21:14 UTC
From: "" <> whitelisted?
Hello list,
I'm getting frequent false negatives on messages like this:
>From - Mon Dec 05 15:15:29 2005
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on xxx.mdibl.org
X-Spam-Report:
* 0.9 SUBJ_HAS_SPACES Subject contains lots of white space
* 2.2 INVALID_DATE Invalid Date: header (not RFC 2822)
* 0.1 FROM_NO_LOWER From address has no lower-case characters
* -100 USER_IN_WHITELIST From: address is in the user's white-list
* 1.4 MSGID_FROM_MTA_ID Message-Id for external message added locally
* 4.3 SUBJ_ILLEGAL_CHARS Subject: has too many raw illegal characters
* 0.5 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date
* 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
* lines
* 0.5 NUMERIC_HTTP_ADDR URI: Uses a numeric IP address in URL
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
* [score: 1.0000]
* 0.0 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
* 0.9 FRONTPAGE RAW: Frontpage used to create the message
* 0.2 MIME_BASE64_NO_NAME RAW: base64 attachment does not have a file
* name
* 1.9 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding
* 2.1 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
* [URIs: 08000800801.com.tw]
* 2.7 FORGED_OUTLOOK_HTML Outlook can't send HTML message only
* 0.3 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary
* 4.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook
X-Original-To: mcmorran@mdibl.org
Delivered-To: mcmorran@mdibl.org
X-Original-To: mailman-owner@lists.mdibl.org
Delivered-To: mailman-owner@lists.mdibl.org
From: "" <>
To: "mailman-owner" <ma...@mdibl.org>
Subject: §Ṳ́w°µ¨ì¾aºô¸ôÁȨú«ùÄò©Ê¦¬¤J ( mailman-owner )
Date: Mon, 05 Dec 05 15:32:17 ¥x¥_¼Ð·Ç®É¶¡
...etc...
How is it that this (weird, sort-of-null) From: address is whitelisted?
It's surely not listed in my local.cf or user_prefs. Any ideas?
Thanks,
-r
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
Re: From: "" <> whitelisted?
Posted by Roy McMorran <mc...@mdibl.org>.
Daryl C. W. O'Shea wrote:
> On 05/12/2005 4:21 PM, Roy McMorran wrote:
>
>> Hello list,
>> I'm getting frequent false negatives on messages like this:
>>
>> From: "" <>
>>
>> ...etc...
>>
>> How is it that this (weird, sort-of-null) From: address is
>> whitelisted? It's surely not listed in my local.cf or user_prefs.
>> Any ideas?
>
>
> What's in the return-path?
Bingo.
Return-Path: <ma...@mdibl.org>
...which is indeed whitelisted. Thanks!
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@mdibl.org
Re: From: "" <> whitelisted?
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 05/12/2005 4:21 PM, Roy McMorran wrote:
> Hello list,
> I'm getting frequent false negatives on messages like this:
>
>> From - Mon Dec 05 15:15:29 2005
>
> X-Original-To: mcmorran@mdibl.org
> Delivered-To: mcmorran@mdibl.org
> X-Original-To: mailman-owner@lists.mdibl.org
> Delivered-To: mailman-owner@lists.mdibl.org
> From: "" <>
> To: "mailman-owner" <ma...@mdibl.org>
> Subject: §Ṳ́w°µ¨ì¾aºô¸ôÁȨú«ùÄò©Ê¦¬¤J ( mailman-owner )
> Date: Mon, 05 Dec 05 15:32:17 ¥x¥_¼Ð·Ç®É¶¡
>
> ...etc...
>
> How is it that this (weird, sort-of-null) From: address is whitelisted?
> It's surely not listed in my local.cf or user_prefs. Any ideas?
What's in the return-path?
Re: bayes_journal permissions
Posted by Matt Kettler <mk...@evi-inc.com>.
Pollywog wrote:
> On 12/06/2005 12:27 am, Matt Kettler wrote:
>
>>David Buttrick wrote:
>>
>>>Is there a control for the permissions on the bayes_journal file?
>>>
>>>I'm using a shared bayes db, and users do not have permissiosn on the
>>>file because it is created chmod 600.
>>>
>>>Is there something i can do in the config files?
>>
>>What's your bayes_file_mode setting set to?
>>
>>If you have a shared bayes db, it should be 0777 (note: 0777 not 0666 due
>>to use in dir creation)
>
>
>
> Wouldn't it be better to set bayes_file_mode to 0770 and add the users to the
> same group as the file, say "users" group?
>
>
> 8)
That works too, although you also have to add "nobody" to that group (any mail
set to scan as root falls back to nobody).
At that point the difference between 0770 and 0777 is not exactly very large.
Sure named, http, cron and other service users can't write it, but that's about it.
For someone exploiting as a service user, It *might* be possible to privilege
escalate by maliciously corrupting the bayes DB. However, when using spamd bayes
is never accessed as root so the potential gain here is small, you'd only be
able to escalate to a regular local user, not to root. From there they might
have better tools available to hop into root via another privilege escalation,
but it's a long shot that they couldn't just do it directly from the service user.
While I agree it's a good idea from a "belt and suspenders" approach, there are
better measures one should take first. (ie: make sure all network daemon
processes are chroot as well as setuid)
Re: bayes_journal permissions
Posted by Pollywog <li...@shadypond.com>.
On 12/06/2005 12:27 am, Matt Kettler wrote:
> David Buttrick wrote:
> > Is there a control for the permissions on the bayes_journal file?
> >
> > I'm using a shared bayes db, and users do not have permissiosn on the
> > file because it is created chmod 600.
> >
> > Is there something i can do in the config files?
>
> What's your bayes_file_mode setting set to?
>
> If you have a shared bayes db, it should be 0777 (note: 0777 not 0666 due
> to use in dir creation)
Wouldn't it be better to set bayes_file_mode to 0770 and add the users to the
same group as the file, say "users" group?
8)
Re: bayes_journal permissions
Posted by David Buttrick <db...@geekforce.com>.
Thanks!
On Dec 5, 2005, at 6:27 PM, Matt Kettler wrote:
> David Buttrick wrote:
>> Is there a control for the permissions on the bayes_journal file?
>>
>> I'm using a shared bayes db, and users do not have permissiosn on the
>> file because it is created chmod 600.
>>
>> Is there something i can do in the config files?
>
> What's your bayes_file_mode setting set to?
>
> If you have a shared bayes db, it should be 0777 (note: 0777 not
> 0666 due to use
> in dir creation)
>
Re: bayes_journal permissions
Posted by Matt Kettler <mk...@evi-inc.com>.
David Buttrick wrote:
> Is there a control for the permissions on the bayes_journal file?
>
> I'm using a shared bayes db, and users do not have permissiosn on the
> file because it is created chmod 600.
>
> Is there something i can do in the config files?
What's your bayes_file_mode setting set to?
If you have a shared bayes db, it should be 0777 (note: 0777 not 0666 due to use
in dir creation)
bayes_journal permissions
Posted by David Buttrick <db...@geekforce.com>.
Is there a control for the permissions on the bayes_journal file?
I'm using a shared bayes db, and users do not have permissiosn on the
file because it is created chmod 600.
Is there something i can do in the config files?
Thanks.
David
Re: From: '' <> whitelisted?
Posted by Steve Thomas <li...@sthomas.net>.
> 1) null sender isn't in the default whitelist
>
> 2) the rule matched isn't due to the default whitelist, as that would show
> up as
> USER_IN_DEF_WHITELIST, instead of USER_IN_WHITELIST.
I guess I need to brush up on my SA rules vocabulary.. :)
> 3) The message in question has the null path as it's From: header address,
> this
> is COMPLETELY different from the return path mentioned in RFC 2821.
Yes, it is, and I realized my mistake about the same time as I released
the mouse button from clicking "Send". Someone else had asked about the
return-path, and I was waiting on a response to that before correcting
myself, if necessary.
Re: From: '' <> whitelisted?
Posted by Matt Kettler <mk...@evi-inc.com>.
Steve Thomas wrote:
>>How is it that this (weird, sort-of-null) From: address is whitelisted?
>>It's surely not listed in my local.cf or user_prefs. Any ideas?
>
>
> Whether or not the null sender should be in the default whitelist is
> subjective, but I think most would agree that it's prudent.
Well, three points:
1) null sender isn't in the default whitelist
2) the rule matched isn't due to the default whitelist, as that would show up as
USER_IN_DEF_WHITELIST, instead of USER_IN_WHITELIST.
3) The message in question has the null path as it's From: header address, this
is COMPLETELY different from the return path mentioned in RFC 2821.
Really I suspect this has to do with SA looking at *MANY* headers other than
just From: when checking to see if the message should be whitelisted. I suspect
this message has a whitelisted domain or address in the Resent-From:,
Return-Path:, Resent-Sender:, Envelope-Sender:, or in one of the Received: headers.
Re: From: '' <> whitelisted?
Posted by Steve Thomas <li...@sthomas.net>.
> How is it that this (weird, sort-of-null) From: address is whitelisted?
> It's surely not listed in my local.cf or user_prefs. Any ideas?
>From RFC 2821:
--------------------------------
If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path). Formats specified for non-delivery reports by other standards
(see, for example, [24, 25]) SHOULD be used if possible.
This notification message must be from the SMTP server at the relay
host or the host that first determines that delivery cannot be
accomplished. Of course, SMTP servers MUST NOT send notification
messages about problems transporting notification messages. One way
to prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a message
is transmitted the reverse-path MUST be set to null (see section
4.5.5 for additional discussion). A MAIL command with a null
reverse-path appears as follows:
MAIL FROM:<>
--------------------------------
Whether or not the null sender should be in the default whitelist is
subjective, but I think most would agree that it's prudent.