Postfix auf Linux System zum Laufen bekommen

[Karl Heinz]

Hallo,

aus Interesse habe ich mal einen Postfix in meinem Linux Mint System installiert.

In folgender Anleitung:

https://wiki.ubuntuusers.de/Postfix/

steht u.a. folgendes:

Wenn der SMTP-Server auf dem Smarthost zum Versenden der Mail ein Passwort verlangt, muss die eben erstellte Konfiguration /etc/postfix/main.cf allerdings noch einmal editiert und diese Zeilen eingefügt werden:

Ich habe hier keine Ahnung welches Passwort hiermit gemeint ist. Das Passwort bezieht sich doch immer auf eine konkrete E-Mail die beim Smarthost eingerichtet wurde, sprich ich müsste doch eigentlich neben dem Passwort auch die E-Mail angeben welche der Smarthost nutzt um die vom Postfix versendete E-Mail weiterzuleiten? Wie diese E-Mail festgelegt werden kann wird aber nirgends erklärt.

Exemplarisch wie folgt:

• Postfix auf Linux Mint verschickt E-Mail an Empfänger
• Für das Weiterleiten an den Empfänger der E-Mail wird ein Smarthost genutzt
• Ich nutze eine beliebige E-Mail auf dem Smarthost mit dessen Hilfe die E-Mail zum Empfänger weitergeleitet wird. Dafür muss ich dem Postfix die E-Mail und das Passwort des Smarthoast mitteilen. Oben in der Erklärung wird aber nur gesagt wie ich das Passwort über /etc/postfix/main.cf festlege, nicht aber wie ich die gewünschte E-Mail des Smarthosts festlegte über welche die E-Mail an den Empfänger weitergeleitet wird.

[Der Martin]

Hi,

Wenn der SMTP-Server auf dem Smarthost zum Versenden der Mail ein Passwort verlangt, muss die eben erstellte Konfiguration /etc/postfix/main.cf allerdings noch einmal editiert und diese Zeilen eingefügt werden:

Ich habe hier keine Ahnung welches Passwort hiermit gemeint ist.

das Passwort, das du zur Anmeldung am SMTP-Server deines e-Mail-Anbieters benutzt.

Das Passwort bezieht sich doch immer auf eine konkrete E-Mail die beim Smarthost eingerichtet wurde, sprich ich müsste doch eigentlich neben dem Passwort auch die E-Mail angeben welche der Smarthost nutzt um die vom Postfix versendete E-Mail weiterzuleiten? Wie diese E-Mail festgelegt werden kann wird aber nirgends erklärt.

Vier Parameter sind nötig:

• der Hostname des externen SMTP-Servers (SMTP Relay Host)
• Der Benutzername zum Anmelden am SMTP-Server
• Das Passwort zum Anmelden am SMTP-Server
• Die e-Mail-Adresse, die als Absender für ausgehende Mails eingetragen werden soll

Die ersten drei Angaben stehen in /etc/postfix/sasl_password, die letzte in /etc/postfix/sender_canonical (siehe Abschnitt Korrekten Absender setzen).

Exemplarisch wie folgt:

• Postfix auf Linux Mint verschickt E-Mail an Empfänger
• Für das Weiterleiten an den Empfänger der E-Mail wird ein Smarthost genutzt
• Ich nutze eine beliebige E-Mail auf dem Smarthost mit dessen Hilfe die E-Mail zum Empfänger weitergeleitet wird. Dafür muss ich dem Postfix die E-Mail und das Passwort des Smarthoast mitteilen. Oben in der Erklärung wird aber nur gesagt wie ich das Passwort über /etc/postfix/main.cf festlege, nicht aber wie ich die gewünschte E-Mail des Smarthosts festlegte über welche die E-Mail an den Empfänger weitergeleitet wird.

Dann lies nochmal genau nach. Zugegeben, der Beschreibungstext im Ubuntu-Wiki ist etwas oberflächlich, die wichtigen Kniffe erkennt man teils erst, wenn man sich die Beispieleinträge für die Config-Dateien genau anschaut. Dann erkennt man auch, dass in /etc/postfix/sasl_password eben nicht, wie im Text erklärt, nur das Passwort steht, sondern auch der Hostname und der zum Passwort gehörende Benutzername.

So long,
 Martin

[Karl Heinz]

Vier Parameter sind nötig:

• der Hostname des externen SMTP-Servers (SMTP Relay Host)
• Der Benutzername zum Anmelden am SMTP-Server
• Das Passwort zum Anmelden am SMTP-Server
• Die e-Mail-Adresse, die als Absender für ausgehende Mails eingetragen werden soll

Hallo Martin,

danke für Deine Hilfe.

Ich habe jetzt alle vier Parameter genau nach Anleitung festgelegt. Anschließend über folgende Zeile eine Testnachricht verschickt:

mail -s "testbetreff" [e-mail] < testmailtext.txt

Die Empfängeradresse habe ich natürlich durch eine echte Mail ersetzt. Im Terminal erhalte ich keine Fehlermeldung. Die Test E-Mail kommt leider nicht beim Empfänger an.

Die Logdatei /var/log/mail.log zeigt mir folgendes:

> Oct  7 13:54:22 Desktop-Robert postfix/pickup[9995]: 390C32E3403: uid=1000 from=<robert>
> Oct  7 13:54:22 Desktop-Robert postfix/cleanup[10098]: 390C32E3403: message-id=<20161007115422.390C32E3403@Desktop-Robert>
> Oct  7 13:54:22 Desktop-Robert postfix/qmgr[9996]: 390C32E3403: from=<[e-mail]>, size=322, nrcpt=1 (queue active)
> Oct  7 13:54:22 Desktop-Robert postfix/smtp[10100]: warning: SASL authentication failure: No worthy mechs found
> Oct  7 13:54:22 Desktop-Robert postfix/smtp[10100]: 390C32E3403: to=<[e-mail]>, relay=xxx.kasserver.com[85.13.152.83]:25, delay=0.4, delays=0.01/0.01/0.38/0, dsn=4.7.0, status=deferred (SASL authentication failed; cannot authenticate to server w00a53e4.kasserver.com[85.13.152.83]: no mechanism available)

Es scheint wohl irgendwas mit der SASL authentication nicht zu stimmten. Weißt du hier Rat?

Dann noch eine andere Frage zu folgendem Abschnitt aus der Ubuntu Anleitung zu Postfix:

Im Prinzip könnte man den Postfix-Server aufsetzen und gleich E-Mails verschicken. Doch leider ist das im Zeitalter von Spam nicht mehr so einfach. Ein SMTP-Server ohne eine feste IP-Adresse und ohne ordentliche Zertifikate wäre eine ideale Spam-Schleuder. Deshalb akzeptiert eigentlich kein E-Mail-Server E-Mails von solchen Servern. Man muss daher die eigenen E-Mails über einen "ordentlichen" SMTP-Server (Smarthost), wie z.B. den von web.de und Co., leiten.

Wenn man die eigenen E-Mails über einen Smarthost leiten muss, dann könnte man doch eigentlich auf den Postfix verzichten. Aus welchem Grund sollte man zusätzlich einen Postfix installieren, wenn man doch bereits alle Funktionalitäten direkt beim Smarthost zur Verfügung gestellt bekommt? Warum mit zwei MTAs arbeiten, wenn es auch mit einem (dem Smarthost MTA) funktioniert?

[Der Martin]

Hi,

Die Logdatei /var/log/mail.log zeigt mir folgendes:

> Oct  7 13:54:22 Desktop-Robert postfix/pickup[9995]: 390C32E3403: uid=1000 from=<robert>
> Oct  7 13:54:22 Desktop-Robert postfix/cleanup[10098]: 390C32E3403: message-id=<20161007115422.390C32E3403@Desktop-Robert>
> Oct  7 13:54:22 Desktop-Robert postfix/qmgr[9996]: 390C32E3403: from=<[e-mail]>, size=322, nrcpt=1 (queue active)
> Oct  7 13:54:22 Desktop-Robert postfix/smtp[10100]: warning: SASL authentication failure: No worthy mechs found
> Oct  7 13:54:22 Desktop-Robert postfix/smtp[10100]: 390C32E3403: to=<[e-mail]>, relay=xxx.kasserver.com[85.13.152.83]:25, delay=0.4, delays=0.01/0.01/0.38/0, dsn=4.7.0, status=deferred (SASL authentication failed; cannot authenticate to server w00a53e4.kasserver.com[85.13.152.83]: no mechanism available)

Es scheint wohl irgendwas mit der SASL authentication nicht zu stimmten.

ja, sieht ganz so aus.

Weißt du hier Rat?

Leider nein, da bin ich auch überfragt. Aber du bist nicht der erste, der dieses Problem hat.

Wenn man die eigenen E-Mails über einen Smarthost leiten muss, dann könnte man doch eigentlich auf den Postfix verzichten.

Ja, und das tun auch viele Nutzer, die irgendeine Linux-Distro als Desktop-System einsetzen. Sie verwenden einen herkömmlichen Mailclient wie z.B. T-Bird und lassen den direkt mit dem externen SMTP- und POP3- oder IMAP-Server sprechen.

Aus welchem Grund sollte man zusätzlich einen Postfix installieren, wenn man doch bereits alle Funktionalitäten direkt beim Smarthost zur Verfügung gestellt bekommt? Warum mit zwei MTAs arbeiten, wenn es auch mit einem (dem Smarthost MTA) funktioniert?

Dafür gibt's mehrere Gründe.

Einer könnte sein, dass ein MTA auf localhost für Unixoide Systeme "etwas Normales" ist, und einige Programme z.B. Statusreports per e-Mail verschicken. Die erwarten dann dafür einen MTA mit der Standard-Schnittstelle, wie sie z.B. sendmail oder postfix bieten.
Würde man auf den lokalen MTA verzichten, müsste man sämtlichen Programmen, die sich per e-Mail melden wollen, die vorher erwähnten vier Parameter in der Konfig "einimpfen". Abgesehen davon, dass das viel redundanter Aufwand ist, sind die meisten Tools gar nicht dafür ausgelegt.

Ein anderer Grund könnte sein, dass man mehrere Rechner im LAN hat, die alle e-Mails verschicken und empfangen sollen, aber alle denselben Mail-Account verwenden. Dann richtet man auf einem Rechner im LAN einen MTA (z.B. postfix) und einen MDA (z.B. dovecot) ein, und alle Rechner im LAN verbinden sich nur noch mit dem, alle Mails im Netz laufen dann durch einen zentralen Knoten. So mach ich das beispielsweise, wobei ich bisher aus Bequemlichkeit auf den zentralen MTA verzichtet habe. Nur dovecot als LAN-interner IMAP-Server, bei dem sich alle Clients bedienen, und der mit fetchmail/procmail regelmäßig die neuen Mails "von draußen" abholt. Senden tun die Clients dann direkt über den externen SMTP, und legen dann eine Kopie im IMAP-Account ab.

So long,
 Martin

[Karl Heinz]

Noch eine Rückfrage zum Abschnitt:

Im Prinzip könnte man den Postfix-Server aufsetzen und gleich E-Mails verschicken. Doch leider ist das im Zeitalter von Spam nicht mehr so einfach. Ein SMTP-Server ohne eine feste IP-Adresse und ohne ordentliche Zertifikate wäre eine ideale Spam-Schleuder. Deshalb akzeptiert eigentlich kein E-Mail-Server E-Mails von solchen Servern. Man muss daher die eigenen E-Mails über einen "ordentlichen" SMTP-Server (Smarthost), wie z.B. den von web.de und Co., leiten.

Wie kann man denn bezogen auf einen Mail-Server herausfinden, ob dieser Mails direkt von einem Postfix Server (ohne den Umweg über einen Smarthost) akzeptiert?

[Der Martin]

Noch eine Rückfrage zum Abschnitt:

Im Prinzip könnte man den Postfix-Server aufsetzen und gleich E-Mails verschicken. Doch leider ist das im Zeitalter von Spam nicht mehr so einfach. Ein SMTP-Server ohne eine feste IP-Adresse und ohne ordentliche Zertifikate wäre eine ideale Spam-Schleuder. Deshalb akzeptiert eigentlich kein E-Mail-Server E-Mails von solchen Servern. Man muss daher die eigenen E-Mails über einen "ordentlichen" SMTP-Server (Smarthost), wie z.B. den von web.de und Co., leiten.

Wie kann man denn bezogen auf einen Mail-Server herausfinden, ob dieser Mails direkt von einem Postfix Server (ohne den Umweg über einen Smarthost) akzeptiert?

Ausprobieren. Die Erfolgschancen sind aber nahe Null, wie der obige Absatz auch schon andeutet.

So long,
 Martin

[Google weiß alles]

Wie kann man denn bezogen auf einen Mail-Server herausfinden, ob dieser Mails direkt von einem Postfix Server (ohne den Umweg über einen Smarthost) akzeptiert?

Ausprobieren. Die Erfolgschancen sind aber nahe Null, wie der obige Absatz auch schon andeutet.

##Variante 2a:## Den Admin fragen, ob er Blacklists prüft.

##Variante 2b:## Den Admin fragen, ob SPF-Einträge die Blocklist-Einträge überschreiben. Das wird aber nur in wenigen Ausnahme so sein.

##Denkmal:## Gehe mal davon aus, dass Du nicht jeden Admin jedes empfangenden Mailservers fragen kannst. Ausnahme wäre wenn es prinzipbedingt nur einen Empfänger bzw. nur eine Empfängerdomain gibt.

##Smarthost:##

Du brauchst zwar für den Smarthost einen Benutzername und ein Passwort - kannst aber in der Regel (bei brauchbaren Hostern) Mails mit mindestens im Userteil abweichenden Absender versenden. (Bei Massenhostern also mit gleicher Domain)

[Karl Heinz]

Wie kann man denn bezogen auf einen Mail-Server herausfinden, ob dieser Mails direkt von einem Postfix Server (ohne den Umweg über einen Smarthost) akzeptiert?

Ausprobieren. Die Erfolgschancen sind aber nahe Null, wie der obige Absatz auch schon andeutet.

Angenommen ich möchte eine E-Mail mit der Absenderadresse [e-mail] an eine @gmx.de Adresse über meinen Postfix verschicken.

Vermutlich wird der Mailserver von GMX die E-Mail nicht weiterleiten, da kein Smarthost (in diesem Fall der Smarthost Anbieter den der Bundestag nutzt) zwischengeschaltet ist.

Gehen wir einfach mal davon aus, der Mail-Server von GMX würde E-Mails auch dann akzeptieren, wenn diese nicht über einen Smarthost kommen, sondern direkt von meinem eigenen Postfix.

Gäbe es dann noch eine weitere Hürde um eine E-Mail mit dem Absender [e-mail] an eine @gmx Adresse zu verschicken, oder würde das Verschicken von [e-mail] an die GMX Adresse dann funktionieren?

In diesem Kontext hatte @woodfighter mal etwas geschrieben, was ich noch nicht so richtig verstanden habe. Hier der Link zum Beitrag:

https://forum.selfhtml.org/self/2016/jan/17/frage-zu-datensicherung-back-in-time/1659465#m1659465

Woodfigther schreibt etwas von SPF-Records. Hier verstehe ich den Zusammenhang nicht so richtig.

Angenommen ein Mail-Server akzeptiert nur Mails von Smarthosts, heißt das dann automatisch, dass der Mail-Server mit SPF-Recoders arbeitet?

bzw.

Angenommen ein Mail-Server akzeptiert Mails auch ohne Smarthost, z.B. direkt vom eigenen Postfix, heißt das dann automatisch, dass der Mail-Server ohne SPF-Records arbeitet?

[Der Martin]

Hallo,

Angenommen ich möchte eine E-Mail mit der Absenderadresse [e-mail] an eine @gmx.de Adresse über meinen Postfix verschicken.

Vermutlich wird der Mailserver von GMX die E-Mail nicht weiterleiten, da kein Smarthost (in diesem Fall der Smarthost Anbieter den der Bundestag nutzt) zwischengeschaltet ist.

vergiss mal für einen Moment den Begriff Smarthost. Du willst also (nein, willst du nicht, aber mal angenommen) von deinem Server aus eine e-Mail mit [e-mail] als Absender an ein GMX-Postfach schicken.
Wichtig ist zunächst mal, zwischen dem Mailserver des Absenders (hier also deine Maschine mit dem Postfix) und dem empfangenden Mailserver (hier GMX) zu unterscheiden. Deine Büchse wird eine solche Nachricht wohl klaglos annehmen und weiterreichen; notfalls musst du die Konfiguration so anpassen, dass es geht. Der GMX-Mailserver erkennt nun eine Absenderadresse mit dem Host bundestag.de, aber die Nachricht wird ihm von einem ganz anderen Host überreicht. Also prüft GMX anhand der SPF-Records von bundestag.de, ob dort eingetragen ist, dass deine Domain Mails im Namen von bundestag.de versenden darf. Wenn ja, nimmt er die Nachricht an; wenn nein, weist er sie ab.

Interessant ist in diesem Zusammenhang die Beobachtung von woodfighter, bundestag.de habe gar keine SPF-Einträge. Er schreibt, der GMX-Server würde deshalb die Mail ohne Murren annehmen; ich bin im Gegenteil der Meinung, dass er das aus eben diesem Grund nicht tun wird.

Gehen wir einfach mal davon aus, der Mail-Server von GMX würde E-Mails auch dann akzeptieren, wenn diese nicht über einen Smarthost kommen, sondern direkt von meinem eigenen Postfix.

Diese Annahme ist illusorisch.

Gäbe es dann noch eine weitere Hürde um eine E-Mail mit dem Absender [e-mail] an eine @gmx Adresse zu verschicken, oder würde das Verschicken von [e-mail] an die GMX Adresse dann funktionieren?

Dann würde es vermutlich hinhauen.

https://forum.selfhtml.org/self/2016/jan/17/frage-zu-datensicherung-back-in-time/1659465#m1659465

Woodfigther schreibt etwas von SPF-Records. Hier verstehe ich den Zusammenhang nicht so richtig.

Angenommen ein Mail-Server akzeptiert nur Mails von Smarthosts, heißt das dann automatisch, dass der Mail-Server mit SPF-Recoders arbeitet?

Nein, das sind zwei ganz verschiedene Paar Stiefel. Bei SPF geht es hauptsächlich darum, wer sich für jemand anderen ausgeben darf.

Angenommen ein Mail-Server akzeptiert Mails auch ohne Smarthost, z.B. direkt vom eigenen Postfix, heißt das dann automatisch, dass der Mail-Server ohne SPF-Records arbeitet?

Nicht automatisch, aber sehr wahrscheinlich.

So long,
 Martin

[Tagwächter]

Interessant ist in diesem Zusammenhang die Beobachtung von woodfighter, bundestag.de habe gar keine SPF-Einträge. Er schreibt, der GMX-Server würde deshalb die Mail ohne Murren annehmen; ich bin im Gegenteil der Meinung, dass er das aus eben diesem Grund nicht tun wird.

Nun ja. Ich habe mal in älteren Mail-Headern nachgeschaut:

mx.google.com; spf=neutral (google.com: 77.238.189.61 is neither permitted nor denied by best guess record for domain of [e-mail]) smtp.mail=[e-mail]; dkim=pass header.i=@yahoo.de

Google hat die Nachricht also angenommen weil kein SPF-Eintrag existierte und weil viele "Administratoren" nichts über SPF-Einträge im DNS wissen (wollen, denn im Gegensatz zu Google (gmail.com -> _spf.google.com -> _netblocks.google.com) auch Yahoo.de hat keine SPF-Einträge) wird das leider auch so bleiben obwohl das mit einem Texteditor auf Seiten der Empfängerserver leicht zu ändern wäre...

Freilich sagt das NICHTS darüber aus, wie GMX reagiert und ich will das jetzt nicht probieren...

[Tagwächter]

auch Yahoo.de hat keine SPF-Einträge)

Hm. Nicht richtig hingeschaut. Ich korrigiere:

yahoo hat spf-Einträge. Erst wird zu "_spf.mail.yahoo.com" verwiesen und dann mit "v=spf1 ptr:yahoo.com ptr:yahoo.net ?all" letztendlich durch das Fragezeichen jeder Sender auf "neutral" gestellt, mithin erlaubt...

Da hätte Yahoo das auch gleich lassen können.

[Karl Heinz]

Also prüft GMX anhand der SPF-Records von bundestag.de, ob dort eingetragen ist, dass deine Domain Mails im Namen von bundestag.de versenden darf. Wenn ja, nimmt er die Nachricht an; wenn nein, weist er sie ab.

Kommt es überhaupt zur Überprüfung der SPF-Records? Eigentlich dürfte es doch gar nicht so weit kommen, da im Szenario ja kein Smarthost verwendet wird, sprich GMX sieht, dass es sich bei meinem Mailserver um keinen Smarthost handelt und lehnt deshalb eine weitere Bearbeitung bzw. Überprüfung ab und somit auch die Überprüfung der SPF-Records.

Interessant ist in diesem Zusammenhang die Beobachtung von woodfighter, bundestag.de habe gar keine SPF-Einträge.

Wie hat er das denn herausgefunden?

Er schreibt, der GMX-Server würde deshalb die Mail ohne Murren annehmen;

Und was ist mit dem nicht genutzten Smarthost? Weil der fehlt gibt es doch schon viel früher einen Fehler, sprich das System bricht schon lange bevor die SPF-Records überprüft werden eine weitere Verarbeitung ab?

ich bin im Gegenteil der Meinung, dass er das aus eben diesem Grund nicht tun wird.

Wie kommst du zu dieser Meinung?

[Google weiß alles]

Interessant ist in diesem Zusammenhang die Beobachtung von woodfighter, bundestag.de habe gar keine SPF-Einträge.

Wie hat er das denn herausgefunden?

nslookup -q=any 'bundestag.de'

nslookup.exe gibt es auch für das Windows-Terminal. Die Webseite baut die Antwort nur in einen HTML-Rahmen (und fummelt ein wenig am Text herum: Erkennung von Links, IP-Adressen und so). Und wurde allein in diesem Thread gefühlte 10x verlinkt...

Und da wir schon bei Links sind: SPF-Einträge kann man dank Scott Kitterman auch testen.

[Der Martin]

Hallo,

Also prüft GMX anhand der SPF-Records von bundestag.de, ob dort eingetragen ist, dass deine Domain Mails im Namen von bundestag.de versenden darf. Wenn ja, nimmt er die Nachricht an; wenn nein, weist er sie ab.

Kommt es überhaupt zur Überprüfung der SPF-Records? Eigentlich dürfte es doch gar nicht so weit kommen, da im Szenario ja kein Smarthost verwendet wird, sprich GMX sieht, dass es sich bei meinem Mailserver um keinen Smarthost handelt und lehnt deshalb eine weitere Bearbeitung bzw. Überprüfung ab und somit auch die Überprüfung der SPF-Records.

ja, gut beobachtet. Ich hatte jetzt nur hypothetisch konstruiert und angenommen, dass dein Mailserver an sich vom Empfänger (hier GMX) als vertrauenswürdig gilt. Tatsächlich hast du mit an Sicherheit grenzender Wahrscheinlichkeit recht: Der GMX-Server wird schon anhand der IP-Adresse feststellen, dass es sich um einen Zugang mit wechselnden IPs aus dem Pool irgendeines Providers handelt, z.B. einen DSL-Einwahlknoten der Telekom.

Interessant ist in diesem Zusammenhang die Beobachtung von woodfighter, bundestag.de habe gar keine SPF-Einträge.

Wie hat er das denn herausgefunden?

Durch eine DNS-Abfrage, nehme ich an. Zum Beispiel mit einem Tool wie dig.

ich bin im Gegenteil der Meinung, dass er das aus eben diesem Grund nicht tun wird.

Wie kommst du zu dieser Meinung?

Wenn ich ein seriöser Betreiber eines Mailservers bin, sollte ich bestrebt sein, SPAM nach besten Kräften zu vermeiden und vor allem zu vermeiden, dass irgendein Heini über meinen eigenen Mailserver SPAM verschickt.
Wenn ich also von einem Host namens example.org eine Mail angeliefert bekomme, deren Absender auf example.net lautet (also eine andere Domain), dann würde ich das nur akzeptieren, wenn ich per SPF-Eintrag von example.net die positive Bestätigung bekomme, dass example.org das darf. Das Fehlen eines entsprechenden SPF-Eintrags würde ich als FAIL-Kriterium werten, wenn die Absender-Domain nicht mit dem einliefernden Hostnamen zusammenpasst.
Wenn sie übereinstimmen, ist natürlich alles in Butter.

So long,
 Martin

[Karl Heinz]

Also prüft GMX anhand der SPF-Records von bundestag.de, ob dort eingetragen ist, dass deine Domain Mails im Namen von bundestag.de versenden darf. Wenn ja, nimmt er die Nachricht an; wenn nein, weist er sie ab.

Kommt es überhaupt zur Überprüfung der SPF-Records? Eigentlich dürfte es doch gar nicht so weit kommen, da im Szenario ja kein Smarthost verwendet wird, sprich GMX sieht, dass es sich bei meinem Mailserver um keinen Smarthost handelt und lehnt deshalb eine weitere Bearbeitung bzw. Überprüfung ab und somit auch die Überprüfung der SPF-Records.

ja, gut beobachtet. Ich hatte jetzt nur hypothetisch konstruiert und angenommen, dass dein Mailserver an sich vom Empfänger (hier GMX) als vertrauenswürdig gilt. Tatsächlich hast du mit an Sicherheit grenzender Wahrscheinlichkeit recht: Der GMX-Server wird schon anhand der IP-Adresse feststellen, dass es sich um einen Zugang mit wechselnden IPs aus dem Pool irgendeines Providers handelt, z.B. einen DSL-Einwahlknoten der Telekom.

Fazit:

Das Versenden von E-Mails nach draußen mit einer gefälschen Absenderadresse ist nicht möglich, weil das Versenden ja nur über einen Smarthost möglich ist. Bei diesem Smarthost muss man sich mit einer echten E-Mail Adresse, für welche man auch die Zugangsdaten besitzt, anmelden, über diese E-Mail werden die Nachrichten dann verschickt.

Hab mir mal den Wikipedia Beitrag zu SMTP angeschaut:

https://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

Aus folgendem Absatz resultiert eine Frage:

Da SMTP ein textbasiertes Protokoll ist, kann mittels Telnet-Client eine E-Mail auch „von Hand“ verschickt werden. Dabei sind, wie auch bei anderen Verfahren, Absender- und Empfängeradresse frei wählbar, und eine Authentifizierung findet nicht statt. Aus diesem Grund ist die Verlässlichkeit der Absenderangabe einer E-Mail nicht gegeben.

Dann schreiben die doch quatsch im Wikpedia-Artikel.

Die Absender-Adresse ist eben nicht frei wählbar, eine Authentifizierung über einen Smarthost (mit der Absender E-Mail Adresse) ist ist doch zwingend notwendig, damit eine E-Mail über den Postfix verschickt werden kann.

[Der Martin]

Hallo,

Das Versenden von E-Mails nach draußen mit einer gefälschen Absenderadresse ist nicht möglich, ...

so uneingeschränkt gilt das nicht; die unzähligen SPAM-Mails, die trotz aller Maßnahmen immer noch mit gefälschten Absenderadressen verschickt werden, zeigen deutlich, dass es möglich ist, weil keine Maßnahme wirklich perfekt ist.

https://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

Aus folgendem Absatz resultiert eine Frage:

Da SMTP ein textbasiertes Protokoll ist, kann mittels Telnet-Client eine E-Mail auch „von Hand“ verschickt werden. Dabei sind, wie auch bei anderen Verfahren, Absender- und Empfängeradresse frei wählbar, und eine Authentifizierung findet nicht statt. Aus diesem Grund ist die Verlässlichkeit der Absenderangabe einer E-Mail nicht gegeben.

Dann schreiben die doch quatsch im Wikpedia-Artikel.

Nein, das ist völlig korrekt. Der Artikel bezieht sich rein auf SMTP. Und das Protokoll SMTP selbst bietet tatsächlich keinerlei Schutz gegen Missbrauch. Das sind andere Techniken jenseits von SMTP (plus SMTP-AUTH als Erweiterung des ursprünglichen SMTP).

Die Absender-Adresse ist eben nicht frei wählbar

Nach der reinen SMTP-Spezifikation schon. Dass eine solche Mailnachricht dann aufgrund anderer Maßnahmen und Kriterien abgewiesen wird, ist nicht die Schuld von SMTP.

eine Authentifizierung über einen Smarthost (mit der Absender E-Mail Adresse) ist ist doch zwingend notwendig, damit eine E-Mail über den Postfix verschickt werden kann.

Nö. Nimm als Beispiel den Mailserver, den du als Teil deines Webhosting-Pakets benutzt. Der gilt, solange du kein Schindluder treibst, bei anderen als vertrauenswürdig, hat eine feste IP-Adresse, verwendet aber bestimmt kein SMTP-AUTH (aber der Provider wird sicher andere Maßnahmen gegen Missbrauch anwenden, z.B. dass der Mailserver nur Mails von localhost annimmt). Möglicherweise lässt der sich sogar beliebige Absenderadressen unterschieben (manche Provider schränken das ein). Wenn's dann auf der Empfängerseite durchgeht - Glück gehabt.

So long,
 Martin

[Karl Heinz]

Nö. Nimm als Beispiel den Mailserver, den du als Teil deines Webhosting-Pakets benutzt. Der gilt, solange du kein Schindluder treibst, bei anderen als vertrauenswürdig, hat eine feste IP-Adresse, verwendet aber bestimmt kein SMTP-AUTH (aber der Provider wird sicher andere Maßnahmen gegen Missbrauch anwenden, z.B. dass der Mailserver nur Mails von localhost annimmt). Möglicherweise lässt der sich sogar beliebige Absenderadressen unterschieben (manche Provider schränken das ein). Wenn's dann auf der Empfängerseite durchgeht - Glück gehabt.

Wie soll man eine beliebige Absender-Adresse unterschieben? Möchte ich eine E-Mail über den Provider versenden, so muss ich mich doch zunächst mit Login und Passwort der E-Mail-Adresse einloggen über die die E-Mail veschickt wird. Ohne Einloggen mit einer bestimmten E-Mail, die als Absender-Adresse verwendet werden soll, verschickt der Mail-Server doch keine Mail. Wie demnach eine Absender-Adresse unterschieben?

[Christian Kruse]

Hallo Karl,

Nö. Nimm als Beispiel den Mailserver, den du als Teil deines Webhosting-Pakets benutzt. Der gilt, solange du kein Schindluder treibst, bei anderen als vertrauenswürdig, hat eine feste IP-Adresse, verwendet aber bestimmt kein SMTP-AUTH (aber der Provider wird sicher andere Maßnahmen gegen Missbrauch anwenden, z.B. dass der Mailserver nur Mails von localhost annimmt). Möglicherweise lässt der sich sogar beliebige Absenderadressen unterschieben (manche Provider schränken das ein). Wenn's dann auf der Empfängerseite durchgeht - Glück gehabt.

Wie soll man eine beliebige Absender-Adresse unterschieben? Möchte ich eine E-Mail über den Provider versenden, so muss ich mich doch zunächst mit Login und Passwort der E-Mail-Adresse einloggen über die die E-Mail veschickt wird. Ohne Einloggen mit einer bestimmten E-Mail, die als Absender-Adresse verwendet werden soll, verschickt der Mail-Server doch keine Mail. Wie demnach eine Absender-Adresse unterschieben?

Der Login hat nichts mit dem Absender zu tun. Den Absender kannst du trotzdem frei wählen; der wird bei SMTP über MAIL FROM und den From-Header in der Mail selber bestimmt.

LG,
CK

[Karl Heinz]

Der Login hat nichts mit dem Absender zu tun. Den Absender kannst du trotzdem frei wählen; der wird bei SMTP über MAIL FROM und den From-Header in der Mail selber bestimmt.

Kurzum das Fälschen des Absenders ist so ohne weiteres möglich?

[Christian Kruse]

Hallo Karl,

Der Login hat nichts mit dem Absender zu tun. Den Absender kannst du trotzdem frei wählen; der wird bei SMTP über MAIL FROM und den From-Header in der Mail selber bestimmt.

Kurzum das Fälschen des Absenders ist so ohne weiteres möglich?

In der Mehrzahl der Fälle ja. Einschränkungen gibt es durch SPF, DKIM und ähnliche Methoden.

LG,
CK

[Karl Heinz]

Kurzum das Fälschen des Absenders ist so ohne weiteres möglich?

In der Mehrzahl der Fälle ja. Einschränkungen gibt es durch SPF, DKIM und ähnliche Methoden.

Das ist doch dann ein Wiederspruch, auf der einen Seite akzeptieren die Mail-Server nur E-Mails von Smarthosts (damit man keinen Absender fälschen kann), auf der anderen Seite beseitigt die Nutzung eines Smarthosts ja nicht die Problematik, dass E-Mails mit gefälschtem Absender verschickt werden können. Wenn der Smarthost sowieso keinen Nutzen hat (weil ich ja auch mit Smarthost den Absender fälschen kann), dann könnten die Mail-Server auch gleich E-Mails direkt von meinem Postfix annehmen und ausliefern?

