Base64 encoded lines are too long, trigger SpamAssassin BASE64_LENGTH_78_79 and BASE64_LENGTH_79_INF rules

[jocutajar]

Hi team,

A friend complains my messages end up in spam a lot. The avatar picture attachment is sent by delta.chat with 78 base64 characters per line. The standard is 76 at most. The auto-crypt header may be even worse with the indentation padding. Not sure. A smart SMTP server could fix this I suppose in transit. I'm using postfix and it doesn't.

• Expected behavior: base64 lines break after 76 characters.
• Actual behavior: base64 lines contain 78 characters (attachments) + padding in case of auto-crypt header.
• Why is it a problem: this triggers anti-spam rules with the outcome of marking sent messages as spam on the receiver end so my messages are effectively not delivered.

See RFC 2045, tl;dr: https://en.wikipedia.org/wiki/Base64#Variants_summary_table

[link2xt]

Duplicate issue #2700 reported here: https://nitter.net/Alex_Helali/status/1440060286086443013

[link2xt]

I have made a fix for base64-encoded part: #4745 No questions here, RFC 2045 is clear about 76-character limit, even though I don't know about the rationale for it. The rationale of "quantum of encoding" being 24 bits and therefore the limit being 19 by 4 = 76 does not make much sense for wrapping, but whatever makes SpamAssassin happy.

For Autocrypt header I did no changes yet, it is another part of the code: https://github.com/deltachat/deltachat-core-rust/blob/c41687586caa45086648a84a0a0b279b79efb3d9/src/aheader.rs#L75C3-L75C3 RFC 2045 reference does not apply here. If no spam filter complains, I would rather leave the code as is, see no reason for 76 character limit there.

[link2xt]

I also have no idea what triggers BASE64_LENGTH_79_INF.

Going to close the issue after #4745 is merged. If there is an example of an email triggering any SpamAssassin rules after that, please provide an example of .eml and maybe open a new issue for this.