Spamfilters are not written in RFCs. Spam is a authentication/authorization security issue that needs to be solved and not a single RFC stepped in to solve that. So it was solved otherwise.

The next big item is email-over-IPv6. Rules are not yet set but one thing is clear: You cannot effectively block on ip address. An alternate method has to be used. My guess is that it will be SPF and/or DMARC. The big inbox-providers (Hotmail/Gmail/Yahoo/Aol) have something to protect (their business model) so they MUST have an effective anti-spam method. They might start to require DMARC or SPF before they accept email (so they can validate the domain with a personal whitelist or reputation-system). It might actually drive IPv6 acceptance.

That is your opinion. And you can do what you want with your mailing list server.

And any domain owner can configure DMARC if (s)he wants to. Which leaves the recipient mailserver operator free to NOT accept the message from your mailinglist server. Your opinion is not internet-law (even if it is written in RFC).

It is however not broken

Please inform yourself better. Even DMARC-haters agree on the fact that mailinglist-software can be changed so that DMARC-enforcing domains are not put in the From or Reply-To field.

Does it mail DMARC-compliant? Mailinglist operators were complaining like the world fell down a few weeks ago.

Are they calling actors cockroaches? Or were they watching politics on 3d?

Just counter that with: "Well, employers are just like other people. And I happened to to be employed by a bad example who tried to f*** me over. I presume you are more reliable?"

And the result is: One person goes to jail and everyone is vulnerable. It seems like a bad trade-off.

or libraries of congress, or liters

Not at all. We probably have the best roads in the world. Silky smooth, hardly makes noise, very well maintained. I drove through Europe a while ago from the Netherlands to Italy and the NL was the quietest. We invest a lot in infrastructure and roads are part of that. The onlly thing that is not nice is the speedbumps.

I was in North Caroline a while ago and it reminded me of a bad stretch of Polish road. Canada is ok, given its two seasons (winter and road repair season?).

True, most of it. They are actually cutting down on public lighting after peak hours due to energy savings. They still light crossings but reduce it on lengthy parts where not much happens. Most inner cities, which are compact to US standards, remain lighted.

Some have overseen the fact that a heartbeat in one layer isn't always enough. The OS tcp/ip heartbeat might have different timeout than preferrable for TLS and you may not have the option to change the one from the OS for different reasons. The second issue is that you want to have the proper exception handling (to correct the issue you had with the bad connection). Just getting a new connection may not cut it.

I had the issue recently when a redundant system had a failover due to maintenance. The firewall of the second system, which took control of the IP address, just ignored the packets (TCP session failover was of no use here) and the messaging system thought that the message was sent (tcp was not complaining for a while). I fixed this by letting the messaging system send an ACK after every message and activating the heartbeat of the messaging system. Any failover is now detected quickly and resolves in making a new connection (and when this happens while sending a message: retry). The original situation always wasted a dozen messages and then corrected by making a new connection.

People in the US do not care for another. They are polite but do not care, not really. It shows when people are at their most vulnerable: No job, in prison, poor, health issues.

@home: Ubuntu, @work: Ubuntu with Virtualbox running windows for email, @work.server: Debian

No dual boot anywhere

This... I don't think about checkout-time any more.