[Christian Kruse]

Hallo Karl,

Das ist doch dann ein Wiederspruch, auf der einen Seite akzeptieren die Mail-Server nur E-Mails von Smarthosts (damit man keinen Absender fälschen kann),

Die Anbieter akzeptieren nur Mails von „Smart hosts,” weil in der Vergangenheit IPs aus dynamischen Pools gerne dazu verwendet wurden Spam zu verschicken. Etwa in Form von Windows-Zombies, Win95 und 98 z.B. waren ja geradezu berüchtigt dafür. Mit „Absender fälschen” hat das nichts zu tun.

Wenn der Smarthost sowieso keinen Nutzen hat (weil ich ja auch mit Smarthost den Absender fälschen kann), dann könnten die Mail-Server auch gleich E-Mails direkt von meinem Postfix annehmen und ausliefern?

Die Wahrscheinlichkeit, dass eine Mail von einer IP aus einem dynamischen Pool eine Spam-Mail ist, ist um Grössenordnungen höher als bei einer Mail von einem echten[tm] Server.

Und um das ganze noch komplizierter zu machen: die grossen Provider, etwa Google und Microsoft, akzeptieren auch nicht von jedem Server Mails. Die arbeiten mit einem sog. Reputation System: eine IP muss erst positiv auffallen, bevor Mails von ihr entgegen genommen werden.

Was das im Detail heisst frag mich bitte nicht, das ist ein Geschäftsgeheimnis und spekulieren darüber ist etwa so sinnvoll wie SEO.

LG,
CK

[Karl Heinz]

Das ist doch dann ein Wiederspruch, auf der einen Seite akzeptieren die Mail-Server nur E-Mails von Smarthosts (damit man keinen Absender fälschen kann),

Die Anbieter akzeptieren nur Mails von „Smart hosts,” weil in der Vergangenheit IPs aus dynamischen Pools gerne dazu verwendet wurden Spam zu verschicken. Etwa in Form von Windows-Zombies, Win95 und 98 z.B. waren ja geradezu berüchtigt dafür. Mit „Absender fälschen” hat das nichts zu tun.

Wenn ein Smarthost verwendet wird kann ich doch über diesen genauso Spam verschicken oder nicht?

[Christian Kruse]

Hallo Karl,

Das ist doch dann ein Wiederspruch, auf der einen Seite akzeptieren die Mail-Server nur E-Mails von Smarthosts (damit man keinen Absender fälschen kann),

Die Anbieter akzeptieren nur Mails von „Smart hosts,” weil in der Vergangenheit IPs aus dynamischen Pools gerne dazu verwendet wurden Spam zu verschicken. Etwa in Form von Windows-Zombies, Win95 und 98 z.B. waren ja geradezu berüchtigt dafür. Mit „Absender fälschen” hat das nichts zu tun.

Wenn ein Smarthost verwendet wird kann ich doch über diesen genauso Spam verschicken oder nicht?

Das ist komplizierter. Es geht um Wahrscheinlichkeiten.

Wenn ein Server mit fester IP Spam versendet, kann man kurzerhand die IP sperren und man hat ihn effektiv ausgeschaltet. Einen neuen Server oder VPS oder so zu mieten ist teuer und kostet Arbeitsaufwand und natürlich sind die Provider auch sehr daran interessiert, dass kein Spam aus ihrem RZ herausfällt.

Aber das gibt es natürlich auch. Und genau deshalb verwenden die Großen ja auch das Reputation-System.

LG,
CK

[Matthias Apsel]

Hallo Christian Kruse,

Und um das ganze noch komplizierter zu machen: die grossen Provider, etwa Google und Microsoft, akzeptieren auch nicht von jedem Server Mails. Die arbeiten mit einem sog. Reputation System: eine IP muss erst positiv auffallen, bevor Mails von ihr entgegen genommen werden.

Aber immerhin gibt es einen Hinweis, wenn die Mail nicht zugestellt wird.

Wie genau, ob per Mail oder ob TB das meldet, erinnere ich gerade nicht.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

Aber immerhin gibt es einen Hinweis, wenn die Mail nicht zugestellt wird.

Wie genau, ob per Mail oder ob TB das meldet, erinnere ich gerade nicht.

Das meldet dir der Mailserver, der deine Mail von Thunderbird entgegen nimmt, in Form einer Bounce-Mail.

LG,
CK

[Matthias Apsel]

Hallo Christian Kruse,

Das meldet dir der Mailserver, der deine Mail von Thunderbird entgegen nimmt, in Form einer Bounce-Mail.

Nö. Die sprechen sich vorher schon ab.

Warum ich allerdings die (gültige) Empfängermailadresse überprüfen soll, ist mir schleierhaft.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

Das meldet dir der Mailserver, der deine Mail von Thunderbird entgegen nimmt, in Form einer Bounce-Mail.

Nö. Die sprechen sich vorher schon ab.

Hm. Das wundert mich. Bist du sicher, dass du nicht über Googlemail.com auch verschickst?

Warum ich allerdings die (gültige) Empfängermailadresse überprüfen soll, ist mir schleierhaft.

Da wird wohl Fehlercode 521 geliefert worden sein.

LG,
CK

[Matthias Apsel]

Hallo Christian Kruse,

Nö. Die sprechen sich vorher schon ab.

Hm. Das wundert mich. Bist du sicher, dass du nicht über Googlemail.com auch verschickst?

Ja, mein Postausgangserver ist mx.freenet.de. Die Absenderadresse ist aber in dem Fall keine @freenet.de-Adresse.

Warum ich allerdings die (gültige) Empfängermailadresse überprüfen soll, ist mir schleierhaft.

Da wird wohl Fehlercode 521 geliefert worden sein.

"521 The message is too large. Else it could be a permissions problem. Check the recipient's mailbox."

Oder ein Berechtigungsproblem - nett.

Bis demnächst
Matthias

[Auge]

Hallo

Da wird wohl Fehlercode 521 geliefert worden sein.

"521 The message is too large. Else it could be a permissions problem. Check the recipient's mailbox."

Oder ein Berechtigungsproblem - nett.

Wird auch gerne von ehemaligen T-Online-Kunden genommen, die ihre zum ehemaligen Account gehörigen Emailadressen behalten. Zumindest war das früher ein Problem, weil die Anmeldung am Server als T-Online-Kunde mit dem Einwahlstring erfolgte, was nach einem Providerwechsel nicht mehr funktionierte. Ob das immer noch so gehandhabt wird, weiß ich allerdings nicht. Zumindest weist die Interpretation „Berechtigungsproblem“ mMn in die richtige Richtung. Die Fehlermeldung wird vermutlich nicht alle möglichen Ursachen berücksichtigen.

Tschö, Auge

[Matthias Apsel]

Hallo Auge,

"521 The message is too large. Else it could be a permissions problem. Check the recipient's mailbox."

Die Fehlermeldung wird vermutlich nicht alle möglichen Ursachen berücksichtigen.

Ich habe noch andere Quellen gefunden, im RFC heißt es lediglich: "Dieses Memo definiert einen neuen SMTP-Antwort-Code - 521, der genutzt werden kann, um anzuzeigen, dass ein Internet-Host keine eingehenden Mails akzeptiert."

Bis demnächst
Matthias

[Der Martin]

Hi,

Wie soll man eine beliebige Absender-Adresse unterschieben? Möchte ich eine E-Mail über den Provider versenden, so muss ich mich doch zunächst mit Login und Passwort der E-Mail-Adresse einloggen über die die E-Mail veschickt wird. Ohne Einloggen mit einer bestimmten E-Mail, die als Absender-Adresse verwendet werden soll, verschickt der Mail-Server doch keine Mail. Wie demnach eine Absender-Adresse unterschieben?

Der Login hat nichts mit dem Absender zu tun. Den Absender kannst du trotzdem frei wählen; der wird bei SMTP über MAIL FROM und den From-Header in der Mail selber bestimmt.

erstens das, und zweitens meinte ich den Versand von Mails durch ein auf dem Server laufendes Script, etwa PHP. Da rufe ich einfach mail() auf und kann für From: wieder eintragen, was ich will.

Nur dass, wie vorher schon erwähnt, einige Provider hier auch schon überwachend einschreiten. Bei meinem Webhoster darf ein Script beispielsweise nur eine Mailadresse als Absender angeben, die vorher im Web-Konfigurationstool anzugeben ist und zu einem existierenden Postfach gehören muss. Versuche ich, Mails mit einer anderen Absenderadresse zu verschicken, habe ich Pech.

