Mailing List Archive: SpamAssassin: users

Undisclosed recipients :; -- again

Index | Next | Previous | View Threaded

philipp_subx at redfish-solutions

Nov 23, 2009, 11:05 AM

Post #1 of 15 (1784 views)
Permalink

Undisclosed recipients :; -- again

Hi.

I want to block all messages that I'm getting that have:

To: undisclosed recipients: ;

with no Cc: line.

Unfortunately, the rule that I have:

header L_UNDISCLOSED To:raw =~ /undisclosed-recipients: ?;/
describe L_UNDISCLOSED To: list is meaningless and no Cc:
score L_UNDISCLOSED 10.0

also seems to match when there's no "To:" line at all, only a "Cc:" line
(which isn't what I want).

Why is Spamassassin thinking that there's a header 'To:' line, and it
says 'undisclosed recipients' when it doesn't exist?

This is on Fedora Core 11, updated (so SA 3.2.5, Perl 5.10.0, and
Sendmail 8.14.3)

Thanks,

-Philip

list-subs at secnap

Nov 23, 2009, 11:10 AM

Post #2 of 15 (1723 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

Philip Prindeville wrote:
> Hi.
>
> I want to block all messages that I'm getting that have:
>
> To: undisclosed recipients: ;
>
> with no Cc: line.
>
>
I went round and round with this a while back.

SA 3.25 has a problem with perl null vs 0 vs ''.

so a To header (or CC header) with no content looks like a missing to line.

but I don't see anything below in this rule that even looks for the CC
line, so you would need to create a meta rule (that doesn't work in
3.2.5) to check each.
rule #1 checks for the undiscloved recpits
rule #2 checks for CC (or blank cc, which sa 3.2.5 sees as the same)

best to block this in MTA, if you really just want to block it.

> Unfortunately, the rule that I have:
>
> header L_UNDISCLOSED To:raw =~ /undisclosed-recipients: ?;/
> describe L_UNDISCLOSED To: list is meaningless and no Cc:
> score L_UNDISCLOSED 10.0
>
>
>
> also seems to match when there's no "To:" line at all, only a "Cc:" line
> (which isn't what I want).
>
> Why is Spamassassin thinking that there's a header 'To:' line, and it
> says 'undisclosed recipients' when it doesn't exist?
>
> This is on Fedora Core 11, updated (so SA 3.2.5, Perl 5.10.0, and
> Sendmail 8.14.3)
>
> Thanks,
>
> -Philip
>
>
>
>

_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
_________________________________________________________________________

philipp_subx at redfish-solutions

Nov 23, 2009, 11:15 AM

Post #3 of 15 (1712 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

On 11/23/2009 12:10 PM, Michael Scheidell wrote:
> Philip Prindeville wrote:
>
>> Hi.
>>
>> I want to block all messages that I'm getting that have:
>>
>> To: undisclosed recipients: ;
>>
>> with no Cc: line.
>>
>>
>>
> I went round and round with this a while back.
>
> SA 3.25 has a problem with perl null vs 0 vs ''.
>
> so a To header (or CC header) with no content looks like a missing to line.
>
> but I don't see anything below in this rule that even looks for the CC
> line, so you would need to create a meta rule (that doesn't work in
> 3.2.5) to check each.
> rule #1 checks for the undiscloved recpits
> rule #2 checks for CC (or blank cc, which sa 3.2.5 sees as the same)
>
> best to block this in MTA, if you really just want to block it.
>

Well, I could use:

header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ?;/
header __L_UNDISCLOSED2 Cc !~ /^$/
meta L_UNDISCLOSED (__L_UNDISCLOSED1 && __L_UNDISCLOSED2)
describe L_UNDISCLOSED To: list is meaningless and no Cc:
score L_UNDISCLOSED 10.0

but as you say, if it can't tell the difference between "" and undef,
then that's an issue.

>> Unfortunately, the rule that I have:
>>
>> header L_UNDISCLOSED To:raw =~ /undisclosed-recipients: ?;/
>> describe L_UNDISCLOSED To: list is meaningless and no Cc:
>> score L_UNDISCLOSED 10.0
>>
>>
>>
>> also seems to match when there's no "To:" line at all, only a "Cc:" line
>> (which isn't what I want).
>>
>> Why is Spamassassin thinking that there's a header 'To:' line, and it
>> says 'undisclosed recipients' when it doesn't exist?
>>
>> This is on Fedora Core 11, updated (so SA 3.2.5, Perl 5.10.0, and
>> Sendmail 8.14.3)
>>
>> Thanks,
>>
>> -Philip
>>
>>
>>
>>
>>
>

list-subs at secnap

Nov 23, 2009, 11:18 AM

Post #4 of 15 (1710 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

Philip Prindeville wrote:
>
>
> but as you say, if it can't tell the difference between "" and undef,
> then that's an issue.
>
>
use header ALL to check for a \nCC
(which could be blank)

or just use your MTA to reject it at SMTPtime.

_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com
_________________________________________________________________________

philipp_subx at redfish-solutions

Nov 23, 2009, 11:37 AM

Post #5 of 15 (1720 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

On 11/23/2009 12:18 PM, Michael Scheidell wrote:
> Philip Prindeville wrote:
>
>>
>> but as you say, if it can't tell the difference between "" and undef,
>> then that's an issue.
>>
>>
>>
> use header ALL to check for a \nCC
> (which could be blank)
>
> or just use your MTA to reject it at SMTPtime.
>

BTW:

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5947

warns against using ALL.

Too bad there's no way to get the "raw" contents of the To: line
(comments included).

kremels at kreme

Nov 23, 2009, 4:11 PM

Post #6 of 15 (1717 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

On Nov 23, 2009, at 12:05, Philip Prindeville <philipp_subx [at] redfish-solutions
> wrote:

> I want to block all messages that I'm getting that have:
>
> To: undisclosed recipients: ;
>
> with no Cc: line.

What's Cc: have to do with it? undisclosed recipients is used for
Bcc: mail

I used it all the time. And you WILL 'block' legitimate mail.

me at junc

Nov 23, 2009, 4:25 PM

Post #7 of 15 (1708 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

On tir 24 nov 2009 01:11:38 CET, LuKreme wrote
> I used it all the time. And you WILL 'block' legitimate mail.

and thats always sender to decide its legitimate :)

i see a pattern there

--
xpoint

jhardin at impsec

Nov 23, 2009, 4:51 PM

Post #8 of 15 (1711 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

On Mon, 23 Nov 2009, LuKreme wrote:

> On Nov 23, 2009, at 12:05, Philip Prindeville
> <philipp_subx [at] redfish-solutions> wrote:
>
>> I want to block all messages that I'm getting that have:
>>
>> To: undisclosed recipients: ;
>
> undisclosed recipients is used for Bcc: mail
>
> I used it all the time. And you WILL 'block' legitimate mail.

Granted, but in metas such a test can be useful:

http://ruleqa.spamassassin.org/?rule=%2FTO_NO&srcpath=jhardin

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin [at] impsec FALaholic #11174 pgpk -a jhardin [at] impsec
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
You do not examine legislation in the light of the benefits it
will convey if properly administered, but in the light of the
wrongs it would do and the harms it would cause if improperly
administered. -- Lyndon B. Johnson
-----------------------------------------------------------------------
45 days since President Obama won the Nobel "Not George W. Bush" prize

philipp at redfish-solutions

Nov 23, 2009, 6:14 PM

Post #9 of 15 (1708 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

On 11/23/2009 05:11 PM, LuKreme wrote:
> On Nov 23, 2009, at 12:05, Philip Prindeville <philipp_subx [at] redfish-solutions
> > wrote:
>
>
>> I want to block all messages that I'm getting that have:
>>
>> To: undisclosed recipients: ;
>>
>> with no Cc: line.
>>
> What's Cc: have to do with it? undisclosed recipients is used for
> Bcc: mail
>
> I used it all the time. And you WILL 'block' legitimate mail.
>
>

For the mailboxes that this will be coming to, no one ever gets mail
with no recipient list.

We occasionally get mail from 'RT' (the bug tracker used by Openssl-dev
and others) that generates a Cc: with no To: line... but that's about
the extent of it.

philipp_subx at redfish-solutions

Nov 23, 2009, 6:15 PM

Post #10 of 15 (1699 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

philipp_subx at redfish-solutions

Nov 27, 2009, 2:04 PM

Post #11 of 15 (1604 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

John Hardin wrote:
> On Mon, 23 Nov 2009, LuKreme wrote:
>
>> On Nov 23, 2009, at 12:05, Philip Prindeville
>> <philipp_subx [at] redfish-solutions> wrote:
>>
>>> I want to block all messages that I'm getting that have:
>>>
>>> To: undisclosed recipients: ;
>>
>> undisclosed recipients is used for Bcc: mail
>>
>> I used it all the time. And you WILL 'block' legitimate mail.
>
> Granted, but in metas such a test can be useful:
>
> http://ruleqa.spamassassin.org/?rule=%2FTO_NO&srcpath=jhardin
>

Speaking of tests, I saved out some messages that should have matched my
rule but didn't into files, and ran them against spamassassin as:

spamassassin -D < /tmp/emails/XXX.eml

and I saw:

[28655] dbg: rules: ran header rule __L_UNDISCLOSED2 ======> got hit: "negative match"

for the ruleset:

header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/
header __L_UNDISCLOSED2 Cc =~ /^$/
meta L_UNDISCLOSED (__L_UNDISCLOSED1 && __L_UNDISCLOSED2)
describe L_UNDISCLOSED To: list is meaningless and no Cc:
score L_UNDISCLOSED 10.0

but didn't see __L_UNDISCLOSED1 match. Also, what does "negative match"
mean? That it didn't match?

Lots of other rules (like __L_UNDISCLOSED1) didn't match, but I didn't
see debug for those...

Just how do I go about figuring out what the "To:raw" value is (for
example)?

Thanks,

-Philip

jhardin at impsec

Nov 27, 2009, 3:43 PM

Post #12 of 15 (1596 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

On Fri, 27 Nov 2009, Philip A. Prindeville wrote:

> header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/
>
> Just how do I go about figuring out what the "To:raw" value is (for example)?

header __TO_RAW To:raw =~ /.+/

If you're analyzing something that may have multiple occurrences, you'll
need a tflags multiple:

body __ALL_BODY /.+/
tflags __ALL_BODY multiple

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin [at] impsec FALaholic #11174 pgpk -a jhardin [at] impsec
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
28 days until Christmas

philipp_subx at redfish-solutions

Nov 27, 2009, 11:33 PM

Post #13 of 15 (1578 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

John Hardin wrote:
> On Fri, 27 Nov 2009, Philip A. Prindeville wrote:
>
>> header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/
>>
>> Just how do I go about figuring out what the "To:raw" value is (for
>> example)?
>
> header __TO_RAW To:raw =~ /.+/
>
> If you're analyzing something that may have multiple occurrences,
> you'll need a tflags multiple:
>
> body __ALL_BODY /.+/
> tflags __ALL_BODY multiple
>

Interesting, thanks:

[31209] dbg: rules: ran header rule __TO_RAW ======> got hit: " undisclosed recipients: ;_"

wondering why it contains the leading space, and what the trailing
underscore is for...

On a side node, I never figured out why I see:

[31209] warn: plugin: failed to parse plugin (from @INC): syntax error at (eval 43) line 1, near "require Mail::SpamAssassin:"

This seems to be a known issue. What's the fix?

uhlar at fantomas

Nov 30, 2009, 3:15 AM

Post #14 of 15 (1497 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

On 27.11.09 14:04, Philip A. Prindeville wrote:
> for the ruleset:

> header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/

just FYI, sendmail can be configured to do different things when To: is
missing - there's sendmail option NoRecipientAction, configured by setting
confNO_RCPT_ACTION m4 directive. The default value is "none" but e.g. Debian
was setting it to "add-to-undisclosed" which causes MISSING_HEADERS not
hitting (only from milter, which appears to be called before the headers are
"fixed").

Maybe you should look at your MTA's configuratioon options if it doesn't
cause different rules hitting/not hitting, e.g. sendmail adds Date: and
Message-Id headers which cause MISSING_DATE and MISSING_MID. I was not able
to find how disable this behaviour in sendmail.

--
Matus UHLAR - fantomas, uhlar [at] fantomas ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
You have the right to remain silent. Anything you say will be misquoted,
then used against you.

philipp_subx at redfish-solutions

Dec 2, 2009, 9:23 AM

Post #15 of 15 (1418 views)
Permalink

Re: Undisclosed recipients :; -- again [In reply to]

On 11/30/2009 03:15 AM, Matus UHLAR - fantomas wrote:
> On 27.11.09 14:04, Philip A. Prindeville wrote:
>
>> for the ruleset:
>>
>
>> header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/
>>
> just FYI, sendmail can be configured to do different things when To: is
> missing - there's sendmail option NoRecipientAction, configured by setting
> confNO_RCPT_ACTION m4 directive. The default value is "none" but e.g. Debian
> was setting it to "add-to-undisclosed" which causes MISSING_HEADERS not
> hitting (only from milter, which appears to be called before the headers are
> "fixed").
>
> Maybe you should look at your MTA's configuratioon options if it doesn't
> cause different rules hitting/not hitting, e.g. sendmail adds Date: and
> Message-Id headers which cause MISSING_DATE and MISSING_MID. I was not able
> to find how disable this behaviour in sendmail.
>
>

Odd. This is on FC11:

[root [at] mai mail]# grep confNO_RCPT_ACTION /usr/share/sendmail-cf/*/*
/usr/share/sendmail-cf/m4/proto.m4:_OPTION(NoRecipientAction, `confNO_RCPT_ACTION', `none')
[root [at] mai mail]# grep NoRecipientAction *.cf
sendmail.cf:#O NoRecipientAction=none
submit.cf:#O NoRecipientAction=none
[root [at] mai mail]#

Added:

define(`confNO_RCPT_ACTION', `none')dnl

to the sendmail.mc, made sendmail.cf, did a service restart... will see what happens.

I can't remember: if an option is commented, is that showing us the default value typically?

-Philip

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads