- postfix-users - list.sys4.de

Re: privater Mailserver ohne DNS
by Jörn Bredereck 06 Sep '16

06 Sep '16

> danke für die Rückmeldung und für den 'Stubser'. Daß ich den Raspberry in mydestination eintragen kann hatte ich auch schon herausgefunden. Aber noch fehlt mir die Möglichkeit, die Mail an eine Nachbar-Maschine zu schicken. Reicht es, die Namen (es sind nicht viele) mit der Host-Zuordnung in /etc/aliases einzutragen und in welcher Form? So wie sie in /etc/hosts stehen oder mit der expliziten IP-Adresse? Du kannst ein statisches Routing ohne DNS-Lookup über die transport table erreichen. In der main.cf: transport_maps = hash:/etc/postfix/transport Wenn du z.B. E-Mails für den Domainpart @laptop an die 192.168.0.200 schicken willst, dann lautet der Eintrag in der Datei /etc/postfix/transport wie folgt: laptop smtp:[192.168.0.200] Nach jeder Änderung an der transport-Datei musst du die dazugehörige Datenbank neu erstellen: postmap /etc/postfix/transport Viele Grüße, Jörn Bredereck -- ****************************** B&W-NetworX GmbH & Co. KG Landstr. 67a 76547 Sinzheim Fon: 07221 996388-8 Fax: 07221 996388-1 http://www.bw-networx.net info(a)bw-networx.net ----------------------------- AG Mannheim HRA 521208 Pers. haf. Ges.: B&W-NetworX Verwaltungs-GmbH Sitz: 76532 Baden-Baden AG Mannheim HRB Nr.: 202122 Geschäftsführer: Jörn Bredereck Dipl. Ing. Holger Wunsch ******************************

1 0

privater Mailserver ohne DNS
by Lutz John 06 Sep '16

06 Sep '16

Liebe Postfixexperten! Ich möchte mich ein bißchen in die Mailwelt einarbeiten und bin dank der Anleitung von 'crisge/meinhomelinux' auch schon etwas fortgeschritten. Nachdem ich die Mails nur in einem kleinen privaten Netz mit 3-4 Maschinen verteilen will und keine Mails von außen empfangen will, hatte ich die Frage gestellt, ob es möglich ist, ohne einen DNS-Server auszukommen und wenn ja, wie ich postfix konfigurieren müßte. Man hat mich an Euch verwiesen. Vielleicht kann mir ja jemand helfen, und sei es auch nur, klar zu sagen, daß es nicht geht. Siehe Thema 'Privater Mailserver ohne DNS' von havilu, Forum linuxmintusers.de. Vielen Dank Lutz John

5 5

Postfix 3.x
by Lukas Malkmus 05 Sep '16

05 Sep '16

Hallo Postfix Experten! Kurz und knapp: Was spricht dagegen für einen neuen Mailserver Postfix 3.x zu verwenden? Gruß, Lukas

2 1

Generelle Frage zum Aufbau einer Postfix-Infrastruktur
by Johannes Kastl 10 Aug '16

10 Aug '16

Liebe Liste, bitte entschuldigt, falls das eine total simple Frage sein sollte. Aber ich befürchte, dass ich etwas übersehe. Ich möchte meine Domains über kurz oder lang mit DNSSEC ausstatten, sprich meine eigenen Nameserver aufsetzen. Die beiden Maschinen sind startklar, bis auf die Postfix-Konfiguration. Und da habe ich mich jetzt gefragt, ob ich auf zwei separate Master gehen soll, oder auf Master+Slave. Ich habe vor, die komplette Konfiguration per Ansible zu erledigen. Es geht nur um kleine Domains, nicht viele Hosts, keine dynamischen Updates oder ähnliches. Sprich die Zonendateien sollten relativ stativ sein. Lasse ich DNSSEC außen vor, sollte eigentlich ein Setup mit zwei (fast?) identischen Mastern funktionieren, einer als Primary und einer als Secondary Nameserver. Bei DNSSEC sieht es anders aus, da ich die Signaturen ja nicht auf dem Ansible-Host in die Zonendateien einbauen kann. Und die Schlüssel per Ansible zu verteilen könnte auch etwas schwieriger werden. Daher würde ich jetzt auf eine einfach Master+Slave Kombination gehen. Master und Slave in die Konfigurationen eintragen, die Transfers per TSIG absichern und dann sollte das eigentlich recht sicher und sauber laufen. Oder übersehe ich etwas? Vielen Dank im Voraus! Grüße Johannes

4 5

Postfix smtpd, Google
by Christian Wohlgemuth 09 Aug '16

09 Aug '16

N'abend allerseits, Ich habe ich Problem mit Postfix und Google: Mir ist aufgefallen, dass Google meine Mails temporär ablehnt mit folgender Meldung: host gmail-smtp-in.l.google.com[74.125.133.26] said: 421-4.7.0 [37.114.46.24 15] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0 https://support.google.com/mail/answer/81126 to review our Bulk Email 421 4.7.0 Senders Guidelines. 80si21752417wmy.26 - gsmtp (in reply to end of DATA command) Im mail.log, war die letzte Mail vor circa 2 Wochen an gmail. Kennt jemand dieses Problem und kann weiterhelfen dies zu lösen Vielen Dank

2 4

AOL mag meine MTAs nicht mehr (DYN:T1)
by Peter Heitzer 09 Aug '16

09 Aug '16

Durch einen gehackten Account sind von Sonntag auf Montag etliche SPAM-Mails an AOL-Adressen versendet worden. Seitdem nehmen mailin-xx-mx.aol.com keine Mails mehr an mit 421 4.7.1 (DYN:T1). https://postmaster.aol.com/error-codes#421dynt1 schreibt, daß es sich dabei um einen temporären Fehler handelt. Reicht es in diesem Fall, abzuwarten oder muss ich mich an AOL wenden, damit ich von ihrer Blacklist wieder runterkomme? Die SPAM-Mails habe ich bereits aus der deferred queue entsorgt, so daß nur noch legitime Mails mit aol Empfängern vorhanden sein dürften. ---- Dipl.-Inform(FH) Peter Heitzer, peter.heitzer(a)rz.uni-regensburg.de

2 2

Envelope Sender - From: Check
by Marc Patermann 25 Jul '16

25 Jul '16

Hallo, Thunderbird hat die "als neu bearbeiten"-Funktion, die (jetzt?*) erlaubt eine Mail unter Beibehaltung der Absenderadresse im Header neu bzw. anders zu verschicken. Thunderbird verwendet weiter die in den Account-Einstellungen eingetragene Absenderadresse im SMTP-Dialog. D.h. Envelope Sender und Login-Daten stimmen überein. smtpd_sender_login_maps wird weiterhin erfolgreich durchlaufen. Return-Path: ist zutreffend gesetzt. Das Envelope Sender und From: abweichen, ist ja nun aus gutem Grund nicht selten, z.B. bei Listenmails wie diesen. Trotzdem ist es intern auf Unmut gestoßen, dass man nun "so einfach" interne Mails unter fremdem Namen versenden kann. Wie könnte ein selektiver (Heder-)Check aussehen, der z.B. für SASL-authentifizierte auf Port 25 eingehende Mails From: und Envelope Sender abgleicht und abweist? *) Meiner Erinnerung nach war es in älteren Versionen nicht so, dass der Absender bei der Funktion übernommen wurde. Marc

4 3

zusätzlicher smtpd in master.cf ohne in local/virtual zu landen
by Christian Bricart 23 Jul '16

23 Jul '16

