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?
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.
Ich bin root - ich darf das.
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?
Gibt da zig Möglichkeiten. Greylisting, Spamcheck, DNSBL usw usf. Die Doku von Postfix ist da sehr gesprächig.
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
Geändert von fork (20.03.18 um 08:03 Uhr)
"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.
Zwischen anonym sein wollen und seine Daten nicht verkaufen wollen, liegen zwei Welten. Wenn man sich einen kostenpflichtigen Dienst sucht, dann meist, weil man für diese Dienstleistung zahlt und nicht selbst das Produkt sein will.
Ich gehe davon aus, dass der TO telnet als smtp Client genutzt hat aber sich unglücklich ausgedrückt hat.Zitat von Huhn Hur Tu
was soll daran unglücklich augedrückt sein?
Völlig normale Vorgehensweise.
Ich bin root - ich darf das.
Ja. Mache ich auch so. Alternativ mache ich das für den Test für SSL-Verbindungen zum Mailserver mittels......telnet...Völlig normale Vorgehensweise.
...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.Code:openssl s_client -quiet -connect mein.mailserver.de:25 -starttls smtp -CApath /etc/ssl/certs
---
... oder verwende für einen Schnelltest meist mxtoolbox.com
Geändert von fork (20.03.18 um 10:07 Uhr)
Die Vorgehensweise ist ja ok, aber unglücklich ausgedrückt:
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.
Naja, SMTP == TELNET == DO NOT USE IT - Email ist doch eh sowas von broken.
Gruß nopes
(,,,)---(^.^)---(,,,) /var/log/messages | grep cat
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!
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
Berechtigungen
Zitieren
Lesezeichen