sendeffect · Infrastruktur-Migration · Briefing

PowerMTA-Flotte, Mandanten & der V2-Tunnel: Wien → Leipzig

Live-Audit der drei alten PMTA-Relays, Mandanten-zu-IP-Zuordnung über alle 41 App-Instanzen und sämtliche serverübergreifenden Datenflüsse, die für das Tunnel-Design relevant sind.

STAND 2026-07-10QUELLEN: old-02…old-13 (live) DOKUMENTE: OLD_MTA_IP_INVENTORY.md · TENANT_IP_MAP.md · V2_TUNNEL_COMMS.md
3.896
öffentl. IPs gebunden
eindeutig, über 3 MTAs
3.166
IPs mit Sende-Reputation
vmta-Quelladressen
30
/24-Subnetze
alle nach Leipzig portierbar
570
Mandanten
145 aktiv (Login ≤ 1 J.)
3.203
virtuelle MTAs
in 1.060 Pools (≈ 1 IP je vmta)
01 · Flotte

Drei Relays, sehr unterschiedliche Footprints

Jede konfigurierte Quell-IP ist tatsächlich gebunden — nirgendwo verwaiste vmtas. Aber ein Fünftel der gebundenen IPs hat nie eine Senderolle bekommen.

old-06 connect.smtp-relay.io

185.176.152.254  PMTA v4.0r17 · 2014
IPs gebunden
1.830
vmta-Quellen
1.399
Mandanten zugeordnet
857
vmtas / Pools
1.415 / 323

old-10 11335-10

185.176.153.198  PMTA v5
IPs gebunden
381
vmta-Quellen
258
Mandanten zugeordnet
172
vmtas / Pools
259 / 94

old-13 11335-13

79.142.191.3  PMTA v5 · höchstes Volumen
IPs gebunden
1.690
vmta-Quellen
1.509
Mandanten zugeordnet
1.189
vmtas / Pools
1.529 / 643

IP-Nutzung je Relay — alle gebundenen IPs nach Rolle

einem Mandanten zugeordnet vmta-Quelle ohne aktuellen Mandanten gebunden, nie vmta-Quelle

Gesamtflotte — 3.896 gebundene IPs nach Nutzung

aktive Mandanten · 1.488 nur inaktive Mandanten · 730 konfiguriert, nicht zugeordnet · 948 ungenutzt (nie konfiguriert) · 730

Nicht zugeordnet = Pools, auf die nur 380 verwaiste Routing-Regeln zeigen (Mandant in der App gelöscht, Konfiguration nie bereinigt). Zusammen mit dem ungenutzten Block: die primären Nicht-migrieren-Kandidaten — vorher orphan_rules.csv prüfen (API-/Transaktions-Sender tauchen nie in user_addresses auf).

Altlasten, die nicht mitkommen: 5 IPs sind gleichzeitig auf old-06 und old-13 gebunden (ARP-Risiko) · 185.46.84.241 ist ein Tippfehler-Zwilling von 185.46.184.241 · old-06 mischt /16- und /24-Masken auf Sekundäradressen · old-06 läuft noch auf PMTA v4 von 2014 — mit dem größten Listener-Footprint.
02 · Subnetze

30 /24er — keines gehört nur einem Host

Elf Subnetze sind praktisch voll belegt (247–253 IPs). Die meisten verteilen sich auf zwei oder drei Relays — genau deshalb erlaubt der V2-Tunnel, der jedes /24 an beiden Standorten announced, einen Umzug entlang der Mandanten statt entlang der Subnetze.

old-06 old-10 old-13
03 · Mandanten

Wer tatsächlich auf diesen IPs sendet

Join der Versanddomains aus user_addresses aller Instanzen gegen die PMTA-Regeln mail-from → vmtapool (aktive Regeln, dann auskommentierte Relikte, dann Pool-Namenskonvention). Jeder aktive echte Kunde aufgelöst; 2.218 IPs tragen einen Mandantennamen.

Top 12 aktive Mandanten nach dediziertem IP-Bestand

