[Citadel Development] update?
If you have a chunk of time, I can do an interactive patch and test. I think we are getting somewhere, but I am not getting the expected results yet.
[Citadel Development] Update -- Saturday, 2021-feb-20
Good morning everyone! With my second cup of coffee finished and a 200 foot driveway full of snow to be plowed, I will post a quick update before heading outside. As previously mentioned, there has been a lot of yak shaving going on. It started with the AppImage development, which forced us to clean up the directory calculation code, which made it sensible to finally abandon LFHS, which made a lot of things a lot cleaner, but forced us to abandon the remaining spaghetti code in the networker, which forced us to rewrite the mailing list service. All of the above is now complete. I'm looking at the complaints in the Citadel Support room from some users who are noting the wrong addresses appearing in the to/from headers on Internet mail under certain conditions. That looks like something that needs to be addressed sooner than later, so I'll be looking at that next. When that is done, I will build a new version of the AppImage (which, frankly, ought to be automated nightly builds at this point, but I don't have the energy to do that) and y'all can begin testing it again. Damn side quests... :)
[Citadel Development] update: compose with inline images
I've had time to do some more work on composing with inline images. TinyMCE image inserter has support for a server-based image list, which is now generated from already-attached images, making it a simple matter to attach an image and then use it inline. Previous tests had been done with kmail which showed that an attached image with a cid: could be referenced from the html part of a multipart/mixed message. This means the image is shown inline and visible as an attachment, which I thought was fair. Sadly this does NOT display inline on thunderbird unless I convert the outer mime type to multipart/related; which stops it being shown as an attachment, and no doubt stops all attachments working. I shoulda read the mime specs instead of testing with flexible mailers. So, I think I'll add an "Insert" button next to the "Add" button below TinyMCE, the use of which indicates that the file should be in a multi-part related wrapper around the multipart/alternative, making it available to be referenced from the message. Only insert'd files will be visible in the image list. Only add'd files will be available for download. Does this suit everyone? I guess I'll make the "insert" button popup the tinyMCE insert dialog as soon as the image is uploaded. Sam
[Citadel Development] UPDATE on SMTP-AUTH and MIME problem at uncensored.citadel.org
I haven't figured out the weird issue on Uncensored yet -- the one that's affecting SMTP-AUTH and also the MIME parser -- but I think I have it isolated. As far as I can tell, it's related to CtdlDecodeBase64(). How does that affect SMTP-AUTH? Well, in PLAIN mode, the login credentials are transmitted using Base64 encoding. We of course call CtdlDecodeBase64() to handle that. It's also very telling that the MIME parser is always able to *enumerate* attachments, but it can't seem to decode them without very bad corruption. However, it's only the Base64-encoded attachments that are failing -- anything encoded in quoted-printable is fine. As a test, I manually assembled an RFC822 message containing a single part of type "text/plain" encoded in Base64. This is a non-multipart message, so it doesn't have to get fed into the part of the MIME parser that recurses through multipart boundaries. Sure enough, when I read the message with my client (which does the Base64 decoding on the client side) it was fine, but when I fetched the message using a MSG0 command (which does the Base64 decoding on the server side ... yeah, it's a legacy command) the message was corrupted. Now that we've got it isolated, I'd appreciate some help in tracking down the nature and source of the problem. Theoretically, this problem should only cause the operational errors we've seen so far, but shouldn't permanently corrupt any stored data. If I had to guess, I'd say that it probably has something to do with the static tables used by CtdlDecodeBase64(). These are initialized at startup and then kept around for the entire duration of the server run. Perhaps they are getting smashed somehow.