Tach zusammen, irgendwie stehe ich auf dem Schlauch. Ich will einen zweiten Eingang zum lokalen Postfix haben (172.0.0.1:2525). Dort soll ein anderer lokaler Prozess per SMTP Mails einkippen können, die dann nach einem Header-Rewrite (ausschliesslich) den weiteren Weg über einen externen Smarthost nehmen. (Hintergrund ist, dass dieser lokale Prozess ausschliesslich SMTP und das ausschliesslich ohne TLS kann und ich den Postfix als quasi TLS-Client in Richtung Smarthost verwenden will) Dazu habe ich folgenden Eintrag in der master.cf: 127.0.0.1:2525 inet n - - - - smtpd -v -o content_filter= -o local_recipient_maps= -o mydestination= -o mynetworks=127.0.0.0/8 -o mynetworks_style=host -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_address_mappings -o relay_recipient_maps= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_restriction_classes= -o smtpd_sender_restrictions= -o smtpd_tls_security_level=none -o smtpd_authorized_xforward_hosts=127.0.0.0/8 -o virtual_alias_maps= -o default_transport = outbound # outbound transport: outbound unix - - - - - smtp -o relayhost=outbound.example.com -o smtp_header_checks=pcre:/etc/postfix/header_rewrites.pcre Das funktioniert so lange, wie das Ziel der Mail keine in der main.cf definierten virtual trifft - aber auch diese Mails sollen hier stumpf einfach den Weg über den Smarthost nehmen und notfalls eben von "vorne" wieder reinkommen. Habe ich das richtig erkannt, dass das an trivial-rewrite(8) liegt und dass ich für sowas ein komplettes postmulti Setup brauche? Oder übersehe ich hier noch was? Grüsse Christian

1 0

Unklare Übertragungsprobleme bei einigen Mails
by Stephan Jacob 01 Jul '16

01 Jul '16

Hallo Postfixler, ich bin auf ein Phänomen gestoßen, welches ich mir nicht erklären kann. Ggf. hat einer von euch eine Idee, wie folgende Situation zu Stande kommt: Ich habe einen Relay Server aufgesetzt und diesen mit IPTables abgesichert (Regeln sind unten beschrieben). Der Server soll vornehmlich Mails "von außen" annehmen und dann intern an 3 verschiedene Mailserver weiterleiten. Bei der Weiterleitung an einen der 3 Mailserver (den unserer Kollegen aus der Uniklinik) kam es bei vereinzelnden Mails zu Zustellungsproblemen und die Mails wurden mit "status=deferred (conversation with uniklinikmailserver[149.AAA.BBB.CCC] timed out while sending message body)" gequeued. Das Problem trat grundsätzlich nur bei "großen" Mails (beobachtet bei 5MB bis 35MB) auf. Dort aber auch nicht bei allen "großen" Mails. Als ich verschiedene Testmails verschiedener Größe an den Mailsserver gesendet habe, konnte ich den Fehler nicht nachstellen. Problematische Mails verschwanden irgendwann (mal nach 20 Minuten, mal nach 5 Stunden) von alleine aus der Queue und wurden laut Log auch an den Uniklinik-Server übertragen. Auch gingen zum Zeitpunkt, wo der Fehler auftritt auf einen anderen Kanal erfoglreich Mails zum dem Mailserver durch, d.h. er war auch verfügbar. Das Problem trat auf, als ich folgende IPTabels Regeln aktiv hatte: *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 141.AAA.240.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j DROP -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j ACCEPT -A INPUT -s 141.AAA.13.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn -m multiport --dports 22 -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -s 141.AAA.BBB.CCC -o eth0 -j ACCEPT COMMIT (In Zeile 7 wird bewusst eines unserer Subnetze ausgeschlossen, es soll kein Mailversand dort stattfinden) Im Zuge der Problemfindung habe ich dann die Pakete, die in der Kommunikation mit dem Uniklinik-Server gedropt werden mitgeloggt. Dabei habe ich bei den Mails, bei denen der oben beschriebene Fehler vorkam folgende Log-Einträge gefunden: Jun 23 12:23:33 mx3 kernel: [ 10.790460] IPTables-Dropped: IN=eth0 OUT= SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=64 TOS=0x00 PREC=0x00 TTL=60 ID=64801 DF PROTO=TCP SPT=25 DPT=60337 WINDOW=480 RES=0x00 ACK URGP=0 Oder bei einer anderen Mail: Jun 23 12:48:32 mx3 kernel: [ 1509.990907] IPTables-Dropped: IN=eth0 OUT= SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=168 TOS=0x00 PREC=0x00 TTL=60 ID=36782 DF PROTO=TCP SPT=25 DPT=32982 WINDOW=3797 RES=0x00 ACK PSH URGP=0 (149.AAA.BBB.CCC ist der Uniklinikserver und 141.AAA.BBB.CCC bin ich). Zur Sicherheit noch einmal: Diese Einträge kamen als ich (141.AAA.BBB.CCC) an die Uniklinik (149.AAA.BBB.CCC) Mails gesendet habe. Es wurden aber nur Pakete bei den Mails verworfen, bei denen die Übertragung nicht funktioniert hat. Zu dem Zeitpunkt, wo die zuvor durch fehlerhafte Übertragung gequeueten Mails übertragen wurden, finden sich auch keine gedroppten Pakete im IPTabeles Log. Das Problem konnte ich dadurch vermeiden, indem ich in der IPTables sämtliche Kommunikation von und zu dem Uniklinik Mailserver erlaubt habe: -A INPUT -s 149.AAA.BBB.CCC -d 141.AAA.BBB.CCC -j ACCEPT Der Mailserver der Uniklinik betreibt Postfix in unbekannter Version. Mails zu einem anderen Postfix Server intern und unserem Exchange Server intern laufen ohne Probleme. Ich betreibe Postfxi 2.11. Meine Fragen sind nun: - Was werden da für TCP Pakete an mich gesendet, die verworfen werden? Wenn diese zur "normalen" Kommunikation beim Mailaustausch gehören, müssten die doch bei jeder Mail kommen oder? - Wieso, findet diese Kommunikation nur bei einigen wenigen Mails statt und bisher nur bei einen der 3 Mailserver? Und teilw. bei ein und derselben Mail mal und mal nicht? - Wie müssten IPTabels Rules auf einem Relay für sowohl eingehenden als auch ausgehenden Mailverkehr aussehen, damit es nicht zu solchen Übertragungsproblemen kommt? Ich kann ja nicht die ganze Welt Whitelisten?!? VG Stephan Jacob Otto-von-Guericke Universität Magdeburg Universitätsrechenzentrum (URZ) Universitätsplatz 2 Gebäude 26 - 035 39106 Magdeburg Tel.: 0391-67-58572 Fax: 0391-67-11134

