base-64 ignored

[Ingo Klöcker]

On Freitag, 27. Mai 2022 12:34:57 CEST gene heskett wrote:
> My point Ingo, is that kmail makes no attempt to decode the base64 in at
> least 80% of the incoming mail. Methinks there is a broken mimetype
> somewhere.

And I think it's invalid base64.

> In one of my first posts in this thread, there was extra data
> on the end of the Boundary statement, but no one commented on that, which
> seems odd?

Well, I guess nobody noticed. Or they noticed and thought, "Yeah, that looks 
perfectly alright." I for one only looked at the base64 data.

> The opening statement:
> ------=_Part_29546_1281477845.1653517724260
> The closing statement:
> ------=_Part_29546_1281477845.1653517724260--
> The question becomes: Where did the extra "--" come from?
> 
> As IUI, those statements must match in order to trigger a new evaluation
> of a mimetype. They do not match.

They do match. Except for the suffix "--" that indicates the end of the last 
body part. In fact, the standard even says
"NOTE TO IMPLEMENTORS:  Boundary string comparisons must compare the
boundary value with the beginning of each candidate line.  An exact
match of the entire candidate line is not required; it is sufficient
that the boundary appear in its entirety following the CRLF."

https://datatracker.ietf.org/doc/html/rfc2046#section-5.1.1

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20220527/fa4df502/attachment.sig>