Results 1 to 9 of 9

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

  1. #1
    Join Date
    Dec 2007
    Location
    Stockton, CA
    Posts
    164
    Rep Power
    7

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

    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:

    Code:
    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!!

  2. #2
    Join Date
    May 2008
    Location
    Park City, KS
    Posts
    342
    Rep Power
    7

    Default

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

  3. #3
    Join Date
    Dec 2007
    Location
    Stockton, CA
    Posts
    164
    Rep Power
    7

    Default

    Quote Originally Posted by Jbrabander View Post
    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.

  4. #4
    Join Date
    May 2006
    Location
    USA
    Posts
    6,242
    Rep Power
    21

    Default

    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:

    Code:
    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:
    Code:
    /^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.
    Last edited by mmorse; 08-15-2009 at 07:44 AM.

  5. #5
    Join Date
    Dec 2007
    Location
    Stockton, CA
    Posts
    164
    Rep Power
    7

    Default

    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...

    Code:
    /^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.

  6. #6
    Join Date
    May 2006
    Location
    USA
    Posts
    6,242
    Rep Power
    21

    Default

    To ignore that restriction if internal you'd use an if statement with a not argument (exclamation point):
    Code:
    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.

  7. #7
    Join Date
    Dec 2007
    Location
    Stockton, CA
    Posts
    164
    Rep Power
    7

    Default

    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?

  8. #8
    Join Date
    May 2006
    Location
    USA
    Posts
    6,242
    Rep Power
    21

  9. #9
    Join Date
    Dec 2007
    Location
    Stockton, CA
    Posts
    164
    Rep Power
    7

    Default

    Hmm.

    I added the line

    Code:
    /^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...

    Code:
    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".
    Last edited by thunder04; 03-30-2009 at 10:38 AM.

Similar Threads

  1. Weird behaviors and LOTS of spam.
    By zwvpadmin in forum Administrators
    Replies: 7
    Last Post: 01-02-2009, 09:26 AM
  2. False Positive Spam debugging
    By gfreemankc in forum Administrators
    Replies: 0
    Last Post: 07-24-2008, 08:43 AM
  3. Spam handling with RBL's
    By Priyantha Bleeker in forum Administrators
    Replies: 2
    Last Post: 04-18-2008, 09:52 AM
  4. Spam weirdness
    By dwmtractor in forum Administrators
    Replies: 7
    Last Post: 01-29-2008, 11:55 AM
  5. Some more simple tips for cutting spam. . .
    By dwmtractor in forum Administrators
    Replies: 14
    Last Post: 11-21-2007, 05:03 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •