Milan Crha wrote:
> I accidentally noticed that the compose reports sometimes contain odd
> charset information, namely `unknown-8bit`, which is not great. It does
> not do that always, like I have:
> 
> `Fedora 43 compose report: 20251014.n.0 changes` , which is:
> 
>     Content-Type: text/plain; charset="utf-8"
>     Content-Transfer-Encoding: base64

That email contains only ASCII characters. It could have used
"charset=US-ASCII" and "Content-Transfer-Encoding: 7bit". But that's
not always the case.

> and then another:
> 
> `Fedora rawhide compose report: 20251014.n.0 changes` , which is:
> 
>     Content-Type: multipart/mixed; boundary="....."
> 
>         Content-Type: text/plain; charset=unknown-8bit
>         Content-Transfer-Encoding: quoted-printable
> 
>             ....
> 
>         Content-Type: text/plain; charset="utf-8"
>         Content-Transfer-Encoding: base64

That one contains packagers' names with non-English letters, so it
needs character encoding metadata.

My guess is that the report generator is unaware that anything but
ASCII exists, and sends MIME-less emails. Thus its emails become
invalid when non-English letters appear. I further guess that either
Mailman or Postfix notices the presence of bytes greater than 127 and
tries to correct the invalid email, but it doesn't know what the
character encoding is so "unknown-8bit" is the best it can do.

In June I was booted off the epel-devel list by invalid updates-testing
reports sent through the list. Mailman is quick to punish subscribers
who bounce even a small fraction of emails. These compose reports are
at least valid MIME mails when they arrive to me, so they don't bounce.
It seems that either there's some difference between compose reports and
updates-testing reports, or the devel list handles them somewhat better
than the epel-devel list did. The problem is still not reported to the
sender, though. Problems don't get fixed when the one who is hurt by
the problem isn't the one who can fix it.

Fedora spec files are encoded in UTF-8 by policy, so the report
generator should assume that text it extracts from packages is UTF-8.
Probably all it needs to do is to add "Content-Type: text/plain;
charset=UTF-8" and "Content-Transfer-Encoding: 8bit" to every email it
sends.

> They both had been received through the mailing list, they both contain
> the list signature/footer, only the rawhide report has it as the second
> part.

It probably becomes a separate MIME part because there's no way to
reconcile "unknown-8bit" and UTF-8 into a common character encoding.

Björn Persson

Attachment: pgpc6cVII2LPt.pgp
Description: OpenPGP digital signatur

-- 
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to