QMail-/Plesk-Verhalten bei 2. IP

Plesk, Confixx, Froxlor, SysCP, SeCoTo, IspCP, etc.
Post Reply
blacksavior
Posts: 59
Joined: 2003-09-02 14:38
Location: Holzwickede
 

QMail-/Plesk-Verhalten bei 2. IP

Post by blacksavior »

Hallo Zusammen,
ich konnte bei Plesk und auch hier leider nichts zu meiner Frage finden - naja, so beginnt hier wohl jeder 2. Thread :-/

Eckdaten:
- 1und1 Root-Server
- 1und1 Standard-Config (Plesk, QMail....)
- eine IP für alle VirtualHosts

Ich möchte für ein Plesk-Physikal-Hosting nur noch einige wenige feste Remote-IPs für den Port 25 zulassen. Web, FTP und co bleiben unangetastet. Da dies die anderen Hostings nicht beeinträchtigen darf wird das Mittel der Wahl folgendes sein:

- Zusätzliche IP-Adresse bei 1und1 mieten und exklusiv diesem Hosting zuschlüsseln.
- unter login.1und1.com die Firewall für die neue IP aktivieren.
- Dort den Port 25 für alle Remotes außer den drei festen Remote-IPs sperren.
- Die Firewalleinstellungen der Shared-IP bleiben unangetastet.

Somit sollte nun eigendlich kein "fremder" Remote E-Mails an die neue IP schicken können; an die anderen Hostings mit der Shared IP jedoch weiterhin. Nun der Punkt, bei dem ich Eure Hilfe brauche:

Das betreffende Hosting läuft dann auf der neuen IP, die restlichen auf der alten. Übernimmt Plesk dies auch für die EMail-Dienste (Qmail)? DNS-technisch sicherlich, jedoch frage ich mir ob Plesk/QMail auch EMails an die Domain dieses Hostings annimmt, wenn diese an die Shared-IPs gerichtet sind. Da es der gleiche Server ist sind die Adressen ja bekannt.

Ich möchte ungerne nur zum testen eine IP bestellen.

Gruß
BlackSavior
beckerstef
Posts: 35
Joined: 2005-12-31 14:07
 

Re: QMail-/Plesk-Verhalten bei 2. IP

Post by beckerstef »

Ich benutze auch mehrere IP Adressen auf meinem Server mit Plesk, und ich habe das eben mal ausprobiert, solange Benutzername und Passwort stimmen ist Qmail die IP Adresse egal. Ausgehende Mails werden anscheinend auch immer über die 1. IP Adresse versendet. Egal welche IP beim Physikalischen Hosting angegeben ist. Die zusätlichen IP's scheinen nur beim Apache Verwendung zu finden. Korrigiert mich wenn ich falsch liege.

Stefan
blacksavior
Posts: 59
Joined: 2003-09-02 14:38
Location: Holzwickede
 

Re: QMail-/Plesk-Verhalten bei 2. IP

Post by blacksavior »

Hallo Stefan,

gelesen und direkt ausprobiert? Respekt (!) und ein großen Dankeschön!