Ciao,
 Martin

[Karl Heinz]

Hi,

Wie soll man eine beliebige Absender-Adresse unterschieben? Möchte ich eine E-Mail über den Provider versenden, so muss ich mich doch zunächst mit Login und Passwort der E-Mail-Adresse einloggen über die die E-Mail veschickt wird. Ohne Einloggen mit einer bestimmten E-Mail, die als Absender-Adresse verwendet werden soll, verschickt der Mail-Server doch keine Mail. Wie demnach eine Absender-Adresse unterschieben?

Der Login hat nichts mit dem Absender zu tun. Den Absender kannst du trotzdem frei wählen; der wird bei SMTP über MAIL FROM und den From-Header in der Mail selber bestimmt.

erstens das, und zweitens meinte ich den Versand von Mails durch ein auf dem Server laufendes Script, etwa PHP. Da rufe ich einfach mail() auf und kann für From: wieder eintragen, was ich will.

Aus Neugierde möchte ich das Versenden einer E-Mail über einen gefälschten Absender testen.

Ich habe es zunächst über meinen Hoster www.allinkl.com probiert.

In die Datei /etc/postfix/sender_canonical habe ich den gewünschten gefälschten Absender gepackt.

Allinkl akzeptiert die gefälschte Absender Adresse nicht mit der Begründung, dass die Absender Adresse nicht zu dem Login passt, den ich über /etc/postfix/sasl_password festegelegt habe.

Wenn ich das richtig verstanden habe, gibt es Hoster, bei welchen die Absender Adresse, die in /etc/postfix/sender_canonical hinterlegt wird nicht dem Login passen müssen der über /etc/postfix/sasl_password festgelegt wurde? Ist das so korrekt?

So wie ich das sehe kann die in /etc/postfix/sender_canonical hinterlegte Adresse gefälscht sein, wenn man als Hoster z.b. Arcor verwendet.

In der Postfix Anleitung steht nämlich folgendes:

Arcor-Internet-Kunden können über ihren eigenen Internetzugang ohne weitere Authentifizierung E-Mails mit beliebigem Absender versenden, sofern dieser eine gültige E-Mail-Adresse darstellt.

Heißt das mit Arcor sollte das Verschicken mit einer gefälschten Absenderadresse, die ich in /etc/postfix/sender_canonical eintrage, funktionieren?

Wisst Ihr wie das bei 1&1 ist, darf man da eine abweichende E-Mail in /etc/postfix/sender_canonical verwenden? Finde leider nirgends eine Info dazu.

Aus versehen habe ich die Datei /var/log/mail.log gelöscht. Habe Sie jetzt wieder händisch angelegt. Jetzt wird die Log-Datei aber nichtmehr mit Infos befüllt. Könnt Ihr mir sagen, woran das liegt?

[Tagwächter]

Aus versehen habe ich die Datei /var/log/mail.log gelöscht. Habe Sie jetzt wieder händisch angelegt. Jetzt wird die Log-Datei aber nichtmehr mit Infos befüllt. Könnt Ihr mir sagen, woran das liegt?

An den Rechten.

sudo chown syslog:adm /var/log/mail.log
sudo chmod 640 /var/log/mail.log

sollte das beheben. Oder Du löschst Deine Datei und lässt das System einfach mal machen. Ist die Datei /var/log/mail.log nicht da wird diese nämlich angelegt.

Falls die bei mir gesehene Nutzer bzw. Rechte mit Deinem System nicht übereinstimmen sollte z.B. /etc/logrotate bzw. die Dateien in /etc/logrotate.d/ Auskunft geben.

[Der Martin]

Moin,

Aus Neugierde möchte ich das Versenden einer E-Mail über einen gefälschten Absender testen.

dann lass das bitte nicht zur Gewohnheit werden. ;-)

Ich habe es zunächst über meinen Hoster www.allinkl.com probiert.

In die Datei /etc/postfix/sender_canonical habe ich den gewünschten gefälschten Absender gepackt.

Allinkl akzeptiert die gefälschte Absender Adresse nicht mit der Begründung, dass die Absender Adresse nicht zu dem Login passt, den ich über /etc/postfix/sasl_password festegelegt habe.

Das hätte ich erwartet.

Wenn ich das richtig verstanden habe, gibt es Hoster, bei welchen die Absender Adresse, die in /etc/postfix/sender_canonical hinterlegt wird nicht dem Login passen müssen der über /etc/postfix/sasl_password festgelegt wurde? Ist das so korrekt?

Jein. Die Essenz des Satzes ist wohl richtig, aber das hat nichts mit postfix und dessen Config-Dateien zu tun; dem Mailserver bei all-inkl.com ist es egal, woher diese Daten stammen. Er sieht nur den Anmeldenamen, der über SMTP-AUTH übergeben wird, und die Absenderadresse, die im SMTP-Dialog per MAIL FROM: genannt wird. Und offensichtlich überprüft er anhand seiner eigenen Konfiguration, ob die beiden zusammenpassen.

Arcor-Internet-Kunden können über ihren eigenen Internetzugang ohne weitere Authentifizierung E-Mails mit beliebigem Absender versenden, sofern dieser eine gültige E-Mail-Adresse darstellt.

Das habe ich vor Jahren sogar selber mal genutzt

Heißt das mit Arcor sollte das Verschicken mit einer gefälschten Absenderadresse, die ich in /etc/postfix/sender_canonical eintrage, funktionieren?

Nein. Arcor vergewissert sich vorher, dass die "falsche" Absenderadresse, die du verwenden willst, tatsächlich dir gehört. Dazu musst du in der Konfiguration bei Arcor die gewünschte Adresse eintragen, dann schicken sie eine Testmail mit einem Bestätigungslink an diese Adresse, und erst wenn du diesen Link mit einer ellenlangen ID nochmal aufrufst, akzeptieren sie die Adresse als gültig.

Das Verwenden von Fake-Absenderadressen ist damit also nicht möglich; der Sinn ist nur, dass du alle Mails über Arcor verschicken könntest, auch wenn du noch Mail-Accounts bei anderen Providern hast.

Aus versehen habe ich die Datei /var/log/mail.log gelöscht. Habe Sie jetzt wieder händisch angelegt. Jetzt wird die Log-Datei aber nichtmehr mit Infos befüllt. Könnt Ihr mir sagen, woran das liegt?

Vermutlich an den Berechtigungen. Wenn du sie von Hand anlegst, "gehört" sie einem anderen Nutzer und hat vermutlich auch andere Zugriffsrechte. Ich würde sie einfach wieder löschen; normalerweise sollte Postfix sie bei Bedarf wieder neu erzeugen. Ist ja bloß eine Log-Datei.

So long,
 Martin

[Karl Heinz]

Das Verwenden von Fake-Absenderadressen ist damit also nicht möglich; der Sinn ist nur, dass du alle Mails über Arcor verschicken könntest, auch wenn du noch Mail-Accounts bei anderen Providern hast.

Mmm, irgend eine Möglichkeit Fake Adressen zu verwenden muss es doch geben. Ich bin mir fast sicher das du diese kennst :-). Kannst du mir einen Tipp geben?

[Der Martin]

Hallo,

Das Verwenden von Fake-Absenderadressen ist damit also nicht möglich; der Sinn ist nur, dass du alle Mails über Arcor verschicken könntest, auch wenn du noch Mail-Accounts bei anderen Providern hast.

Mmm, irgend eine Möglichkeit Fake Adressen zu verwenden muss es doch geben. Ich bin mir fast sicher das du diese kennst :-). Kannst du mir einen Tipp geben?

natürlich ... Versuche, einen offenen Mailserver zu finden, der deine Nachrichten entgegennimmt und weiterleitet. Also einen, der dir alles glaubt und keine Anmeldung fordert.

Die besten Chancen hast du vermutlich in Osteuropa (Rumänien, Ukraine), Fernost (China, Korea) oder Südamerika (Brasilien, Argentinien). Das sind zumindest die Herkunftsländer, die in meiner eigenen SPAM-Statistik auf den ersten Plätzen stehen.
Geh aber davon aus, dass solche offenen Mailserver sehr schnell wieder auf den Blacklists stehen, so dass du dir dann wieder einen anderen suchen musst.

