FTR: mod_mbox treats the message the same: http://mail-archives.apache.org/mod_mbox/incubator-general/201701.mbox/browser
Note that == may not always be present; one or two == are added if necessary for padding when the input is not a multiple of 3 bytes. In particular, the footer does not have the == trailer. If no padding is needed, then the == is not present, and the footer could be appended without an issue. i.e. on average in 1/3 of the cases the footer can be added and will be decoded OK. In other cases, AFAIK it's only possible to merge new text by decoding the body (or at least the last 4 chars), adding the new text, and re-encoding. On 13 January 2017 at 14:39, Daniel Gruno <[email protected]> wrote: > Top posting because lot of text :p > Yeah, it's a specific issue with ezmlm doing what it's not supposed to > do, which is edit an email to add that field (there are lots of other > issues with that!). We can possibly work around it if need be? > > This is a specific thing that ezmlm (and some other mailing list > systems) do, so it's always only going to be that footer that gets lost > - the incentive to work around it ain't exactly high, but I can probably > look at it anyway :) > > With regards, > Daniel. > > On 01/13/2017 03:35 PM, Stian Soiland-Reyes wrote: >> Sorry, but this is not directly about Ponymail.. but a question about base64 >> encoding which I wonder if you have come across: >> >> I came across this message [email protected]: >> >> https://lists.apache.org/thread.html/f9a44f9f01bf75a320e399c8c660844041be6f2d8d3b261138de7c34@%3Cgeneral.incubator.apache.org%3E >> >> and in the raw source we see it is base64 encoded: >> >> https://lists.apache.org/api/source.lua/f9a44f9f01bf75a320e399c8c660844041be6f2d8d3b261138de7c34@%3Cgeneral.incubator.apache.org%3E >> >> ..terminating with: >> >> YW4gdW5kZXJzdGFuZGluZyB0aGF0IG1vdmluZyB0byBBU0YgcmVwb3MgaXMgb2YgdGhlDQo+IGhp >> Z2hlc3QgaW1wb3J0YW5jZSBmb3IgdGhlIG5leHQgbW9udGguDQoNCg== >> DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t >> LS0tLS0tLS0tLS0tLS0tLS0NClRvIHVuc3Vic2NyaWJlLCBlLW1haWw6IGdlbmVyYWwtdW5z >> dWJzY3JpYmVAaW5jdWJhdG9yLmFwYWNoZS5vcmcNCkZvciBhZGRpdGlvbmFsIGNvbW1hbmRz >> LCBlLW1haWw6IGdlbmVyYWwtaGVscEBpbmN1YmF0b3IuYXBhY2hlLm9yZw0K >> >> Now this is a bit odd for me, as == is normally just at the end of a >> Base64-encoding.. it turns out that this is the end of the quote of Felix' >> message, while the bit after "==" is the amended "To unsubscribe" footer from >> the mailing list server. Decrypting with Python's "base64" module stops at >> == and >> strips the footer (similar to Ponymail). >> >> >> I use notmuch locally for mail indexing (https://notmuchmail.org/) , and the >> == >> is for some reason output as \0 characters when showing that email: >> >> notmuch show id:[email protected] | tail -n 10 >> | less >> >>> high speed. But we have an understanding that moving to ASF repos is of the >>> highest importance for the next month. >> >> ^@^@ >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> Here ^@ is less showing the NUL characters corresponding to ==. >> >> In Ponymail we don't get to see the "----" bit after null -- everything after >> it is truncated. I don't know if this would only happen with footers or if >> also replies/forwarding could be affected in various clients. >> >> Now I don't know if that would count as a bug or not in notmuch (my bet), the >> apache.org ezmlm list server (perhaps) or Ponymail, (Certainly not an >> important >> one) - but it would seem this would make it possible to make emails with \0 >> characters with content that shows for some, and not for others. >> >> http://tools.ietf.org/html/rfc4648 says that implementations MAY ignore == >> before the end, but not what they should do about them if they don't ignore >> them :) >> >> Thought you might (not) want to know :) >> >