Relay-Verteilung:  old-06 old-10 old-13
347 IPs werden von mehr als einem Mandanten genutzt (Agentur-Pools wie cooper-ads): die lassen sich nicht mandantenweise umziehen, ohne den ganzen Pool zu koordinieren. Und die großen Sender liegen über allen drei Relays — GMC allein hält 167 IPs auf 06+10+13. Wellenplanung pro Mandant: out/tenants.csv, KumoMTA-Egress-Erzeugung: out/tenant_ips.csv + out/pool_ips.csv.
04 · Tunnel & Datenflüsse

Was durch den Tunnel geht — und was nie muss

Alles zwischen App und MTA läuft bereits über externe IPs — es passiert den Tunnel unverändert. Sämtlicher interner Verkehr bleibt in Wien und endet mit der Hardware — sofern die unten vereinbarten Lösungen die zwei Wien-gebundenen Abhängigkeiten ersetzen. Entschieden: Der Tunnel selbst ist unverschlüsselt (bare L2) — daraus folgen verbindliche Regeln, siehe unten.

Alte Infrastruktur Wien

Web / App · 02, 04 + mixed 07, 08, 12
Datenbanken · 03, 05 (+ lokal auf 07/08/12)
PowerMTA · 06, 10, 13 3.166 Sende-IPs
  • Web → DB · MySQL 10.254.25.x — je Mandant am selben Standort, zieht gemeinsam um
  • middleware_common-Replikation · Master 03 → 05/07/08/12 — ersetzt durch Sync-Lösung ↓
  • Backup-NFS → old-03 /bkshare · Hoster-LDAP/SAN — nur Wien, endet mit der Stilllegung
V2-Tunnel/24s an beiden Standortenunverschlüsselt

Neue Infrastruktur Leipzig · OpenStack

Mandanten-VMs · sendeffect-01 … Provisionierung je Welle
KumoMTA · geplant Egress-Pools aus tenant_ips.csv
Eigenes middleware_common · eigene Backups
  • heute schon standortübergreifend: SMTP → old-13 (STARTTLS) · Bounce-Abholung per rsync/SSH — die Blaupause

Fluss-Matrix

FlussPfadIPsVerschlüsselungStatusLösung
AApp → MTA SMTP :25/:2025 öffentlichSTARTTLSSTARTTLS erzwingen Tunnel unverschlüsselt → für standortübergreifenden Versand ist STARTTLS Pflicht (SMTP_STRICT_TLS vorhanden)
BMTA → App Bounce-Feed, NFSv3 öffentlichKlartextquert nie Standorte NFS niemals über den Tunnel (Empfänger-PII im Klartext) — je migriertem Mandanten läuft die se2--Filter- + rsync/SSH-Pipeline, produktiv erprobt
CWeb → DB MySQL internkein Einfluss Web+DB je Mandant am selben Standort, ziehen gemeinsam um
Dmiddleware_common-Replikation 03 → 05/07/08/12 internLösung vereinbart Sync alt → neu per Webhook oder ~10-Minuten-Cron über TLS/SSH, solange die Inhalte aus der alten Infrastruktur gepflegt werden
EMTA → Web Unsubscribe + FBL, HTTPS öffentlichTLSFix je Instanz siehe unten — eine Instances-Zeile je migrierter Instanz + eindeutige Instanznummern; FBL-Nachfolger zum Cutover
FBackups NFS → old-03 interngelöst neue Infrastruktur sichert lokal — kein standortübergreifender Backup-Verkehr
G/HHoster-LDAP/SAN · Link 09↔07 internkein Einfluss an die Wiener Hardware gebunden / ungenutzt
INeue VM ↔ alte Flotte SMTP, rsync, SSH öffentlichTLS/SSHläuft heute quert das offene Internet bereits verschlüsselt — das Muster für alles darüber
Entscheidung (2026-07-10): Der V2-Tunnel ist unverschlüsselt (bare L2), eine zusätzliche Verschlüsselungsschicht ist nicht gewollt. Verbindliche Konsequenzen: Klartext-Protokolle queren niemals die Standorte (Bounce-NFS bleibt je Standort; se2-Pipeline übernimmt) · standortübergreifendes SMTP nur mit erzwungenem STARTTLS · die Reihenfolge-Regel wird Pflicht: eine IP wird erst in Leipzig verankert, wenn ihre Sender migriert sind — dann muss Klartext-Verkehr den Tunnel nie durchqueren.

