Whilst this is high risk for a flamewaresque HN policy violation I'm going to attempt a response.
When a very important email never arrived I suddenly realised I hadn't been receiving email for two days. Jumping onto the migadu site I found a brand new UI with all my regexes gone and my email ingestion broken. So I patch it up quickly and send a support ticket.
In short the response to the ticket was: "we had a storage layer failure [...] we could not serve all the requests [...] The catchalls and aliases have been a consequence - hence no announcement" (announcement is a reference to me asking why I wasn't emailed to tell me).
Unfortunate things happen, I get it. However. When they do, notifying clients should be a high priority.
Combine that with some previous and subsequent tickets that were closed without resolution and I have a pattern of behaviour that is completely absurd for the provider of a vital service.
The account that given in your post is at odds with what I received from the support team - this is even more evidence to me that migadu is not the right company to be responsible for my mail.
I also feel its important to highlight your claim "we have never had an outage where mail was lost". When an email responds to a sender indicating that a user does not exist the result is the email being deleted. Many terrible systems in business do this silently. The fact that migadu allowed this failure mode without a mitigation (and in your example, deliberately) is assuredly mail loss. What else could be done? It could be rejected but still saved (bulk disk writes with simple metadata - anything) so that intended receivers can be notified which senders now think they don't exist.
No risk of flamewar, I genuinely want to know your view, not defend ourselves in public. If we messed up, knowing where and how helps not to repeat it.
I agree we could have done that better, however an announcement was made via email and site, taken it reached you via notification address in account.
Nevertheless, my apologies on behalf of our team. We will take your criticism to improve. None of us were born doing this and we are learning as we go.
When a very important email never arrived I suddenly realised I hadn't been receiving email for two days. Jumping onto the migadu site I found a brand new UI with all my regexes gone and my email ingestion broken. So I patch it up quickly and send a support ticket.
In short the response to the ticket was: "we had a storage layer failure [...] we could not serve all the requests [...] The catchalls and aliases have been a consequence - hence no announcement" (announcement is a reference to me asking why I wasn't emailed to tell me).
Unfortunate things happen, I get it. However. When they do, notifying clients should be a high priority.
Combine that with some previous and subsequent tickets that were closed without resolution and I have a pattern of behaviour that is completely absurd for the provider of a vital service.
The account that given in your post is at odds with what I received from the support team - this is even more evidence to me that migadu is not the right company to be responsible for my mail.
I also feel its important to highlight your claim "we have never had an outage where mail was lost". When an email responds to a sender indicating that a user does not exist the result is the email being deleted. Many terrible systems in business do this silently. The fact that migadu allowed this failure mode without a mitigation (and in your example, deliberately) is assuredly mail loss. What else could be done? It could be rejected but still saved (bulk disk writes with simple metadata - anything) so that intended receivers can be notified which senders now think they don't exist.