Leider gefällt mir deine Antwort absolut nicht. :( Das vom Server ausgehender E-Mail-Traffic immer über die 1. IP läuft ist mir eigendtlich egal. Jedoch das der eingehende auch an der 1. IP akzeptiert wird, obwohl für das entsprechende Hosting nur die 2. aktiv ist, ist für mein Vorhaben ein absolutes no-go.

@all
Hat jemand hierzu eine Idee? Oder könnte man den SMTP Listenern ohne Plesk beikommen (?) und dies so, dass Plesk die Veränderungen einerseits nicht überschreibt, andererseits änderungen der E-MAiladressen (neu, etc.) doch berücksichtigt werden?

Gruß
BlackSavior
blacksavior
Posts: 59
Joined: 2003-09-02 14:38
Location: Holzwickede
 

Re: QMail-/Plesk-Verhalten bei 2. IP

Post by blacksavior »

Ich habe mir gerade überlegt, den Grund meines Vorhabens mal auszuformulieren. Vielleicht muss man ja nicht unbedingt den Weg über eine 2. IP gehen.

IST:
Der benannte 1und1 Server hat eine gewissen Anzahl an Hostings. Jeweils inkl. mehrerer E-Mail-Konton, ftp, Datenbank und co. Alle Hostings laufen derzeit über ein und die selbe IP.

SOLL:
Nun muss bei einem der Hostings der Port 25 für alle Remotes gesperrt werden, mit Ausnahme von 3 Remote-IP Adressen. Dies darf die anderen Hostings nicht beeinträchtigen.

GRUND:
Per DNS wurde ein externer Spamfilter davorgeschaltet. Naja, Spamfilter ist etwas untertrieben. Die Mails werden durch ein kleines Rechenzentrum geschleußt und auf Spam und Viren untersucht. Jedoch mit einer Trefferquote jenseits von gut und böse. Der Laden beschäftigt sich nur mit Spam und Viren und hat dafür über 100 Festangestellte beschäftigt. - Aber ich schweife ab.

Also: Der mx-Eintrag der Domains des Hostings zielt nun auf die IP des externen Dienstleisters. Der Scannt die Mails bevor sie unseren Server erreichen und leitet sie dann an den A-Eintrag mail.domain.tld weiter. Leider nutzen etliche Spamengines direkt die IP-Adresse und nicht den Weg über den mx-EIntrag. Fazit: Der Port 25 muss für diese Domains gesperrt werden. Da wir hier von tausenden Spammails reden muss dies am besten schon vor unserem Server geschehen (zB 1und1 Firewall).

Frage: Ist der Weg über die 2. IP der richtige Ansatz?

Gruß BlackSavior
Roger Wilco
Posts: 5923
Joined: 2004-05-23 12:53
 

Re: QMail-/Plesk-Verhalten bei 2. IP

Post by Roger Wilco »

blacksavior wrote:Frage: Ist der Weg über die 2. IP der richtige Ansatz?
Ja.
oxygen
Posts: 2138
Joined: 2002-12-15 00:10
Location: Bergheim
 

Re: QMail-/Plesk-Verhalten bei 2. IP

Post by oxygen »

Roger Wilco wrote:
blacksavior wrote:Frage: Ist der Weg über die 2. IP der richtige Ansatz?
Ja.
Find ich nicht. Wenn der externe Dienstleister so viel Aufwand betreibt, kann er authentifiziert einliefern. Ersatzweise auf einen anderen Port.
blacksavior
Posts: 59
Joined: 2003-09-02 14:38
Location: Holzwickede
 

Re: QMail-/Plesk-Verhalten bei 2. IP

Post by blacksavior »

Danke für die Beiträge!
Ein anderer Port stellt mich wieder vor ein ähnliches Problem: Wie den Port für nur ein Hosting umlegen. Der Port 25 MUSS für die anderen Hostings bestehen bleiben. Es geht halt nur um ein Hosting unter "vielen".
oxygen
Posts: 2138
Joined: 2002-12-15 00:10
Location: Bergheim
 

Re: QMail-/Plesk-Verhalten bei 2. IP

Post by oxygen »

blacksavior wrote:Danke für die Beiträge!
Ein anderer Port stellt mich wieder vor ein ähnliches Problem: Wie den Port für nur ein Hosting umlegen. Der Port 25 MUSS für die anderen Hostings bestehen bleiben. Es geht halt nur um ein Hosting unter "vielen".
Das ist schon klar. Ich kenne mich zugegebenermaßen nicht wirklich mit QMail aus, aber bei postfix ist es z.b. leicht möglich eine 2. Instanz auf einem 2. Port laufen zu lassen, die dann z.B. für jene Domains emails akzeptiert, während die Hauptinstanz auf Port 25 das nicht tut. So spart man sich eine 2. IP. Über Authentifizierung wäre eine entsprechende Aufteilung auch möglich, aber komplizierter.
Post Reply