Fluss E im Detail — Mailto-Unsubscribe ist ein Instanz-Thema, kein Architekturproblem

List-Unsubscribe-Antworten landen bei PMTAs unsubmail, das den zentralen Forwarder mit der numerischen Instanz-ID aufruft, die in jeder versendeten Mail steckt. Der Forwarder schlägt middleware_common.Instances → IemBaseUrl nach und leitet den Browser des Abonnenten per 302-Redirect zur Instanz. Im Code auf old-08 verifiziert.

  • Je migrierter Instanz: die Instances.IemBaseUrl-Zeile aufs neue Zuhause umstellen — Unsub-Links aus Alt-Mails folgen dann automatisch. Kein Alt-→Neu-Serverlink nötig; der middleware_common-Sync (Fluss D) transportiert die Zeile.
  • Namensraum-Falle — dieselbe Klasse wie die X-Binding-Kollision: der Lookup schlüsselt auf sendlx_<N>. Nutzt eine neue Instanz eine Nummer, die in der alten Flotte noch lebt, landet der Redirect auf der falschen URL → neue Instanzen brauchen flottenweit eindeutige Nummern, abgestimmt mit dem se2--Binding-Token-Schema.
  • FBL/Beschwerden (UnsubscribeByMail.php, old-02) ist zentral, nicht instanzbezogen: Allowlist auf 146.255.57.222 (old-13). Braucht Nachfolger + Allowlist-Pflege zum Cutover.
05 · Entscheidungen & offene Punkte

Vereinbart — und was noch offen ist

Entschieden (2026-07-10)

PunktLösung
Alle 30 /24er portierbarWien → Leipzig; kleiner als /24 zieht nichts um. Der V2-Tunnel verankert jedes /24 während der Übergangszeit an beiden Standorten.
Tunnel unverschlüsseltBare L2, keine zusätzliche Schicht. Konsequenz: Klartext-Protokolle queren nie die Standorte; STARTTLS-Pflicht für standortübergreifendes SMTP; strikte IP-Verankerung je Welle.
middleware_common-SyncWebhook oder ~10-Minuten-Cron, alt → neu, öffentliche IPs + TLS/SSH — ein Zusatzwerkzeug der Migration, ersetzt die interne MySQL-Replikation standortübergreifend.
BackupsDie neue Infrastruktur sichert auf ihrer Seite. Null Backup-Verkehr zwischen den Standorten.
BouncesGelöst: se2--Token-Filter auf old-04 + Abholung per rsync/SSH. Ende-zu-Ende mit einem echten old-13-Bounce nachgewiesen.

Offene Punkte

#PunktWarum es zählt
1STARTTLS-Durchsetzung App → MTA für standortübergreifenden Übergangsverkehr Folge der Tunnel-Entscheidung: Klartext-SMTP darf den Tunnel nicht queren (Fluss A)
2Instanznummern-Namensraum fürs Unsub-Routing neue Instanzen dürfen keine lebenden Alt-Nummern wiederverwenden (Fluss E)
3FBL-Empfänger-Nachfolger + Allowlist-Pflege Kontinuität der Beschwerdeverarbeitung, wenn 02/13 stillgelegt werden
4948 nicht zugeordnete IPs prüfen via orphan_rules.csv bevor sie als „nicht migrieren" gelten (versteckte API-Sender)
5Resilienz old-03 — middleware-Master + Backup-Ziel der Flotte mit totem DRBD-Peer Single Point of Failure für das gesamte Migrationsfenster
6Hygiene: old-12 rpcbind :111 antwortet Internet-Scannern; NFS-Export-Beschränkungen der MTAs prüfen Angriffsfläche verkleinern, solange Wien produktiv ist