mexx
Goto Top

Mail Senden über Telnet

Hallo,

ich betreibe einen eigenen Mailserver hinter einer festen IP. Wenn ich per Client wie Thunderbird oder emClient den Mailserver nutzen möchte, um einen Mail zu senden, geht dies nicht ohne Zugangsdaten. Also vollkommen korrektes Verhalten.

Nun verbinde ich mich per Telnet auf den Port 25 und versuche einen Mail zu senden und das ohne jegliche Zugangsdaten eingeben zu müssen und es funktioniert. Warum ist das so? Mir fehlt an der Stelle Grundsatzwissen. Handelt es sich dabei um ein richtige Verhalten zum Testen oder um eine Sicherheitslücke?

Danke für die Info,
mexx

Content-ID: 235613

Url: https://administrator.de/contentid/235613

Ausgedruckt am: 22.11.2024 um 13:11 Uhr

aqui
aqui 15.04.2014 aktualisiert um 16:35:44 Uhr
Goto Top
geht dies nicht ohne Zugangsdaten
Das kommt weil solche Clients immer POP (oder IMAP) before SMTP machen. Der reine Mail Versand per SMTP geschieht bekanntermaßen ohne User und Passwörter.
Wäre ja auch Unsinn, denn dann müsste dein Mailserver sämtliche Passwörter aller weltweit existierenden Mailserver kennen. Du siehst selber das das Unsinn ist... Siehe auch..
http://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
Lochkartenstanzer
Lösung Lochkartenstanzer 15.04.2014, aktualisiert am 25.04.2014 um 11:56:04 Uhr
Goto Top
Vermutlich weil Du kein SMTP-Auth forderst. face-smile

lks

PS. Einfach mal die RFC's zu diesem Thema lesen. Hilft ungemein beim Verständnis.
sigkill
Lösung sigkill 15.04.2014, aktualisiert am 25.04.2014 um 11:55:49 Uhr
Goto Top
Wohin versuchst du auf dem Mailserver eine Mail zu senden? Lokal oder an einen entfernten Empfänger? Und von wo loggst du dich per telnet ein?
Auf welchem Port verbinden sich die Mail-Clients? Auch 25?

Prinzipiell muss dein Mailserver natürlich ohne Authentifizierung Mails annehmen, sonst könnte er ja auch keine Mails von anderen Server ausliefern. Ganz früher, in der guten alten Zeit, also bevor es SPAM gab, hat jeder Mailserver ohne Authentifizierung alle Mails angenommen und verarbeitet. Das haben natürlich Spammer gnadenlos ausgenutzt. Sowas nennt sich heute "offenes Relay" und wird von vielen anderen Mailservern geblockt. Daher nehmen richtig konfigurierte Mailserver nur noch Mails von anderen, passenden Mailservern (und evtl. von localhost) an. Dazu wird z.B. die Absenderadresse und der zugehörige MX-Record geprüft etc...

Einfacher Test: Verbinde dich (Ohne vorher(30min-1h) Mails abzurufen!) von einer entfernten Maschine per Telnet und versuche eine Mail an eine z.B. gmx-Adresse zu senden mit Absender z.B. irgendwas@web.de

Funktioniert das ist dein Mailserver definitiv falsch konfiguriert. Funktiniert das nicht, kann dein Mailserver immer noch falsch konfiguriert sein, aber wenigstens nicht ganz so hoffnungslos falsch ;)

Da ich nicht weiss, welchen Du verwendest, kann ich dir da nicht weiterhelfen.

Prinzipiell gilt: Port 25 ist für die Kommunikation von Mailservern untereinander. Hier geschieht die Authentifizierung über IP-Adresse in Verbindung mit MAIL FROM und RCPT TO Angaben und dem MX-Record im DNS. Noch ab und an üblich, aber nicht mehr Zeitgemäß ist eine Verbindung der Clients mit "POP before SMTP" ... Damit identifiziert sich die IP per Mailabruf(POP/IMAP) und diese IP wird dann für einen definierten Zeitraum als berechtigt gespeichert und darf Mails ohne nochmalige Authentifizierung über Port 25 versenden. Wie gesagt, das ist veraltet, wird manchmal noch verwendet, manchmal aus Faulheit(don't touch a running system), manchmal weil irgendeine antike Software kein SMTP mit Authentifizierung beherrscht.

Für Mail-Clients sollte Port 587("Message Submission") verwendet werden - inklusive "normaler" Authentifizierung per Username/Passwort.... Ab und an hört man auch noch Port 465 für SSL-verschlüsselung(SMTPS). Das ist aber auch veraltet.
mexx
mexx 15.04.2014 um 20:56:29 Uhr
Goto Top
Großes danke schön an die guten Antworten. Jetzt habe ich erstmal einiges zu lesen und ich werde mich um eine extern stehende testumgebung bemühen und die Tests machen. Ostern finde ich zeit dafür. Wäre schön, wenn ihr den Beitrag als beobachtet markiert, damit ihr eine Mitteilung bekommt, wenn ich Ergebnisse und fragen habe.

Danke danke,
Mexx
sigkill
Lösung sigkill 16.04.2014, aktualisiert am 25.04.2014 um 11:55:46 Uhr
Goto Top
Hier noch was zusammengefasst zum Lesen und Testen:
http://wiki.hetzner.de/index.php/Mailserver_Relaytest
mexx
mexx 25.04.2014 um 11:55:41 Uhr
Goto Top
Hallo Leute,

nach Durchlesen der Artikel, im speziellen den http://wiki.hetzner.de/index.php/Mailserver_Relaytest, habe ich die Konfiguration des Mailservers um die Einträge...

SMTP AUTH verwenden
smtpd_sasl_auth_enable = yes
pwcheck_method = saslauthd
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

...erweitert. Wie im Artikel beschrieben, verweigert der Mailserver nun das Relay.

Vielen Dank für die Hilfe,
mexx
sigkill
sigkill 25.04.2014 um 13:01:06 Uhr
Goto Top
Bitteschön, gern geschehen face-smile

Wenn der Mailserver ein offenes Relay war ist es nun wichtig, die Anti-spam-Datenbanken zu prüfen.... wie in dem Wiki-Artikel unten auch angedeutet wird.
Dazu auf http://www.dnsstuff.com/tools unter "Email Tools" die IP bei "Spam Blacklist Lookup" eintragen und die Anti-spam-Datenbanken checken. Ist der Mailserver irgendwo eingetragen, dem entsprechenden Link folgen und um Löschung bitten.... Wenn nach einem Grund bzw. den Maßnahmen zur Beseitigung der Spamquelle gefragt wird, angeben dass man den Mailserver umkonfiguriert hat und nun kein Offenes Relay mehr hat.

Wenn das nicht passiert, kann es sein, das andere Mailserver bei deinen Mails die Annahme verweigern bzw. Mails von deinem Server grundsätzlich als SPAM markieren oder ähnlich unangenehme Sachen....

Was jetzt noch passieren kann, ist dass zu viel Spam ankommt. Gefälschte Absendeadressen, Spezielle zum direkten Spamversand konfigurierte Server, andere offene Relays und so weiter und so fort. Aber das betrifft dann nun nur noch dich und deine User.
Wenn Du jetzt noch Probleme mit viel Spam hast, kannst du den Server versuchen noch dichter zu machen. Stichworte dazu sind "Sender Policy Framework", Greylisting, Blacklists, dynamische IP-Bereiche sperren etc. pp.... Aber dabei besteht natürlich auch die Gefahr des Fehlkonfigurierens, das würde ich nur machen, wenn sich die User über zuviel Spam beschweren und ich genau weis was ich da tue.