7 16

Achtung neuer Crypto Locker im Anflug
by Patrick Ben Koetter 29 Jun '16

29 Jun '16

Er tarnt sich als DHL Paketverfolgung: ---- From: DHL Paketverfolgung <tracking(a)dhl.de> Subject: DHL-Paket-Lieferung fehlgeschlagen Reply-To: <DHL Paketverfolgung <tracking(a)dhl.de>> Sehr geehrter Kunde, die Lieferung für das Paket mit der Sendungsverfolgungsnummer 056392024191 ist fehlgeschlagen. Der Kurier war zum wiederholten Male nicht in der Lage Sie persönlich anzutreffen. Bitte senden Sie uns das ausgefüllte Versandetikett um einen erneuten Lieferungsversuch in Auftrag zu geben. Das Versandetikett für Ihre Lieferung finden Sie im Anhang dieser E-Mail. Mit freundlichen Grüßen, DHL EXPRESS Deutsche Post AG Charles-de-Gaulle-Straße 20 PLZ/ Ort: 53113 Bonn ---- Im Anhang befindet sich eine Sendung_xxx.zip, welche JS-Dateien beinhaltet: unzip -t Desktop/Sendung_056392024191.zip Archive: Desktop/Sendung_056392024191.zip testing: Sendungsetikett_056392024191.pdf.js.js OK testing: Sendungsinformationen_056392024191.pdf.js.js OK No errors detected in compressed data of Desktop/Sendung_056392024191.zip. In den Dateien selbst befindet sich dann der typische, obfuscatete JS-Code. Einzelne Strings werden zu einem grossen String zusammengebaut. Dann wird der Windows Scripting Host aufgerufen und der führt das zusammengebaute Skript dann aus. Dieses Skript lädt die eigentliche Malware nach, welche dann den Rechner unter Kontrolle bringt. Windows-Anwender erkennen in der Regel nicht, dass es sich um JS-Dateien handelt, weil die Defaults des OS das Suffix des Dateinamens unterdrückt. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

2 1