Re: Undisclosed recipients :; -- again
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: [r...@mail mail]# grep confNO_RCPT_ACTION /usr/share/sendmail-cf/*/* /usr/share/sendmail-cf/m4/proto.m4:_OPTION(NoRecipientAction, `confNO_RCPT_ACTION', `none') [r...@mail mail]# grep NoRecipientAction *.cf sendmail.cf:#O NoRecipientAction=none submit.cf:#O NoRecipientAction=none [r...@mail 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
Re: Undisclosed recipients :; -- again
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, uh...@fantomas.sk ; 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.
Re: Undisclosed recipients :; -- again
John Hardin wrote: On Mon, 23 Nov 2009, LuKreme wrote: On Nov 23, 2009, at 12:05, Philip Prindeville philipp_s...@redfish-solutions.com 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_NOsrcpath=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
Re: Undisclosed recipients :; -- again
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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org 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
Re: Undisclosed recipients :; -- again
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?
Re: [sa] Re: Undisclosed recipients :; -- again
On Mon, 23 Nov 2009, John Hardin wrote: Granted, but in metas such a test can be useful: http://ruleqa.spamassassin.org/?rule=%2FTO_NOsrcpath=jhardin Every now and then, someone posts a link like this one, and I find myself looking at a kind of 'index' page that frankly doesn't mean a thing to me. Rather than being a direct link to an actual rule or meta, I have to *guess* which link/section to click on to find what you intended to have us see as an example? I see statistics about a rule named TO_NO_BRKTS_DYNIP but no indication of what those rules ARE. Am I missing something here? - Charles
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_UNDISCLOSEDTo: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
Re: Undisclosed recipients :; -- again
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_UNDISCLOSEDTo: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/ _
Re: Undisclosed recipients :; -- again
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_UNDISCLOSEDTo: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
Re: Undisclosed recipients :; -- again
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 _
Re: Undisclosed recipients :; -- again
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).
Re: Undisclosed recipients :; -- again
On Nov 23, 2009, at 12:05, Philip Prindeville philipp_s...@redfish-solutions.com 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.
Re: Undisclosed recipients :; -- again
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
Re: Undisclosed recipients :; -- again
On Mon, 23 Nov 2009, LuKreme wrote: On Nov 23, 2009, at 12:05, Philip Prindeville philipp_s...@redfish-solutions.com 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_NOsrcpath=jhardin -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org 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
Re: Undisclosed recipients :; -- again
On 11/23/2009 05:11 PM, LuKreme wrote: On Nov 23, 2009, at 12:05, Philip Prindeville philipp_s...@redfish-solutions.com 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.
Re: Undisclosed recipients :; -- again
On 11/23/2009 05:11 PM, LuKreme wrote: On Nov 23, 2009, at 12:05, Philip Prindeville philipp_s...@redfish-solutions.com 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.
