Server nimmt Email für Domain an und soll das doch nicht

    • Server nimmt Email für Domain an und soll das doch nicht

      Hallo,

      ich konfiguriere meinen Kunden-Server gerne der Art, dass nur die Website gehostet wird. Der A-Record bei Provider des Kunden wird auf meinen Kunden-Server umgebogen und der Kunde kann so sein Email-Management selbst übernehmen und ich kann mich in seinem Namen einzig um seine Webpräsenz kümmern.

      Das hat eine Weile funktioniert, indem ich in der die EasySCP-Domain-Vorlage (damals noch EasySCP 1.x) die Domains, für die keine Emails angenommen werden sollen, auskommentiert habe. Seit geraumer Zeit funktioniert das nicht mehr.

      Die Mailq läuft voll und ich bekomme nach ca. 7 Tagen eine entsprechende Unzustellbarkeitsnachricht. Als Workaround habe ich in der Zwischenzeit die Email weitergeleitet.

      In der Mailq steht

      Source Code

      1. 4FA1F1AC0A163 909 Fri Aug 4 12:12:29 absender@domain.de
      2. (connect to xx.meinrootserver.de[private/dovecot-lmtp]: No such file or directory) empfaenger@domain.de

      Das ist auch logisch: lokal gibt es die Emailadresse ja auch nicht. Die soll also nach draußen gehen und dort durch den Email-Empfänger beim Provider empfangen werden.

      Ich habe folgendes erfolglos versucht:

      Reseller
      Max. Anzahl E-Mail-Konten
      (-1 deaktiviert, 0 unbegrenzt)
      auf -1 gesetzt

      Ebenso beim Benutzer

      Ebenso habe ich Manuelle DNS-Unterstützung aktiviert und den MX-Record auf dem Mailserver des Providers gesetzt.

      Ich will nicht ausschließen, dass ich durch manuelle Fummelei (oder auch die verschiedenen Migrationen über die unterschiedlichen Versionen) etwas durcheinandergebracht habe. Deshalb habe ich dann irgendwann in der Datenbank die Befehle:

      SQL-Query

      1. UPDATE `domain` SET status = 'add';
      2. UPDATE `domain_aliasses` SET status = 'add';
      3. UPDATE `mail_users` SET status = 'add';
      4. UPDATE `subdomain` SET status = 'add';
      5. UPDATE `subdomain_alias` SET status = 'add';
      ausgeführt und unter EasySCP Debugger die offenen Requests ausführen lassen.



      Wo kann ich noch bei der Fehlersuche weitermachen?

      Ich wäre dankbar für jeden Hinweis. Vielen Dank für Eure Zeit.

      Oliver.

      --
      EasySCP version: EasySCP 2.0.2
      Operating system Debian GNU/Linux 7
      Kernel 3.2.0-4-amd64
      Apache Apache/2.2.22
      PHP PHP 5.6.31-1
      MySQL 5.5.57
    • Hi,

      normalerweise sollte er das "-1" korrekt interpretieren. Ich schaue mir das aber vorsichtshalber nochmal an.

      Für dein System würde ich empfehlen das du mal die "mail.domains" Tabelle durchgehst und alle "falschen" Domains entfernst, also diejenigen, welche Lokal nicht als Mail vorhanden sein sollen (ggfls. auch die Tabelle "mail.users" prüfen auf unerwünschte Einträge).

      Die Änderungen werden eigentlich sofort übernommen, du kannst aber auch sicherheitshalber Postfix und Dovecot beenden und neu starten. Dann solltest du ruhe haben.
      Gruss
      Shadow
    • Hallo ShadowJumper,

      danke, danke für die superschnelle Antwort. Bitte erlaube kurz zwei Rückfragen:

      Frage 1:
      Die Tabelle "domains" in den DB "mail" ist doch das Äquivalent zu der alten "domains"-Textdatei, oder? Wird die Tabelle nicht neu geschrieben, wenn ich wie oben beschrieben die offenen Requests abarbeiten lasse?

      Anmerkung: Mir ist ähnliches auch in der DB "powerdns" aufgefallen. Dort sammeln sich bspw. die alten Domains, die eigentlich schon per Web-Gui entfernt wurden.

      Frage 2:
      Gibt es die Möglichkeit, die komplette Konfiguration auf Basis der in der EasySCP-DB hinterlegten Daten neu zu schreiben? Ist die Vorgehensweise (UPDATES (siehe unten) in der EasySCP-DB und dann Requests ausführen lassen) die richtige?

      Updates auf EasySCP-DB:

      SQL-Query

      1. UPDATE `domain` SET status = 'add';
      2. UPDATE `domain_aliasses` SET status = 'add';
      3. UPDATE `htaccess` SET status = 'add';
      4. UPDATE `htaccess_groups` SET status = 'add';
      5. UPDATE `htaccess_users` SET status = 'add';
      6. UPDATE `mail_users` SET status = 'add';
      7. UPDATE `subdomain` SET status = 'add';
      8. UPDATE `subdomain_alias` SET status = 'add';
      Danke und viele Grüße

      Oliver
    • Ich habe eben nochmal folgendes probiert:
      • Ich habe MEINEDOMAIN.DE neu angelegt
      • Ich habe Emails sowohl beim Reseller, als auch beim Benutzer Max. Anzahl Email-Konten auf "-1 gesetzt.
      • Ich habe keine manuelle DNS-Behandlung konfiguriert
      Auf meinem Rootserver gibt es auf dig mx meinedomain.de folgende Antwort:

      Source Code

      1. # dig mx meinedomain.de
      2. ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> mx meinedomain.de
      3. ;; global options: +cmd
      4. ;; Got answer:
      5. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24332
      6. ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
      7. ;; QUESTION SECTION:
      8. ;meinedomain.de. IN MX
      9. ;; ANSWER SECTION:
      10. meinedomain.de. 7200 IN MX 10 mail.meinedomain.de.
      11. ;; ADDITIONAL SECTION:
      12. mail.meinedomain.de. 7200 IN A 12.34.56.78
      13. ;; Query time: 2 msec
      14. ;; SERVER: 127.0.0.1#53(127.0.0.1)
      15. ;; WHEN: Fri Aug 4 14:38:28 2017
      16. ;; MSG SIZE rcvd: 69
      Display All


      Ist das so gewollt und richtig?

      Ich interpretiere die Antwort schon so, dass der lokale Mail-Server, für den die Emailannahme eigentlich deaktiviert ist, doch für die Emailbehandlung eingesetzt wird und dann feststellt, dass es das lokale Postfach nicht gibt und deshalb die Undelivery Message schmeißt.

      Aktiviere ich "Manuelles DNS" und ändere den MX-Eintrag auf "mail.outsidedomain.de", dann liefert dig erwartungsgemäß:

      Source Code

      1. # dig mx meinedomain.de
      2. ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> mx meinedomain.de
      3. ;; global options: +cmd
      4. ;; Got answer:
      5. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56423
      6. ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
      7. ;; QUESTION SECTION:
      8. ;meinedomain.de. IN MX
      9. ;; ANSWER SECTION:
      10. meinedomain.de. 3600 IN MX 10 mail.outsidedomain.de.
      11. ;; Query time: 2 msec
      12. ;; SERVER: 127.0.0.1#53(127.0.0.1)
      13. ;; WHEN: Fri Aug 4 14:45:43 2017
      14. ;; MSG SIZE rcvd: 67
      Display All

      Das scheint so richtig zu sein. An einem "echtem" Testaccount führte das dann auch zu der gewünschten Weiterleitung zu originalen Provider.

      Ich freue mich nochmal über einen kleinen Kommentar dazu. Ich werde das Thema mal weiter im Auge behalten.

      Viele Grüße

      Oliver
    • Hi,

      zu deiner Frage: Ja das ist richtig, diese Tabelle ist das äquivalent der alten Konfiguration. Welche Version hast du bisher eingesetzt? Eigentlich sollte das "auf räum" Problem schon beseitigt sein.

      Zu Frage 2: Prinzipiell könntest du den Inhalt der mail.* und powerdns.* komplett löschen. Nur bei den powerdns Tabellen darauf achten das die Eintrag mit der "easyscp_domain_id" = 0 erhalten bleiben. Diese Einträge werden nur beim Setup erzeugt für den FQDN/Master.

      Zum anderen Thema: Das verhalten ist eigentlich korrekt. Beim anlegen der DNS Einträge kann das System ja nicht wissen, das du einen externen MX benutzen willst. Würde das System Lokal keinen MX erzeugen, dann würden Mails vom Lokalen System ebenfalls nicht zugestellt werden können, da der lokale DNS Server korrekt melden würde das er zwar zuständig sei für "meinedomain.de" aber es keinen MX Record gibt -> Mail wird sofort als unzustellbar markiert.

      Somit gibt es da eigentlich keine "saubere" Lösung. Die einzige Lösung wäre beim Anlegen der Domain zu fragen, ob das System Lokal auch für DNS zuständig sein soll oder eben nicht.

      Das widerspricht dann aber etwas dem Prinzip "Easy". Im Grunde soll es ja quasi eine komplett Lösung aus einer Hand sein. Das Leute, die sich damit auskennen, es gerne etwas um konfigurieren wollen ist diesbezüglich ja kein Widerspruch, das versuchen wir ja stückweise zu berücksichtigen und einzubauen. Sprich wer es einfach haben will, nutzt es "Out of the Box", und den anderen geben wir die Möglichkeit das System anzupassen.

      Nur geht das an einigen stellen leider nicht über Nacht. ;(
      Gruss
      Shadow
    • Moin,

      danke für die ausführliche Antwort.

      Meine zuletzt benutze Version EasySCP 2.0.0 Build 20160122(?). Die habe ich dann auf 2.0.2 Build 20170427 aktualisiert. Dort habe ich eine alte Domain beseitigt, die dann weiter in der DB geblieben ist. Vielleicht habe ich beim Update etwas falsch gemacht...


      ShadowJumper wrote:

      Nur geht das an einigen stellen leider nicht über Nacht.
      Das ist klar. Ihr macht, wie schon gesagt, einen tollen Job - weiter so. Frei nach dem Grundsatz der Entwickler eines bestimmten CMS: die Version ist eben fertig, wenn sie fertig ist. ;)

      Danke und viele Grüße

      Oliver