Did I open a can of worms here?

-2 seconds, jeesh that is fast (it must be very heavy to warp time like that, f-ing wormhole).

They seem complementary: There are technical and functional checks you can do to avoid misuse or abuse. And then there is reputation to check if you have previously conducted in a bad manner. All good predictors of things you don't want.

What eight years?

I only read 3000 cycles and a possible 300 mile radius which translates into 900.000 miles total lifetime. If that is only 22% true then it would be fine.

It is not like they have issues hauling things into space (https://en.wikipedia.org/wiki/Ariane_%28rocket_family%29). Or am I missing something?

we were innocent and naive. Now you can only trust open source.

Sorry to reply to myself, but I particularly like this post. It did not go into aspects very well but I liked the attention for other numbers.

Why do you give status updates? What does it tell them? Nothing. That is why they are so bored.

What they really need to be able to do is 'manage'. Giving them status updates (about service levels) are not the information they are looking for. Managing is about achieving a goal having certain risks and costs. Your goal is having happy customers about the service you provide. Even though that is formalized through SLAs, that will never be why a customer stays or goes.

The reason that it is difficult to tell anything about the 'process' 'providing service' is because it is a very undefined business process requiring skills on all sorts of areas. I prefer to say something about the aspects of the process. These may include e.g.: security management, incident management, hardware management, external supplier management, hr management, personnel knowledge management, building management, computer system management, release management, ... You notice that I put the word management behind every aspect. That is because all these aspects require activity on your part (and choices are to be made). Choose your aspects in a practical manner (lets say between 20 and 30 items).

The next thing is that you identify the following for every aspect: You describe shortly the current situation (e.g. operating system mgmt: We are running Debian Wheezy with automatic updates on wednesday because that is our service maintenance window. Sometimes packages are necessary from upstream). You describe the 'ideal situation' (e.g. for personnel knowledge mgmt: We would like all tasks to be able to be completed by two persons because people have holidays or may be sick. We have weekly knowledge sessions). You describe already known issues that need to be fixed. And lastly you give a grade: 1-5 if this aspect is a risk getting you goal achieved and 6-10 if you are (firmly) in control of the aspect. Remember: A 10 is probably a waste of money and other resources.

If you covered your area well, described all relevant aspects, you will then get something new: You are able to identify the largest risks (even if they did not go wrong) and unique selling points. In 9 out of 10 cases you will realize you are far from done with your work. In the 10th case you realize you can do your job with fewer people. When you have identified your aspects you should (partly) report on that.

Btw A great marketeer once held this speech. Since you are presenting something you should know a little about marketing (which is about making people enthousiastic).

I am aware of technical possibilities. I still think it is an option to _not_ use IPs and it may be a valid choice.

In the email world there are 'reputation' providers that will give an IP address a score (e.g. from 0 to 100). On many domains if your 'reputation' is too low, the email bounces. However we are heading towards an IPv6 world where ip-reputation is too hard (too many addresses). So you need another way to base your reputation on (e.g. your domain name or email address).

Who is providing the content and are they trusted (you better prove you are trustworthy). Just another option.

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.