Alternative: Miete dir einen Root-Server in einem anerkannten Rechenzentrum, wo du komplett deinen eigenen Mailserver aufsetzen kannst und sämtliche Absender-Checks wegkonfigurierst. Aber sobald du damit auffällig wirst, wird auch dieser Server ruck-zuck auf diversen Blacklists stehen; eventuell kündigt der Provider dir sogar den Vertrag, weil du gegen irgendwelche Vereinbarungen verstößt.

So long,
 Martin

[Karl Heinz]

natürlich ... Versuche, einen offenen Mailserver zu finden, der deine Nachrichten entgegennimmt und weiterleitet. Also einen, der dir alles glaubt und keine Anmeldung fordert.

Wie sucht bzw. findet man denn einen offenen Mailserver? Gibt es da spezielle Suchmaschinen?

Vielleicht sowas wie www.shodanhq.com?

Alternative: Miete dir einen Root-Server in einem anerkannten Rechenzentrum, wo du komplett deinen eigenen Mailserver aufsetzen kannst und sämtliche Absender-Checks wegkonfigurierst.

Root Server ist ein Synonym-Begriff für dedizierter Server korrekt?

Der Root-Server gehört einem im Gegenteil zu einem Shared-Server komplett alleine?

Welche Linux Distribution läuft eigentlich auf Root-Servern oder Shared-Servern? Gibt es da einen Standard oder sind das verschiedene?

Haben die Root-Server oder Shared-Server eigentlich auch eine GUI (Cinnamon, KDE, Mate usw.) oder kann man die nur per Terminal nutzen?

[Der Martin]

Moin,

natürlich ... Versuche, einen offenen Mailserver zu finden, der deine Nachrichten entgegennimmt und weiterleitet. Also einen, der dir alles glaubt und keine Anmeldung fordert.

Wie sucht bzw. findet man denn einen offenen Mailserver? Gibt es da spezielle Suchmaschinen?

hehe, du kannst Fragen stellen! Wie sucht man nach einem schlecht bewachten Geldtransporter? ;-)

Vielleicht sowas wie www.shodanhq.com?

Keine Ahnung. Vermutlich eher nicht, aber ich kann es nicht beurteilen.

Alternative: Miete dir einen Root-Server in einem anerkannten Rechenzentrum, wo du komplett deinen eigenen Mailserver aufsetzen kannst und sämtliche Absender-Checks wegkonfigurierst.

Root Server ist ein Synonym-Begriff für dedizierter Server korrekt?

Der Root-Server gehört einem im Gegenteil zu einem Shared-Server komplett alleine?

Viel wichtiger: Ein Server, den du komplett selbst verwaltest, auf dem du selbst root bist. Hence the name.

Welche Linux Distribution läuft eigentlich auf Root-Servern ...

Diejenige, die du selbst installierst. Wobei der Hoster meist zwei oder drei typische vorkonfiguriert anbietet.

Haben die Root-Server oder Shared-Server eigentlich auch eine GUI (Cinnamon, KDE, Mate usw.) oder kann man die nur per Terminal nutzen?

Normalerweise haben die keinen Desktop, sondern werden per ssh bedient. Oder in Notfällen mal von einem RZ-Mitarbeiter vor Ort.

So long,
 Martin

[Karl Heinz]

hehe, du kannst Fragen stellen! Wie sucht man nach einem schlecht bewachten Geldtransporter? ;-)

Ich habe halt Null Ahnung wie man da vorgeht, du hättest sicherlich eine Strategie die besser ist als meine Null Ahnung Strategie :-).

Irgend ein Tipp vielleicht?

Wie findet man Mail-Server?

• Über Web-Verzeichnisse?
• Über Such-Maschinen?
• Über spezialisierte Foren?
• Über eine Terminal Abfrage Script das bestimmte IP Bereiche scannt?
• ...

Habe keine Ahnung wie ich da ran gehen soll.

[Der Martin]

Moin,

hehe, du kannst Fragen stellen! Wie sucht man nach einem schlecht bewachten Geldtransporter? ;-)

Ich habe halt Null Ahnung wie man da vorgeht, du hättest sicherlich eine Strategie die besser ist als meine Null Ahnung Strategie :-).

in diesem Fall: Nein, nicht wirklich. Ich würde auch im Nebel stochern, weil mich diese Grauzone bisher nur unter rein theoretischen Aspekten interessiert hat.

Wie findet man Mail-Server?

Du meinst vor allem solche, die man "missbrauchen" kann?

• Über Web-Verzeichnisse?

Möglich. Zumindest die anständigen, seriösen.

• Über Such-Maschinen?
• Über spezialisierte Foren?

Möglich, vielleicht in der Hacker-Szene.
Und bevor du danach fragst: Nein, da habe ich keinen Einblick.

• Über eine Terminal Abfrage Script das bestimmte IP Bereiche scannt?

Hmm, dann findest du wahrscheinlich Hunderte, die meisten davon absolut anständig.

Habe keine Ahnung wie ich da ran gehen soll.

Was ich mir noch vorstellen könnte: Mal die Received-Headerzeilen einiger SPAM-Mails durchgehen und nachlesen, über welche Server die (angeblich) verschickt und weitergeleitet wurden. Manchmal stehen sie als Klartext (mit Hostnamen) drin, manchmal nur per IP-Adresse, und die Angaben müssen auch nicht zwangsläufig korrekt sein. Aber es wäre ein Anhaltspunkt.

So long,
 Martin

[Tabellenkalk]

Hallo,

Habe keine Ahnung wie ich da ran gehen soll.

Bisher gings es um theoretische Überlegungen. Du scheinst das tatsächlich praktisch vorzuhaben. Daher folgender Ratschlag: Nein, da sollst du garnicht "ran gehen".

Gruß
Kalk

[Google weiß alles]

Ich habe halt Null Ahnung wie man da vorgeht, du hättest sicherlich eine Strategie die besser ist als meine Null Ahnung Strategie :-).

Schau mal nach, was Dein ISP Dir als Mailserver anbietet und nutze den als Smarthost. Die ISP (die Typen von denen Du Deinen Internetzugang kaufst) lassen oft den Versand über deren Mailserver unter beliebigem Absender zu, weil die den möglichen Missbraucher anhand der von diesen vergebenen IP erkennen und also auch auf die richtigen Finger hauen (oder den Anschlussinhaber der StA als Verursacher nennen) können.

[Tingelding Wankelbumm]

Ein SMTP-Server ohne eine feste IP-Adresse und ohne ordentliche Zertifikate wäre eine ideale Spam-Schleuder. Deshalb akzeptiert eigentlich kein E-Mail-Server E-Mails von solchen Servern.

Zertifikate sind in aller Regel bedeutungslos.

Wie kann man denn bezogen auf einen Mail-Server herausfinden, ob dieser Mails direkt von einem Postfix-Server (ohne den Umweg über einen Smarthost) akzeptiert?

Das hat nichts mit der verwendeten Software zu tun, es wird einfach geprüft, von welchem Anschluss verschickt wird – daher der Hinweis auf die "feste IP-Adresse" oben.

Die meisten Internet-Provider versehen Einwahlanschlüsse (auch DSL) mit halbwegs aussagekräftigen Domainnamen. Der annehmende Mailserver braucht lediglich prüfen, ob im linken Teil des Namens etwas à la dynamic, dial, dsl, dhcp, ppp oder dergleichen vorkommt und kann sich schon sehr sicher sein, dass da kein echter Mailserver hintersteckt, keiner, der regulär an einer festen Adresse erreichbar wäre, sondern einer im heimischen Kinderzimmer. (Die Postfix-Einstellung wäre check_client_access mit entsprechender Tabelle.)

Es gibt weiterhin eine Empfehlung, bei solchen Zugänge die IP-Adresse in den Domainnamen zu übernehmen. 12-34-56.example.com wäre also auch ein deutlicher Hinweis auf einen Einwahlanschluss.

Die Deutsche Telekom verwendet für ihre häuslichen Kunden grundsätzlich t-dialin.net oder t-ipconnect.de, jeweils mit IP-Adresse vorweg, allerdings hexadezimal en bloc kodiert. Andere große Provider verfahren ähnlich.

Last but not least gibt es auch Listen mit IP-Bereichen, die von Providern dynamisch vergeben werden (Spamhaus und SORBS haben zum Beispiel solche Listen, Postfix-Einstellung reject_rbl_client).

