PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Postfix richtig konfigurieren



saphear
19.03.18, 16:22
Moin zusammen,
ich habe unter einem vServer bei einem größeren Anbieter eine - ich nenne es einfach mal so - "Standard"-Konfiguration von Postfix laufen. D.h. mit Plesk installiert und konfiguriert. An sich klappt da auch alles, aber in einem Punkt bin ich misstrauisch:
Ich kann mich via Telnet beim Server anmelden und darf Mails an lokale Adressen zustellen, sofern ich bei "RCPT TO:" irgendwas eintrage, was eben lokal existiert. Das finde ich aber Käse - eine info@ oder kontakt@ oder sowas existiert ja bei sehr vielen deutschen Domains.

Wie kann man sowas unterbinden bzw. ist es für den "normalen" Transportweg von anderen SMTP-Servern erwünscht, dass das so funktioniert?

marce
19.03.18, 16:49
Was willst Du denn sonst bei "RCPT TO:" eintragen wenn nicht die Empfänger-Adresse? Wenn Du keine Mails annehmen willst - dann solltest Du keinen empfangenden Mailserver laufen lassen.

Ob das Konstrukt bei Dir "per se" ein Problem hast kannst Du über div. Online-Testtools herausfinden.

saphear
20.03.18, 08:25
Hallo, danke für deine Antwort. Natürlich muss ich eine lokal vorhandene Mailadresse bei RCPT TO eintragen, das ist schon klar. Mir geht es nur darum, wie leicht die MAIL FROM: hier manipuliert werden kann. Kann ich meinem Server nicht beibringen, hier von anderen Mailservern irgendeine bessere Authentifizierung zu verlangen? Kein User-Login, das ist schon klar. Aber gibt es da nicht noch andere Möglichkeiten?

DrunkenFreak
20.03.18, 08:29
Gibt da zig Möglichkeiten. Greylisting, Spamcheck, DNSBL usw usf. Die Doku von Postfix ist da sehr gesprächig.

fork
20.03.18, 08:59
Das prüfen von SPF ist ein wirksamer Schutz gegen Fälschung der Absenderadresse.
Ebenso die Validierung von DKIM-Signaturen.

Das sind Absicherungen die andere getroffen haben und die Du nur überprüfen musst, und bei Verstoss dagegen die Mail guten Gewissens ablehnen kannst.

https://de.wikipedia.org/wiki/Sender_Policy_Framework
https://de.wikipedia.org/wiki/DomainKeys

Huhn Hur Tu
20.03.18, 09:23
"TELNET" !?! Ich hoffe nicht aus dem Netz.
telnet gehoert seit 15 Jahren als Service getoetet, der client ist ja noch zum Service testen gut, wenn man kein netcat mag.

Dukel
20.03.18, 09:29
"TELNET" !?! Ich hoffe nicht aus dem Netz.
telnet gehoert seit 15 Jahren als Service getoetet, der client ist ja noch zum Service testen gut, wenn man kein netcat mag.

Ich gehe davon aus, dass der TO telnet als smtp Client genutzt hat aber sich unglücklich ausgedrückt hat.

marce
20.03.18, 09:34
Ich kann mich via Telnet beim Server anmelden
was soll daran unglücklich augedrückt sein?

Völlig normale Vorgehensweise.

fork
20.03.18, 11:02
...telnet...Völlig normale Vorgehensweise.

Ja. Mache ich auch so. Alternativ mache ich das für den Test für SSL-Verbindungen zum Mailserver mittels...



openssl s_client -quiet -connect mein.mailserver.de:25 -starttls smtp -CApath /etc/ssl/certs


...wobei anzumerken ist, dass das der Buchstabe "R" eine SSL-Verbindungsneuaushandlung von openssl auslöst und man deswegen den Befehl "RCPT TO" nicht eingeben kann. Der Workaround dafür ist, ein kleines "r" zu schreiben, was auch akzeptiert wird.

---
... oder verwende für einen Schnelltest meist mxtoolbox.com

Dukel
20.03.18, 12:26
was soll daran unglücklich augedrückt sein?

Völlig normale Vorgehensweise.

Die Vorgehensweise ist ja ok, aber unglücklich ausgedrückt:



Ich kann mich via Telnet beim Server anmelden...

Du meldest dich nicht mit Telnet an, sondern nutzt Telnet als Netzwerk / SMTP Client!
Mit Anmelden kann sowohl SMTP als auch das Protokoll Telnet gemeint sein.

nopes
20.03.18, 12:50
Naja, SMTP == TELNET == DO NOT USE IT - Email ist doch eh sowas von broken.

saphear
23.03.18, 08:34
Ja, ich meinte telnet als Mailclient ;)
Ich werde mich mal der Vorschläge von fork und DrunkenFreak annehmen und schauen, welche Anpassungen ich hier vornehme, danke für die Tipps!

fork
23.03.18, 09:39
Zum Thema SPF:

Ich vertrete da die Meinung, dass man den eher etwas "weniger restriktiv" konfigurieren sollte.

D. h. wenn man mehrere IP-Adressen hat, dann erlaube ich grundätzlich eher allen dieser IP-Adressen den Versand um im Fall des Falles(z. B.: Eine IP ist geblacklistet) schnell die IP-Adresse wechseln zu können, ohne dass über seinen eigenen SPF-Record stolpert, der dann verhindert, dass die Mails vom eigenen Server nicht mehr angenommen werden.

Mit "weniger restriktiv" meine ich jedoch nicht, dass man ~all verwendet, aka "softfail" was lt. RFC 7208 bedeutet, dass eine Mail nicht alleine aufgrund eines solchen Kriteriums abgelehnt werden sollte. IMHO will man aber genau das: Wenn eine Maileinlieferung gegen den SPF-Record verstösst, dann möchte man dass die Mail sofort abgelehnt wird. Das erreicht man mit -all.

Siehe
https://tools.ietf.org/html/rfc7208