https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7411
Bill Cole <billc...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |billc...@apache.org
--- Comment #3 from Bill Cole <billc...@apache.org> ---
(In reply to Jeremy Andrews from comment #2)
> Umm... so yeah, as a result of this change, my e-mail client is marked as
> using a forged Mozilla header. I develop an e-mail client called Epyrus,
> which is a fork of Mozilla Thunderbird.
>
> The UA that's being sent is:
>
> Mozilla/5.0 (Windows NT 10.0; WOW64; rv:6.3) Goanna/20230916 Epyrus/2.1.0
>
> Essentially, the engine it uses is a fork of Gecko, and the application is a
> fork of Thunderbird. The reason I am getting targeted by this rule is
> because I am not presenting my application as being Thunderbird. If I were
> to impersonate Thunderbird more accurately, I would actually be able to get
> past this check.
>
> The Mozilla/5.0 thing is a compatibility string, essentially.
Which is entirely useless in an email header and particularly in a header which
has no standard meaning in email and only TBird-based MUAs generate.
> It lets
> everyone know the user agent that sent the e-mail is compatible with
> Mozilla, it's not actually saying that the e-mail is from Mozilla, or even
> from a Mozilla-produced client.
Please do not take this personally: NO ONE CARES.
A MUA is not a web browser. The only purpose of identifying a MUA in any header
is to *specifically* identify the precise MUA used to compose the message for
problem analysis. There is no mechanism that uses any sort of 'compatibility
string' in email. The fact that Mozilla made this mistake in TBird is no reason
for you to perpetuate it.
> If it's necessary, I can look into how to remove it, but it is going to
> cause compatibility issues because things that check useragents will have no
> idea how to process an e-mail from "Epyrus" without the Mozilla string to
> indicate what it's compatible with.
THERE ARE NO SUCH "THINGS."
Web browsers send User-Agent headers with carefully constructed cargo-cult
strings because HTTP was specified to allow for servers to send different data
to different agents based on those strings. That behavioral model does not
exist in email. Even with HTML content in email, no common MUAs try to use
Mailer, X-Mailer, or User-Agent headers in any way.
> Also, apologies if I was supposed to create a new bug,
I'm closing this one. The real problem it was opened to address was addressed
>6 years ago. Your problem is unrelated to THIS bug. You'd know that if you
read the bug before tacking your complaint onto it.
> but the thing I
> wanted to highlight was that this change was a regression from my
> perspective because it makes forking Thunderbird without getting flagged as
> impersonating Mozilla a lot harder.
Maybe you could stop perpetuating Mozilla's stupid MUA mistakes?
I don't think it is wise for SA to accommodate one MUA vendor choosing to do
something *which serves no functional purpose* that happens to entangle an
existing well-performing rule.
--
You are receiving this mail because:
You are the assignee for the bug.
