Traffic Shaping, Outlook, Email, RFCs, Programming Logic, Rust, IPTV

1. Configured new router with traffic shaping. Some people claim that network traffic shaping and throttling is negative thing. But I personally strongly believe it's a positive thing. Reminded myself about related options, burst rates, sizes, ceilings, queue types, FIFOs and filter rules how traffic is put into different queues. kw: FQ_CODEL, HFQ, SFQ, PFIFO, FIFO, traffic shaping, queue management, throttling, bandwidth management, Quality of Service (QoS). networking, routing, ECN, Fair Queuing with Controlled Delay, Host Fairness Queuing, Stochastic Fairness Queuing, (First In, First Out), Priority FIFO

2. Outlook email sucks so hard, now I've configured my own SMTP out server, as well as SMTP in server, which relays emails to Outlook. That's kind of silly, but it works well. Because Outlook is blacklisting the IP addresses / ASN where the primary email relay servers are. And no those servers are NOT sending spam, nor those servers are open relays or abused. But even so, Outlook keeps blocking those. 

3. Again programmers do not understand RFCs. https://tools.ietf.org/html/rfc5322#page-49 - Yes email headers can contain comments. If your code doesn't work with comments, it's inherently broken. It would be fun to have a test project, where I would test N+1 services, which are broken and do not handle email correctly. Yet my guess is that most of services are broken, and there would be only a small bunch of services which do work correctly. - What does this tell about quality and competence of software developers and their understanding about the things they're trying to do.

4. Sometimes coding is just so boring, endless stream of "issues" from production, not covered by any test cases and specifications. Constant logic changes. Requirements for complex testing and validation. Which actually makes further changes very painful, because everything needs to be changed, when there are new logic changes and so on. - Business as usual. - It's totally and utterly useless to claim that 792382,34 does not match 793281,72. - Yes, so what? Why it doesn't match? And which one of the numbers is even right and which one is wrong, and why? - It's totally pointless to send such feedback. It's useless, there's nothing that could be done based on that. - Except wasting a lot of time looking for something without enough information. - This is pretty much why I say meetings and calls about such matters are also just waste of time. Without related facts and details, there's absolutely nothing to discuss about. - It would be nice to fix some "core problems", but when code is already in production, nobody wants to touch that anymore. It's just some "light cover it up" overlay code which will be used, masking problems in the core code.

5. Rust supports inline assembler. Haha, reminds me about the good old Turbo Pascal times. Every now and  then you could drop a new lines as inline assembler code to optimize something. No, it's good for performance sure, but it's still kind of funny. At least it's not C64 poke and peek. 

6. Lots of tuning with IPTV (server and client) setups. Now I can stream everything over HTTPS using VLC. Awesome. As well as if required, relay the traffic in secure way. It took quite a lot of tuning, because TV stream is delivered to static IP addresses using IGMP. But now traffic is being captured, and can be forwarded over HTTPS if and when required. Joy.

7. More discussion about SPF, DKIM and DMARC. No there's nothing special about this, it's easy to configure that correctly. But there are so many services which do not implement things correctly, or strict / reject rules cause secondary services to fail. So there are multiple overlapping reasons why this stuff could fail. Sometimes it's very hard to tell what's failing and why. Yet one obfuscation layer was the fact that Outlook bounces do not work, which is very annoying thing. After in depth troubleshooting, it's now clear why things work as they do. And in my case, I didn't have configuration error, but I've now found two other services which do not work correctly. Sigh. So classic. Also some people try to forward emails, without changing From field, which naturally fails. As it's supposed to! - To sum it up, Outlook costs you a lot of valuable time with constant troubleshooting and lost messages and curses of inherent unreliability. - I personally estimate that time lost to Outlook is now easily in several full 24 hour days. Because it's cloud service, there's no way to fix the issues. But if I would be running the service, as I'm doing with my own servers, it would be trivial and take minutes to fix. It's not that hard, cloud bleeping services just make it impossible to fix simple things. Classic curses of closed source crap. - On top of that time lost, there's the mental energy drain, which is catastrophic.

8. But how about something different? - Monorail - https://en.wikipedia.org/wiki/Monorail -.

2021-07-25