Samstag, 24. Oktober 2026
Wegen anhaltender Probleme mit Cyons Email-Infrastruktur, und insbesondere auf Grund eines unterschiedlichen Verständisses zwischen Kunde und Anbieter, für was eine solche Infrastruktur gebraucht werden kann und dabei tolerieren sollte, bin ich auf Migadu gestossen.
Der Anbieter will nur eines machen: Email, und zwar gut, für Power User und Geeks. Ein fantastisches Produkt!
Ich habe deshalb über Hostpoint eine zweite Domain gekauft, und wickle nun emailbasierte Systemmeldungen meines Serverparks über Migadu ab.
So möchte ich verhindern, dass mir Cyon über mehrere Tage hinweg wegen „Problemen“ mit Emails meiner Infrastruktur meine privaten und geschäftlichen Emails abklemmt.
In dem Zusammenhang: Cyons Crew ändert auch schon mal einfach so das Passwort eines angeblich „kompromittierten“ Email-Kontos (Meine Meinung: Bounces sind kein Hackerangriff …), und blockiert dann wenig später gleich das ganze Kundenkonto, weil die Automationen, welche mit dem alten, vom Kunden gesetzten Passwort weiter regelmässig auf das Email-Konto zugreifen wollen, dann als noch grössere „Attacke“ erachtet werden. Item.
Migadu hat Restriktionen, wie viele „outgoing“ Mails man versenden kann. Der Clou: Emails, welche innerhalb der eigenen Domain versendet werden, zählen hierbei nicht. Solange ich also von server.xyz@meineinfra.tld an events@meineinfra.tld maile, kann ich so viele Mails rauslassen wie ich will (vermutlich zieht aber dennoch Fair Use).
In den letzten Tagen stauten sich plötzlich Emails auf meinen Servern und konnten über Migadu nicht ausgeliefert werden.
In den Postfix-Logs tauchte immer wieder folgende Meldung auf:
...
Oct 23 19:06:28 SERVER postfix/smtp[73067]: Untrusted TLS connection established to smtp.migadu.com[51.210.223.36]:587: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256
Oct 23 19:06:29 SERVER postfix/smtp[73067]: 9556D5F006: to=, relay=smtp.migadu.com[51.210.223.36]:587, delay=121, delays=0.01/120/0.24/0.04, dsn=5.7.1, status=bounced (host smtp.migadu.com[51.210.223.36] said: 550 5.7.1 sender address rejected: not allowed (in reply to end of DATA command))
In meiner Recherche fand ich heraus, dass das Problem am 15. Oktober aufzutreten begann. Ich könnte schwören, dass ich an dem Tag nichts an Migadu geändert hatte. Aber ich kann mich täuschen.
Lustigerweise betraf dies nicht alle Emails, viele Mails kamen weiterhin durch, und anfänglich machte alles keinen Sinn.
Bis ich auf folgenden Blog-Artikel stiess: Email aliases: receive and send with a different address per sender. Dort wurde sowohl Migadu erwähnt, als auch genau die von mir beobachtete Fehlermeldung.
Die Schlüsselstelle im Artikel:
- In the Migadu admin, open the domain, then Mailboxes, then the mailbox that receives everything.
- Turn on Wildcard sender. The mailbox may now send as any address of this domain, with its own login. Identities don’t inherit the right.
- Open the domain settings and set the catch-all („improperly addressed messages“) to deliver to that mailbox.
- Use smtp.migadu.com, port 465 (SSL), with the mailbox address and password, in every client.
Jetzt ging mir ein Licht auf. Die Emails, die nicht ankamen, wurden über server.xyz@meineinfra.tld versendet, trugen als Absender aber From: monitoring@meineinfra.tld. Das hatte seit Eröffnung des Migadu-Kontos problemlos funktioniert, nun aber nicht mehr.
Nach etwas Herumpröbeln im Migadu-Interface dann die Lösung:
- Email Domains > meineinfra.tld > Mailboxes > server.xyz@meineinfra.tld > Wildcard Sender > [x] Permit wildcard sending Authentifiziere ich mich mit diesem Konto gegen Migadus SMTP, kann ich in From: einen beliebigen Präfix von @meineinfra.tld verweden.
- monitoring@meineinfra.tld hatte ich bei Eröffnung des Kundenkontos als Mailbox eingerichtet. Diese brauche ich aber nicht wirklich, da ich die Email-Adresse nur als Absenderadresse verwende. Somit habe ich die Mailbox gelöscht.
- Stattdessen erstellte ich unter Email Domains > meineinfra.tld > Mailboxes > server.xyz@meineinfra.tld >Identities eine neue Identity monitoring@meineinfra.tld, und gab ihr das Attribut Not used for authentication, sender persona only
Und siehe da, nach ein paar Minuten begannen meine Server, die bis jetzt zurückgewiesenen Emails in deren Postfix Queue auszuliefern.
Übrigens: Egal ob Cyon oder Migadu oder ein anderer Mail-Anbieter, was man auf keinen Fall will: Einen SMTP respektive eine INBOX mit Emails im Sekundentakt fluten. Deshalb habe ich in meiner Postfix main Folgendes stehen:
...
initial_destination_concurrency = 1
default_destination_concurrency_limit = 1
default_destination_rate_delay = 60
default_destination_recipient_limit = 2
default_process_limit = 100
...
