SMTP, Postgres, OTR, np1sec, Consistency

  • Had issues with Microsoft SMTP Mail Server. It seems that the only format it's actually accepting is files with \r\n and utf-16le encoding. Ok, fine. But it took few annoying tests to find that out. I would have preferred utf-8 and \n. Also as usual, Microsoft is being extremely helpful, with error message 0xC00402CE. - Thanks - Really enraging trial and error slow process. I especially love when extremely simple and easy things are frustrating and takes quite a while. - After getting sick'n'tired how extremely picky the mail server is. I decided it's much easier to use full smtp client application to send mails, than just simply drop the data to pickup directory, which clearly isn't working option. - What did I say about transferring files over SMTP earlier? Hahah, now it did bite me. Because this is exactly that. Instead of moving files from A to B, I gather files from A and then deliver those over SMTP to B, because writing acceptable format for the picky application handling files for B is too annoying. - But isn't this what microservices and all the cool stuff is about? Instead of using os.rename('a','b') we can write a web server, user restful API, client and then send over HTTPS the 'a' to 'b'. It's so cool tech (!) awesome. Actually we could add extra modules, the data pickup and storage could be passed via SQL database and ... ;) - I just would like to keep it simple. - After lot of extra testing and playing it seems that the drop files has to be utf-8, even if the files in the other directories are using utf-16le. Sigh. - Good thing is that now both options are available. SMTPS, (TLS, Auth, etc.) and simple file drop to pickup folder.
  • Migrated a few production servers to new versions software & os, etc... Phew, lot of work. But miraculously everything worked perfectly after the load was switched to the new environment. I was expecting the normal 'city is burning' event.
  • Stability in a Chaotic World: How Postgres Makes Transactions Atomic - Nice post about ACID / MVCC Postgres stuff. But nothing new, all of this information is directly available from Postgres documentation. All old stuff. Some illustrations are very nice. And some of the things I didn't remember about. like the usage of bits to store information efficiently was good reminder. It's how programs should be written. Nowadays many programmers would make a class for it and then instances of it, storing id and one integer and the amount of overhead would be really amazing. Compared to this solution where they can store 32768 transaction states in 8 kilobytes. Mot programmers are just way too used to create bloated stuff. Yep, that's what I often do, unless I happen to create something extremely efficient out of nerd joy. - Also comments multi-threading vs multiprocessing were nice.
  • Secure communication basics from OTR: Encryption, No one else can read your instant messages. - Authentication, You are assured the correspondent is who you think it is. - Deniability, The messages you send do not have digital signatures that are checked by a third party. Anyone can forge messages after a conversation to make them look like they came from you. However, during a conversation, your correspondent is assured the messages he sees are authentic and unmodified. - Perfect forward secrecy, If you lose control of your private keys, no previous conversation is compromised.
  • Checked out np1sec protocol . "Distributed encryption for federated group chat". That's pretty classic problem. There are also countless solutions and the field is extremely fragmented. Also np1sec provides some extra: Authorship, A message recipient can be assured of the sender’s authenticity even if other participants in the room try to impersonate the sender.
  • Room consistency, Group chat participants are confident that they are in the same room. - Transcript consistency, Group chat participants are confident that they are seeing the same sequence of messages. See documentation.
  • Something different? Air-launched Cruise Missile (ALCM). Mostly were interested about JASSM and KEPD 350.