Das alles sind Kriterien, die genutzt werden können, Mails nur noch nach Authentifizierung anzunehmen. Es geht hier allerdings weniger um Leute, die zu Hause sinnloserweise einen Mailserver betreiben, sondern um infizierte PCs – gefühlt 90% allen Spams wird über virenverseuchte Heim-PCs verschickt. Wenn du wieder was bekommst, achte mal drauf: Du findest die Angaben in den Received:-Kopfzeilen.

[Google weiß alles]

gefühlt 90% allen Spams wird über virenverseuchte Heim-PCs verschickt. Wenn du wieder was bekommst, achte mal drauf: Du findest die Angaben in den Received:-Kopfzeilen.

Weitere gefühlte 900% allen Spams werden über "professionell betriebene" Webserver mit gehackten Joomla- oder Wordpress-Installationen verschickt. Dazu kommen noch gefühlte 450% des Spams, der von Servern bei sehr professionellen Spamhostern ausgesendet wird. Natürlich landen auch die in den erwähnten Blacklists und werden von ernsthaft betriebenen Mailservern nicht mal mehr angenommen, was man sehr schön in den Gigabyte-großen Logfiles des missbrauchten Webservers oder im Falle eines rechtmäßig versendeten aber nicht angenommen Mails im Bounce nachlesen kann. Ein paar Prozente des Spams gehen über täglich neue Accounts bei Freemailern raus, die nicht gesperrt werden können, also auf einer Blacklist für die Aufnahme in die Blacklist stehen.

[Karl Heinz]

Die Logdatei /var/log/mail.log zeigt mir folgendes:

> Oct  7 13:54:22 Desktop-Robert postfix/pickup[9995]: 390C32E3403: uid=1000 from=<robert>
> Oct  7 13:54:22 Desktop-Robert postfix/cleanup[10098]: 390C32E3403: message-id=<20161007115422.390C32E3403@Desktop-Robert>
> Oct  7 13:54:22 Desktop-Robert postfix/qmgr[9996]: 390C32E3403: from=<[e-mail]>, size=322, nrcpt=1 (queue active)
> Oct  7 13:54:22 Desktop-Robert postfix/smtp[10100]: warning: SASL authentication failure: No worthy mechs found
> Oct  7 13:54:22 Desktop-Robert postfix/smtp[10100]: 390C32E3403: to=<[e-mail]>, relay=xxx.kasserver.com[85.13.152.83]:25, delay=0.4, delays=0.01/0.01/0.38/0, dsn=4.7.0, status=deferred (SASL authentication failed; cannot authenticate to server w00a53e4.kasserver.com[85.13.152.83]: no mechanism available)

Es scheint wohl irgendwas mit der SASL authentication nicht zu stimmten.

ja, sieht ganz so aus.

Weißt du hier Rat?

Leider nein, da bin ich auch überfragt. Aber du bist nicht der erste, der dieses Problem hat.

Es klappt jetzt, hat daran gelegen, dass Passwörter im Klartext übertragen werden müssen, ich habe einfach "noplaintext" in nachfolgendem Abschnitt gelöscht und schon klappt es.

smtp_sasl_auth_enable = yes
# noplaintext weglassen, wenn Passwörter im Klartext übertragen werden müssen:
# (nicht empfohlen, nur wenn's anders nicht funktioniert)
smtp_sasl_security_options = noplaintext noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password

In diesem Zusammenhang die Frage wie ich im Vorfeld herausfinden kann, ob ein Smarthost ausschließlich Passwörter im Klartext akzeptiert. Kann ich das irgendwie per Terminal abfragen oder wie kann ich diese Information herausfinden. Durch probieren finde ich jetzt nicht besonders elegant.

[Der Martin]

Mahlzeit,

Aber du bist nicht der erste, der dieses Problem hat.

Es klappt jetzt, hat daran gelegen, dass Passwörter im Klartext übertragen werden müssen, ich habe einfach "noplaintext" in nachfolgendem Abschnitt gelöscht und schon klappt es.

Sehr schön ... also, dass es jetzt geht. Die Tatsache, dass Passwörter im Klartext übermittelt werden müssen, ist eigentlich nicht schön.

In diesem Zusammenhang die Frage wie ich im Vorfeld herausfinden kann, ob ein Smarthost ausschließlich Passwörter im Klartext akzeptiert. Kann ich das irgendwie per Terminal abfragen oder wie kann ich diese Information herausfinden. Durch probieren finde ich jetzt nicht besonders elegant.

Das sollte dir eigentlich dein e-Mail-Provider sagen können. Da, wo du Informationen über Hostnamen, die zu verwendenden Ports und Usernamen findest, sollte auch angegeben sein, ob der Server von Anfang an eine verschlüsselte Verbindung akzeptiert oder erst nach der Anmeldung auf Verschlüsselung umschalten will (STARTTLS-Kommando).

So long,
 Martin

[Tagwächter]

Das sollte dir eigentlich dein e-Mail-Provider sagen können. Da, wo du Informationen über Hostnamen, die zu verwendenden Ports und Usernamen findest,

Den mir besonders relevant erscheinenden Teil habe ich mal eingefettet.

Ich habe noch einen Lesetipp zu "Nutzung eines Smarthost mit Postfix und TLS":

https://blog.bravi.org/?p=1065

Und: "Configure Postfix to Send Mail Using an External SMTP Server"

An der Vorgehensweise dürfte sich bei anderen Linux-Distries nichts oder nicht viel (vielleicht der eine oder andere Pfad unterhalb von /etc/) ändern...

[Karl Heinz]

Das sollte dir eigentlich dein e-Mail-Provider sagen können. Da, wo du Informationen über Hostnamen, die zu verwendenden Ports und Usernamen findest, sollte auch angegeben sein, ob der Server von Anfang an eine verschlüsselte Verbindung akzeptiert oder erst nach der Anmeldung auf Verschlüsselung umschalten will (STARTTLS-Kommando).

Ich habe mir mal den Wikipedia Artikel zu STARTTLS angeschaut:

https://de.wikipedia.org/wiki/STARTTLS

Der Artikel enthält u.a. folgenden Absatz:

Bei einer älteren Methode zur Einleitung der Verschlüsselung einer Verbindung zwischen Mailprogramm (Client) und Mailserver setzt diese Verhandlung bereits beim Verbindungsaufbau ein, indem die entsprechenden Ports angesprochen werden. In den Beispielen für Standardports kennzeichnet das jeweilige S hinter den Protokollbezeichnungen die abgesicherte Variante:

Bei der genannten älteren Methode wird demnach gleich von Anfang an verschlüsselt, bei der neueren Methode (STARTTLS) hingegen erst nach dem Verbindungaufbau.

Eigentlich würde ich vermuten, dass die neuere Methode (STARTTLS) die bessere ist und gleich am Anfang verschlüsselt, laut Wikipedia-Artikel ist es aber genau umgekehrt.

Habe ich da etwas falsch verstanden?

[Google weiß alles]

Eigentlich würde ich vermuten, dass die neuere Methode (STARTTLS) die bessere ist und gleich am Anfang verschlüsselt, laut Wikipedia-Artikel ist es aber genau umgekehrt.

Habe ich da etwas falsch verstanden?

Kurze Antwort: Ja.

Lange Antwort:

Hier ist ein Beispiel für die unverschlüsselte Anwendung des SMTP-Protokolls via Telnet/NetCat

Nach dem Verbindungsaufbau aber vor der Authentifizierung sendet der Server dem Client eine Zeile

STARTTLS

Darauf hin antwortet der Client, wie er verschlüsseln kann, es wird also die Verschlüsselungsmethode ausgehandelt und dann auch zu dieser gewechselt. Nachfolgend werden ohne Protokollwechsel also brav Zeilen ausgetauscht, die aber verschlüsselt sind. Darunter auch die USER-Zeile und die PASS-Zeile.

Ich zitiere mal:

"Ein essentieller Vorteil hierbei ist die Tatsache, dass die Peers, also die Verbindungspartner, die technischen Fähigkeiten beiderseits aushandeln können. Wird auf einem dedizierten SSL-Port eine Klartextverbindung aufgebaut, kommt es zwangsläufig zum Abbruch, in umgekehrter Kombination ebenso. Der Nutzer oder ein Admin muss nun eingreifen. Dank STARTTLS kann zum Beispiel der Client (ohne Nutzereingriff) wahrnehmen, dass der Server die Erweiterung bietet und automatisch Gebrauch davon machen. Im Alternativfall müsste der Client erst den dedizierten Port kontaktieren, auf den Fristablauf warten und danach den Port für unverschlüsselte Kommunikation testen."