Is it possible to give "undisclosed-recipients" a positive spam score?

[thunder04]

I did a search for "undisclosed-recipients" and didn't find anything related to my question/problem, so here it goes!

We've been receiving an exponential amount of spam lately, and more of it than I like is not being given a high enough spam score to be automatically thrown into spam.

These messages have differed greatly, but the one common thing I noticed is that, in the headers, they're addressed to undisclosed-recipients as shown below:

To: undisclosed-recipients:;

Is it possible to configure spamassassin to give messages that are addressed in a manner like above a positive weight? If so, how would I go about doing this?

Thanks!!

[Jbrabander]

But wouldn't legitimate messages sent only to BCC people say that as well?

[thunder04]

Originally Posted by Jbrabander

But wouldn't legitimate messages sent only to BCC people say that as well?

Possibly, but at this point I'm not concerned about it. People are very on top of when messages are sorted improperly, so if it causes a problem I'll be notified.

[mmorse]

2 methods:

The first involves combining spamassassin local.cf rules for valid-looking & probably faked/non RFC 'undisclosed recipients' with low score values since no To is allowed afterall, then assign another higher score if not they don't appear to be internal users:

header UNDISC_RECIPS    To =~ /^undisclosed-recipients?:\s*;$/
score UNDISC_RECIPS 0.00019 0.00018 0.00017 0.00016
describe UNDISC_RECIPS    Valid-looking "undisclosed-recipients:;"
header FAKED_UNDISC_RECIPS    To =~ /undisclosed[_ ]*recipient(?:s[^:]|[^s])/i
score FAKED_UNDISC_RECIPS 0.0029 0.0028 0.0027 0.0026
describe FAKED_UNDISC_RECIPS    Probably faked or non RFC "Undisclosed Recipients"
header __MY_DOMAIN    From =~ /\@yourdomain\.com/i
meta LIKELY_EXTERNAL_UNDISC    (UNDISC_RECIPS || FAKED_UNDISC_RECIPS && !__MY_DOMAIN)
score LIKELY_EXTERNAL_UNDISC 0.039 0.038 0.037 0.036
describe LIKELY_EXTERNAL_UNDISC More points if not From @yourdomain user.

-Append __ to UNDISC_RECIPS / FAKED_UNDISC_RECIPS and remove the extra score x.x lines if you don't want them to have an effect on their own.
-Should probably find a better __MY_DOMAIN check that looks at trusted paths, since they could obviously fake the From field; but we won't extrapolate here, you have tons of other checks.
-I didn't test the above with spamassasin --lint so careful before taking that rule live in /opt/zimbra/conf/spamassassin 20_head_test.cf or local.cf
-There's && and, || or, ! nor as well as xor, xnor values as well.

x.x rundown:
If there is only one score parameter then that value is used all the time.
1st score applies when the Bayesian classifier and network tests are not in use.
2nd score applies when the Bayesian classifier is not in use, but the network tests are.
3rd score applies when the Bayesian classifier is in use, but network tests are not.
4th score applies when the Bayesian classifier and network tests are both in use.

As Jbrabander said, it's allowed per RFC to not have a To and only Bcc. But it is funny how spammers tend to use undisclosed more, and legitimate people at least To/CC themselves; if said spammers are smart they could just specify a bogus external To/CC value...

So if you still really want to halt it altogether, a postfix header_check would do the trick:

/^To: .*undisclosed*recipients*/ REJECT Please specify who your sending to.

(Or just *recipients* if they're using another word for undisclosed like unlisted.)

header_checks = pcre:/opt/zimbra/conf/postfix_header_checks

Possibly use [Kyle Dent] - Turning Off Body and Header Checks for Internal Users but I think their's simpler methods using if statements that wouldn't halt all checks.

[thunder04]

I know it's not the "best" method, but as long as it'll return an error message, I think I'm going to try...

/^To: .*recipients*/ REJECT Please specify at least one address you are sending to.

That'll basically reject a message that's sent 'To' anything with recipients in the name, right? Just want to make sure! I'm not too familiar with Postfix header check syntax.

[mmorse]

To ignore that restriction if internal you'd use an if statement with a not argument (exclamation point):

if 
!/^From:.*@yourdomain.com/ 
/^To:.*recipients*/ REJECT Please specify at least one address you are sending to.
endif

Also you can use WARN instead of REJECT if you ever want to test a rule, then check your logs for the error.

[thunder04]

Hmm. When I add the check to /opt/zimbra/conf/postfix_header_checks and then reload postfix, my changes are removed.

I know I'm doing something wrong. How do I properly add the header check?

[mmorse]

postfix_header_checks.in

[thunder04]

Hmm.

I added the line

/^To: .*recipients*/ REJECT Please disclose at least one recipient

to postfix_header_checks.in. When I issue a "postfix reload" as the zimbra user, I get...

postmap: warning: /opt/zimbra/conf/postfix_header_checks.ZkH361, line 5: record is in "key: value" format; is this an alias file?

and the header check doesn't work. What else can I be doing wrong? lol

EDIT: When removing my modification from the postfix_header_checks.in file, the postmap warning does not appear when doing a "postfix reload".