On 1/18/2023 10:02 AM, bugzilla-dae...@spamassassin.apache.org wrote:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7910
Bill Cole<billc...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
CC| |billc...@apache.org
--- Comment #2 from Bill Cole<billc...@apache.org> ---
PDS_BAD_THREAD_QP_64 is not in the current SpamAssassin ruleset.
mail-tester.com is not part of the ASF SpamAssassin project and they are known
to be using an obsolete version with rules and scores that do not match the
current SA default ruleset.
Take any problems they claim to exist in your mail to them. We cannot answer
for their failure to provide accurate results.
1) Correct. From the Zimbra Config Guide:
1160 zimbraMailThreadingAlgorithm enum 8.0.0 The algorithm
to use when aggregating new messages into conversations. Possible values
are: - "none": no conversation threading is performed. - "subject": the
message will be threaded based solely on its normalized subject. -
"strict": only the threading message headers (References, In-Reply-To,
Message-ID, and Resent-Message-ID) are used to correlate messages. No
checking of normalized subjects is performed. - "references": the same
logic as "strict" with the constraints slightly altered so that the
non-standard Thread-Index header is considered when threading messages
and that a reply message lacking References and In-Reply-To headers will
fall back to using subject-based threading. - "subjrefs": the same logic
as "references" with the further caveat that changes in the normalized
subject will break a thread in two.
I believe the main RFC that deals with Message Threading correlates to
Zimbra's "strict" mode, particularly the In-Reply-To and References
headers. Where Zimbra overstepped is that while there is no RFC
describing Thread-Index, there IS a standard. Microsoft first started
using this back in 2000, and documented it within MSDN in 2003. Zimbra
simply chose to do their own thing (whatever that may be).
2) Don't want to be a party-pooper, but the veracity of the underlying
regex (__THREAD_INDEX_GOOD) is suspect. I found several hundred
Thread-Index headers and found many that fail with standard, non-spam,
Outlook messages. Here are a couple (Outlook 2007 and Outlook 2013):
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLYgMQp8BCX9nSr6CIOlZIDeiK7/KkngMmA
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH+vjdk9tD1ot0pJqzGHeFq00ZfdgFRP4zA
Notice the UPPERCASE second character. I've also found a lot of hosted
Exchange and Exchange Online headers that don't match this regex. Those
are much longer strings.
3) You *might* want to use something like this for __THREAD_INDEX_GOOD:
header __THREAD_INDEX_GOOD Thread-Index =~
m,^(A[A-z0-9][A-z0-9+\/]{27}(?:[A-z0-9+\/]{20})?(?:[AQgw]==|[A-z0-9+\/]{7}|[A-z0-9+\/]{13}[AEIMQUYcgkosw048]=)|[A-z0-9\/+]{30}==)$,
This addresses the Outlook headers as indicated above. It also provides
support for Zimbra headers (last [A-z0-9\/+]{30}== grouping).
4) While it is good that PDS_BAD_THREAD_QP_64 is dead, if
__THREAD_INDEX_GOOD is loose, then so are its dependencies:
__ADVANCE_FEE_5_NEW, __ADVANCE_FEE_4_NEW, __ADVANCE_FEE_3_NEW,
__ADVANCE_FEE_2_NEW, TO_NO_BRKTS_PCNT, TO_NO_BRKTS_MSFT, TO_IN_SUBJ,
TO_EQ_FM_DIRECT_MX, MONEY_FORM_SHORT, HAS_X_OUTGOING_SPAM_STAT (as
observed in SA v3.4.6).
Or....kill off __THREAD_INDEX_GOOD entirely. It has to be hard to
maintain header support like that.
$0.02,
-- Jared Hall
