https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8337
--- Comment #4 from Bill Cole <billc...@apache.org> --- (In reply to lurkertech from comment #3) > Really? Yes, really. As you may reasonably guess, the general issue has been raised a few times before. SpamAssassin itself has never generated a "X-Ham-Report" header. Any errors in such a header are not due to SpamAssassin. > Isn't the message right here in rules/10_default_prefs.cf ? cPanel has every right to copy our message for the one they apply in their non-standard header. SpamAssassin is open source with a very permissive license. > https://github.com/apache/spamassassin/blob/trunk/rules/10_default_prefs.cf > > Even though it doesn't say the X-Ham-Report header name explicitly, I don't understand how you can think SA is responsible for a header that it CANNOT generate. >isn't > the implementation of _PREVIEW_ (without escaping) the source of the > problem? Not in the actual SpamAssassin code. If you had found this is a X-Spam-Report header on a non-cPanel installation using one of the open source glue layers between the MTA and SA, we could at least investigate. We do not have access to whatever cPanel has done to SA inn their installations. > And at what level is _PREVIEW_ expanded? In the case of constructing a X-Ham-Report header, it is obviously being expanded in something written by and proprietary to cPanel. We cannot help you with that. We cannot debug code we don't have. The problem is in how cPanel is re-using our prefacing message and code. Only cPanel can explain or fix whatever it is doing in the cPanel context. -- You are receiving this mail because: You are the assignee for the bug.
