[Bug 7908] Domain PRO is treated as spam
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7908 Kevin A. McGrail changed: What|Removed |Added Resolution|--- |INVALID CC||kmcgr...@apache.org Status|NEW |RESOLVED --- Comment #1 from Kevin A. McGrail --- Those rules are promoted based on evidence in corpora. Additionally, many of the newer TLDs do not have appropriate fraud protection. If you have a FP with the domain, add a sample to pastebin for consideration. The hits you are listing below show a system not running sa-update for rule updates. Additionally, the rules you are listing are not up to date PDS_PRO_TLD was created specifically to check the S/O of the rule independently of other domains. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7905] Meta tests that use networking should not be ignored in maybe_header_only and maybe_body_only
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7905 --- Comment #3 from Bert Van de Poel --- I'm not sure I completely follow, RW. Could you perhaps give an example to explain? That way it may be easier for me to understand. Thank you in advance! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7905] Meta tests that use networking should not be ignored in maybe_header_only and maybe_body_only
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7905 RW changed: What|Removed |Added CC||rwmailli...@googlemail.com --- Comment #2 from RW --- The network metarules are presumably ignored because there is usually a corresponding network eval rule with type header or body. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7908] New: Domain PRO is treated as spam
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7908 Bug ID: 7908 Summary: Domain PRO is treated as spam Product: Spamassassin Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P2 Component: Rules Assignee: dev@spamassassin.apache.org Reporter: i...@webstars.pro Target Milestone: Undefined I'm using one of the most SPAM-CLEAR domain .PRO. I don't send any spam but all the time my doesn't reach receipients. Because they are classifies as spam. It doesn't matter what I sent. Always it is a spam. I noticed that this is problem when recipient's server using Spam Assassin and classify my e-mail: 2.0 PDS_OTHER_BAD_TLD 1.8 FROM_SUSPICIOUS_NTLD_FP 0.5 FROM_SUSPICIOUS_NTLD Domain PRO is treated as a source of spam, but this is absolutely untruth. https://www.scoutdns.com/most-abused-top-level-domains-list-october-scoutdns/ Domain PRO is responsible for 0,1% of world's spam but domain COM for 65% of spam. Domain COM should be completely blocked for ever but PRO is the most trusted and should be unlocked on all SpamAssassin servers. What can you do with that? How can you help? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7907] Meta tests should be devolved to determine whether they apply to the header, body or both
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7907 Bert Van de Poel changed: What|Removed |Added CC||b...@bhack.net -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7831] DKIM_VALID_AU does not get set properly when mailing from a subdomain
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7831 Benny Pedersen changed: What|Removed |Added CC||m...@junc.eu --- Comment #14 from Benny Pedersen --- https://bugs.gentoo.org/758935 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7735] Meta rules need to handle missing/unrun dependencies
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735 Henrik Krohns changed: What|Removed |Added Attachment #5742|0 |1 is obsolete|| --- Comment #13 from Henrik Krohns --- Created attachment 5743 --> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5743=edit Meta patch for r1889731 v2 Updated patch for current trunk. - do_meta_tests() updated a bit, now also uses get_pending_lookups (renamed from has_pending_lookups) to check if rule is pending, this should fix most 3rd party async plugins (like my iXhash2) Currently both of these are considered ready/done rules evaluating to 0: - non-existing rules - disabled rules (score 0) Still considering if it's manageable to do the proposed "evaluate un-run as both true and false". -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7907] New: Meta tests should be devolved to determine whether they apply to the header, body or both
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7907 Bug ID: 7907 Summary: Meta tests should be devolved to determine whether they apply to the header, body or both Product: Spamassassin Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Learner Assignee: dev@spamassassin.apache.org Reporter: b...@bhack.net Target Milestone: Undefined As outlined within bugs 7905 and 7906, meta tests are maltreated within the __get_autolearn_points, maybe_header_only and maybe_body_only functions. I suggest meta tests should be parsed further to determine whether they constitute a combination of only header tags, only body tags or a mix. If it is a mix, I would suggest a ratio is returned so the score can be partially attributed to header and partially to body. However, I can think of certain meta rules I've written of a similar form to "if more than 3 of the following 10 tests succeed, then attribute this score", it may sometimes prove difficult to clearly indicate whether a test is actually header, body or a specific ratio of both. Therefore it's maybe worth considering having meta rules report their own categorization, for example with tflags like autolearn_header autolearn_body autolearn_both and the existing noautolearn for those to difficult to categorise. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7906] Meta tests that do not use networking should not be automatically considered as a header test in _get_autolearn_points
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7906 Bert Van de Poel changed: What|Removed |Added CC||b...@bhack.net --- Comment #1 from Bert Van de Poel --- Bug 7905 is related to this https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7905 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7905] Meta tests that use networking should not be ignored in maybe_header_only and maybe_body_only
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7905 Bert Van de Poel changed: What|Removed |Added CC||b...@bhack.net --- Comment #1 from Bert Van de Poel --- Bug 7906 is related to this https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7906 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7906] New: Meta tests that do not use networking should not be automatically considered as a header test in _get_autolearn_points
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7906 Bug ID: 7906 Summary: Meta tests that do not use networking should not be automatically considered as a header test in _get_autolearn_points Product: Spamassassin Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Learner Assignee: dev@spamassassin.apache.org Reporter: b...@bhack.net Target Milestone: Undefined Currently when tests are evaluated for the header and body scores for Bayes autolearning, meta tests that define that they are not network tests (no tflags = net) are considered both body and header tests. Of course this is obviously not always the case in practice, since a meta test could combine only header tests, only body tests, or a combination of both. Beyond that clearly incorrect presumption, the code in PerMsgStatus.pm's _get_autolearn_points only considers the maybe_body_only function if the maybe_header_only function has failed. This means that any meta rule that does not have tflags including net, is always considered a header test. This is absolutely false, as other code says it's both, and all things considered it should actually depend on the rules the meta test consists of. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7905] New: Meta tests that use networking should not be ignored in maybe_header_only and maybe_body_only
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7905 Bug ID: 7905 Summary: Meta tests that use networking should not be ignored in maybe_header_only and maybe_body_only Product: Spamassassin Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Learner Assignee: dev@spamassassin.apache.org Reporter: b...@bhack.net Target Milestone: Undefined Currently when tests are evaluated for the header and body scores for Bayes autolearning, meta tests that define that they are network tests (tflags = net) are fully ignored. I would argue that this should not be the case. Specifically, the code within Conf.pm for maybe_header_only and maybe_body_only both contain code that when meta tests are passed to it, they are either not considered when the network tflag is set (which this bug is about) or always scored (which has other problems I will file another bug about). I don't understand why requiring network functionality automatically disqualifies a meta test, but then does not disqualify a non-meta test. Considering that a meta test combines for example two URI tests that use external databases available through some sort of DNS or HTTP API, then both tests should set the network flag, as well as the meta test that derives from it (if I understand things correctly). I don't see why that inherently makes that test more or less relevant for defining whether or not it's relevant for autolearning. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7735] Meta rules need to handle missing/unrun dependencies
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735 --- Comment #12 from Henrik Krohns --- (In reply to Henrik Krohns from comment #11) > - Duplicate rule merging code has been removed, since it would require new > bloaty extra logic to work with all the above. It saved very little > resources anyway, makes no difference. PS. While doing some tests I found a bug in merging too.. if you have duplicate rules but set some score to 0, it will disable the other rule too. Hit my head for 15 minutes until I realized why my test was acting strange. *groan* body FOO1 /./ body FOO2 /./ score FOO1 0 # FOO2 will never hit Farewell kludgy merging code, won't be missing you. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7904] Missing types in maybe_body_only()
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7904 Bert Van de Poel changed: What|Removed |Added CC||b...@bhack.net -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7904] New: Missing types in maybe_body_only()
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7904 Bug ID: 7904 Summary: Missing types in maybe_body_only() Product: Spamassassin Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Learner Assignee: dev@spamassassin.apache.org Reporter: b...@bhack.net Target Milestone: Undefined I recently noticed some problems with Spamassassin not autolearning spam that was not overly similar to previous messages and had enough scores. From debug logs, I figured out the messages weren't hitting the minimum requirement of 3 or more spam score based on the body. Bizarrely enough, when I went through the list of tests, I did find enough examples of body tests in some cases. After reaching out to the mailing list about this, wondering whether this was perhaps a bug, I received confirmation from RW that some important parts were missing in the maybe_body_only() function which causes it not to consider very relevant body tests such as DCC, Razor and Pyzor (which give huge scores and we consider as very relevant). See the quote from https://www.mail-archive.com/users@spamassassin.apache.org/msg108260.html below: "One thing that does look wrong is that maybe_body_only() looks for: (($type == $TYPE_BODY_TESTS) || ($type == $TYPE_BODY_EVALS) || ($type == $TYPE_URI_TESTS) || ($type == $TYPE_URI_EVALS)) so it's missing any rawbody and full rules. Specifically Pyzor, Razor2 and DCC are full eval rules." I would therefore consider this a bug that should be fixed and perhaps even considered by distros for backporting into existing long term releases (such as the Ubuntu LTS and RHEL). -- You are receiving this mail because: You are the assignee for the bug.
