Jonathan Joseph Chiarella

Seconding the thanks to Alexander Leidinger (@aleidinger). Because MP3 will remain for a long time as the lowest common denominator for devices and very cheap on hardware, I am glad to see the open-source LAME be tops all around. CBR is still big for seeking accuracy and for streaming. I had not commented here, but I successfully ABX-ed and heard the difference for the q4 bug in even CBR 320 kbps (44.1 kHz) files done on top of a file that already had the distortion bug from a previous encoding....

If I understand what I'm reading about Pretty Easy Privacy from their proposed drafts, it seems incompatible with autocrypt. The methods of key transfer are different (metadata for autocrypt, mime attachment for PEP). Additionally, header protection seems fundamentally flawed. PEP only protects the "Subject: " header and only if it is encrypted. On the other hand, autocrypt/memory hole protects the "Subject: " and the "To: " and the "From: " fields. Autocrypt/memory hole protects these fields as...

The "bad" part is autogenerating keys. New users who have Thunderbird on a PC and a laptop will end up creating separate keys on each and may not be aware they have a different key on each device if the keys are both identified as "kelly@g.com."

Thank you for your reply and pointing me to that PEP is following RFC 3156. I kept coming across examples of encrypted messages of PEP 1 and decrypted messages showing nested structure of PEP 2 and was operating on guesswork. I'm fairly sure the Autocrypt people took over Memory Hole, right? The incoproration of it or protected headers is on the horizon. I can understand PEP doing basic defaults for all and whatnot. I may not like some of the choices, but as can be seen with WireGuard simplicity...

I don't want to disparage the work gone into Enigmail supporting both, which is a good decision. I am just baffled as to why PEP should even exist at this point and I disagree strongly with defaulting to PEP. Having support for PEP reading, like supporting reading DSA1024 mail even though DSA1024 keys are discouraged, is great, of course.

If I understand what I'm reading about Pretty Easy Privacy from their proposed drafts, it seems incompatible with autocrypt. The methods of key transfer are different (metadata for autocrypt, mime attachment for PEP). Additionally, header protection seems fundamentally flawed. PEP only protects the "Subject: " header and only if it is encrypted. On the other hand, autocrypt/memory hole protects the "Subject: " and the "To: " and the "From: " fields. Autocrypt/memory hole protects these fields as...

Wow.... Maybe PGP/MIME is just never going to work in certain contexts. If mailman is removing MIME layers and contents, it or any other service could strip out signatures, section breaks or attachments. PGP/Inline ideally has format=flowed off (as well as line wrap disabled), because even the Enigmail and PGP clean up of > and trailing whitespace isn't fool-proof. which is good because mail programs sometimes mess up contents. However, I did notice that very long lines (~1000+) get turned to Base64,...

Actually, I just thought of a solution. Why not rewrite the Subject Title entirely in Unicode? Make the whole thing =?UTF-8?B?........?= or =?UTF-8?Q?........?= and use Base64 or Quoted-Printable always. (Right now, the subject line is 7-bit ASCII, if a non-ASCII character is included, it is Quoted Printable or Base64, but using these seems to cause no issues. I tried writing a Subject line manually this way on a normal e-mail and everyone plays nicely with it, even webmail interfaces.