Email, Fish, Teams, DNS, ECN, Geoloc, MTA-STS, DMARC, RMQ

  1. Had little fun with friends, we were looking for broken email address handling, and it was trivial to find issue after issue on almost every service. The services which do work correctly, are a really small margin compared to totally broken implementations. - To sum it up, email is just so totally broken mess. It isn't that hard, or is it. Email addresses (@ Wikipedia). For most of engineers, that seems to be way too hard.

  2. Played with Fish shell. Good stuff: funced, vared, dirh, nextd, prevd

  3. Again got amazed how badly file sharing features on Teams suck. It's a total mess and really badly implemented. How about getting several references to the same file? Too hard for engineers. Well, seems to be so. I just wish someone at Microsoft would learn about hashing and the could conclude that there's a reasonable change that, if the filename size and sha256 are the same, the file is the same as the existing file. But who knows, maybe they want it just to be extra safe? Of course a hash collision is always possible, even with perfect hashes, when the data is larger than the hash size and when the input data size grows number of collision possibilities naturally explodes.

  4. DNS case (@ - A nice debugging story from Google Cloud Team. Sometimes fixing issues can be hard, yet on most of cases, nobody ever bothers to look for the root cause. Any quick'n'dirty workaround is what's "good enough" and that's it. Issue solved.

  5. When using ECN (@ Wikipedia), I'll always disable the TCP slow start (@ Wikipedia) after idle option. It's pointless to slow start every time. Especially when using SSH shell or other persistent, quite low traffic, but bursty protocols, you'll notice the difference when doing anything which dumps quick burst of data data on screen. Also with remote hosts I'll always use delayed compression, because it helps to fit data in a fewer packets -> lowering change of packet loss / buffer full situations.

  6. IP location != not language (@ - This one should be obvious, but there are so many sites which get it wrong. It seems that the "Accept-language: fi,en-US;q=0.7,en;q=0.3" header data structure seems to be way too complex to interpret for many engineers. Especially when using some tunneling, this problem becomes obvious. If I use tunnel, it doesn't mean my language preferences would have changed in anyway.

  7. MTA-STS RFC8461 (@ )- Nice. Purpose of this is really good. But the approach is complex, brittle and error prone. It's far from simple and effective, which would be the approach which I would personally like. Naturally it's doable, but probably not worth of the time, effort and extra risk it brings. Two tests: STARTTLS Everywhere (@ EFF) - and Hardenize (@ domain configuration checker.

  8. Updated DMARC (@ Wikipedia) configuration for all domains I'm managing.

  9. Read An introduction to RabbitMQ (@ In one of upcoming projects there has been discussion about using RabbitMQ. I personally said, that I don't really care what transport is being used to transfer the data. So if it's RabbitMQ, HTTPS/ REST, Files, SFTP, FTP, FTPS, ZeroMQ, Kafka, TCP, UDP, MQTT, Redis, MSMQ, SMTP PubSub, WebSub, Transact-SQL QUEUE's or traditional SQL tables it really doesn't matter at all. Only option I really disliked was MSMQ. Ugh, the intro post was kind of scary and bad. It didn't give anything with value at all. - After all, using any queue instead of something else, doesn't many any meaningful difference. A -> B securely, reliably, somewhat efficiently with delivery confirmation is the key. How that's done, not that big a deal. "Anything over anything" as I say. Yet if possible, I kind of like avoiding intermediaries, especially if those are doing some extra transformation. Yet some organizations require all data transfer to use ESB which might support plenty of different protocols and communication methods. But after all it's all about authentication, "message passing" / data forwarding with logging. Late addition using Postgres instead of Redis (@ as said, the same results can be achieved in multiple ways, performance may vary. As said many projects achieve this with software like SQLite3, it all depends from the requirements.