September 2015 - postfix-users

Wer will an einem kostenlosen DNSSEC/DANE-Workshop teilnehmen?
by Patrick Ben Koetter 02 Oct '15

02 Oct '15

Hallo Postfix-Users! Wir, die sys4, veranstalten kommende Woche auf der it-sa <https://www.it-sa.de> einen eintägigen Workshop zum Thema DNSSEC/DANE. Für den Workshop sind noch Plätze frei. Die Teilname ist kostenlos und die Tickets brennen ein Loch in meinen Tisch… ;) # Eckdaten Titel: DANEn lügen nicht! Beginn: Dienstag, 06.10.2015 um 09:00 Ende: Dienstag, 06.10.2015 um 17:00 ## Kurzbeschreibung In unserem zweiteiligen Workshop informieren wir im ersten Teil über Anwendungsszenarien und die Relevanz für die elektronische Kommunikation von DNS und DNSSEC im Unternehmensumfeld. Wir erklären, was DNSSEC und DANE sind, wie sie funktionieren und was sie bewirken. Dieser Teil richtet sich an CTOs/IT-Leiter, CEOs/Geschäftsführer, Inhaber von KMU, CI(S)Os und IT-Architekten. Im zweiten Teil üben wir mit Dir, wie sich eigene DNS-Zonen per DNSSEC absichern lassen, und wie ein DNS-Server die DNSSEC-Daten anderer Zonen im Netzwerk überprüfen (validieren) kann. Dieser Teil richtet sich vorrangig an Administratoren, aber auch an technisch versierte Mitarbeiter der Unternehmensleitung. # Wie kommst Du an ein Ticket? Tickets für die it-sa und den Workshop gibt es bei mir. Sende eine Mail an p(a)sys4.de und nenne mir die Anschrift an die wir die Tickets senden sollen. First come, first serve! Freitag nachmittag gehen wir ein letztes Mal zur Post… Ich freu mich! p@rick P.S. Die Teilnahme ist im Rahmen der Re-Zertifizierung zum T.I.S.P./T.E.S.S als Weiterbildung anrechnungsfähig. ;) -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

2 2

Konfiguration des Relaying
by Mein Papierkorb 29 Sep '15

29 Sep '15

Hallo zusammen, ich habe einen Postifx 2.9 mit Dovecot als MDA dahinter. Die anzunehmenden Domains sind in der "relay_domains" hinterlegt, mit dem Eintrag "lmtp:[127.0.0.1]" dahinter zur Weiterleitung an Dovecot. Soweit so gut - läuft auch alles. Nun möchte ich zusätzlich dieses Postfix vor einen Exchange schalten, um dem Exchange ein Greylisting zu spendieren. Davon betroffen ist eine zusätzliche Domain, die ich dann ebenfalls unter relay_domains eingetragen habe, mit dem Hostname des Exchange-Servers dahinter. Auch das funktioniert soweit. Zur Entlastung würde ich aber gerne eine Empfängerliste für diese Domain hinterlegen, damit Postfix sofort alle Mails ablehnt, deren Empfänger auf dem Exchange gar nicht existieren. Wenn man das über dynamische Empfängerlisten (Postfix-Buch S.331) versucht zu realisieren, scheint es in Verbindung mit dem Exchange 2013 jedoch große Probleme zu geben. Das Problem wird hier erläutert: http://www.msxfaq.de/e2013/e2013recipientfilter.htm Wenn ich es über ne statische Empfängerliste versuche (wäre generell auch ausreichend in diesem Fall), (Postfix-Buch S.329), dann müssten aber in der relay_recipient_maps jedoch auch alle Mail-Adressen auftauchen, die auch an Dovecot weitergeleitet werden. Die domains, die an Dovecot gehen würde ich aber gerne davon ausnehmen, weil das sind ein paar. Gibt es irgendwie ne Möglichkeit, die relay-domain für den Exchange mit ner statischen Empfängerliste zu ergänzen OHNE die domains, die an Dovecot gehen zu involvieren? Im Postfix-Buch auf S.329 steht was von "local_recipient_maps". Da der Dovecot auf der gleichen Mühle läuft, ist das in meinen Augen lokal (auch wenn das für Postfix natürlich auch ne Art von relaying ist - ist mir klar) Kann ich die Dovecot-Domains vielleicht irgendwie über "local_recipient_maps" laufen lassen, und sie so von dem echten (externen) Relaying zu dem Exchange zu trennen? Alternativ könnte ich natürlich noch ne 2. Postfix-Instanz konfigurieren, aber ich würd gern erstmal eure Meinung dazu hören... Danke vorab & Gruß, Markus

2 1

Konfiguration des Relaying
by Papierkorb 27 Sep '15

27 Sep '15

Hallo zusammen, ich habe einen Postifx 2.9 mit Dovecot als MDA dahinter. Die anzunehmenden Domains sind in der "relay_domains" hinterlegt, mit dem Eintrag "lmtp:[127.0.0.1]" dahinter zur Weiterleitung an Dovecot. Soweit so gut - läuft auch alles. Nun möchte ich zusätzlich dieses Postfix vor einen Exchange schalten, um dem Exchange ein Greylisting zu spendieren. Davon betroffen ist eine zusätzliche Domain, die ich dann ebenfalls unter relay_domains eingetragen habe, mit dem Hostname des Exchange-Servers dahinter. Auch das funktioniert soweit. Zur Entlastung würde ich aber gerne eine Empfängerliste für diese Domain hinterlegen, damit Postfix sofort alle Mails ablehnt, deren Empfänger auf dem Exchange gar nicht existieren. Wenn man das über dynamische Empfängerlisten (Postfix-Buch S.331) versucht zu realisieren, scheint es in Verbindung mit dem Exchange 2013 jedoch große Probleme zu geben. Das Problem wird hier erläutert: http://www.msxfaq.de/e2013/e2013recipientfilter.htm Wenn ich es über ne statische Empfängerliste versuche (wäre generell auch ausreichend in diesem Fall), (Postfix-Buch S.329), dann müssten aber in der relay_recipient_maps jedoch auch alle Mail-Adressen auftauchen, die auch an Dovecot weitergeleitet werden. Die domains, die an Dovecot gehen würde ich aber gerne davon ausnehmen, weil das sind ein paar. Gibt es irgendwie ne Möglichkeit, die relay-domain für den Exchange mit ner statischen Empfängerliste zu ergänzen OHNE die domains, die an Dovecot gehen zu involvieren? Im Postfix-Buch auf S.329 steht was von "local_recipient_maps". Da der Dovecot auf der gleichen Mühle läuft, ist das in meinen Augen lokal (auch wenn das für Postfix natürlich auch ne Art von relaying ist - ist mir klar) Kann ich die Dovecot-Domains vielleicht irgendwie über "local_recipient_maps" laufen lassen, und sie so von dem echten (externen) Relaying zu dem Exchange zu trennen? Alternativ könnte ich natürlich noch ne 2. Postfix-Instanz konfigurieren, aber ich würd gern erstmal eure Meinung dazu hören... Danke vorab & Gruß, Markus

1 0

Aliasverwaltung in Postfix oder Dovecot
by Wolfgang Rosenauer 27 Sep '15

27 Sep '15

Hi, bisher hatte ich für meine Mailserver die "Userverwaltung" hauptsächlich über Postfix gemacht. D.h. Usermapping, Aliase etc. Jetzt setze ich gerade wieder mal einen Mailserver neu auf und schaue gerade in Peer Heinleins Dovecot Buch, wo sehr stark empfohlen wird, einfach nur ein Relay zu Dovecot-lmtp einzurichten. Worauf aber nicht eingegangen wird, ist die Frage, wie denn Aliase zu handhaben sind (bzw. auch Mailbox-Namen, die nicht der email-Adresse entsprechen). Jetzt frage ich mich gerade, ob Dovecot mit Aliasen arbeiten kann oder ob ich das dann doch ganz herkömmlich wie früher mit alias_maps und mydestination machen müsste. Bzw. ob ich irgendwas übersehe, wie ich zwar den empfohlenen Relay Weg gehen kann aber vorher die Adressen umschreiben könnte. Danke, Wolfgang

5 4

[leicht OT] SPAM als Bounces der eigenen Domain mit Schadcode im Gepäck
by django＠nausch.org 21 Sep '15

21 Sep '15

Servus, in den Jahren in den ich mich nunmehr mit Mailservern beschäftigte, dachte ich eigentlich ich hab schon viel gesehen. Tja, falsch gedacht, denn seit gestern bin ich ein kleines Stückchen weiser - O.K., das ist bei mir Gerüchten nach relativ einfach, aber was sollst. Nun gut, gestern wurde groß Alarm geschlagen, da bei einer Kollegin plötzlich hunderte Mails (Bounces) aufschlugen und sie von dritter Seite gleich angeschissen wurde, sie habe in einer Spammail auf einen Link geklickt oder ein Attachment geöffnet zu haben. Schnell konnte ich klären und beweisen, dass die Kollegin gar nichts gemacht haben kann. Weder von Ihrem Account noch von einem anderen wurden, noch auf irgend einem der Mailserver beim Kunden hat in der Zeit irgendwas in der Art und Weise verschickt. Eigentlich ist an der Sache ja nicht ungewöhnliches, kennen wir doch Adressfälschungen und Backscatter doch schon etwas länger. Was mich aber nun stutzig machte, war der Umstand, dass in dem "zurückbekommenen Bounce" eine ZIP-Archiv mit einer .exe enthalten war. MOMENT, dachte ich mir, dafür haben wir doch extra eigene Regeln in unseren AMaViS-Cluster, die eben Nachrichten mit derartigem potentiellen Schadcode gar nicht erst annehmen soll. Kurz brach der Angstschweis aus, da ich mich selbst verdächtigte in einer der vielen dunklen Minuten (bei dem der schwarze Hund mich mehr beschäftigte als die Arbeit) etwas verkonfiguriert zu haben. Aber auch das konnte ich sehr schnell widerlegen, da alle Versuche solch präparierte Nachrichten an "mir selbst" vorbeizuschleusen, allesamt zum Scheitern verurteilt waren. Also zurück auf Anfang und aus den Maillogs der verschiedenen Systeme die Log-Zeilen herausgesucht. Denn irgendwo muss es ja einen Grund geben, warum der gefakte Bounce mit dem Schadcode im Anhang durchgewunken wurde. Der Versuch den Schadcode in einer Standardmail verpackt zu empfangen klappt jedoch nicht. Das einzigste, was ich da nun entdeckt habe, war auf dem AMaViS-Cluster: Sep 8 13:17:10 amavis-cluster-by amavis[23088]: (23088-10) bounce rescued by domain (DSN), <> -> <redacted(a)example.com>, date: Tue, 8 Sep 2015 12:41:24 +0200, from: Rosenbaum Group <redacted(a)example.com>, message-id: <HDmUIBRrPV7ZeJ2q0r2ttvv(a)example.com>, return-path: redacted(a)example.com Hä, "bounce rescued by domain" sagt mir nix, als Tante Google befragen und folgende beiden Seiten entdeckt: https://www.mail-archive.com/amavis-user@lists.sourceforge.net/msg11245.html http://sourceforge.net/p/amavis/mailman/amavis-user/thread/201010051713.380… O.K. $bounce_killer_score habe ich gefunden, der Wert wurde bis dato nicht angefasst, steht er beim Defaultwert: $bounce_killer_score = 100; # spam score points to add for joe-jobbed bounces Darum habe ich mich auch bis jetzt noch nie so richtig beschäftigt, weder in Berlin noch in München wurde das Thema erwähnt hehe - kleiner Wink mit dem Zaunpfahl ;) Wie kann ich nun meine AMaVis'e dazu bewegen, gefakte Bounces zu erkennen und deren Annahme zu verweigern? Alternativ dazu, muss ich dann für solche Fälle eben doch eine Quarantäne vorhalten und derartigen Müll nicht zum Endkunden zurückzuwerfen. Also Raus aus dem Schützengraben und klärt mich mal auf, wo genau ich mich zu diesem angeblichen bounce killer feature einlesen und beeinflussen kann. Servus Django -- http://dokuwiki.nausch.org http://wetterstation-pliening.info http://ebersberger-liedersammlung.de

4 11

Relay ohne lokale Queue
by Lutz Reinhardt 16 Sep '15

16 Sep '15

Hallo zusammen, ist möchte folgendes tun: - ankommende Mails sollen an einen SMTP Server nur weitergeleitet werden (Relay halt) - dabei soll das ganze aber "live" passieren - so das wenn der Ziel SMTP Server an den die Mails weitergeleitet werden, abbricht bzw. die Mails abweist, die Response an den Sender weitergeleitet werden kann... - ich möchte damit verhindern das die Mails lokal "liegen bleiben" Ist das mit postfix umsetzbar? Danke im Voraus!

3 2

Hosts in mynetworks sollen nur Absender Adressen aus relay_recipient_maps verwenden dürfen
by Wenger Florian 10 Sep '15

10 Sep '15

Hallo Postfix-Users Kann ich Postfix so konfigurieren, dass angeschlossene Mailserver (gelistet in mynetworks) über Postfix relayen dürfen, aber als Absenderadressen nur diese Adressen verwenden dürfen, welche auch in relay_recipient_maps angegeben sind? Zur Erklärung ein paar mehr Fakten... Ich bastle gerade an einem neuen Mailgateway meines Arbeitgebers. Debian 8.2 ,Postfix 2.11.3, Amavis, Spamassassin, usw... Auf diesem Server gibt es keine Mailboxen oder Mailuser. Alle eingehenden Mails (von Internet-Seite) werden an verschiedene Mailsysteme (intern) weitergeleitet. In einer MySQL-Tabelle sind alle gültigen Empfänger-Adressen aller angeschlossenen internen Mailsysteme hinterlegt. Postfix kennt alle Empfänger-Adressen der angeschlossenen Mailsysteme und nimmt nur diese an. SMTP-Auth (SASL) oder address_verify_map für relay_domains ist leider nicht möglich. relay_domains = proxy:mysql:/etc/postfix/relay_domains.mysql = Liste der Domains die nach intern weitergeleitet werden. relay_recipient_maps = proxy:mysql:/etc/postfix/relay_recipients.mysql = Liste aller Empfänger-Adressen der relay_domains smtpd_reject_unlisted_recipient = yes = Postfix nimmt unbekannte Empfänger nicht an. Dank smtpd_reject_unlisted_sender = yes können auch nur Absender Adressen von meinen relay_domains verwendet werden, wenn diese in relay_recipient_maps vorhanden sind. Beispiel: relay_domains dom1.example.org dom2.example.org relay_recipients user1(a)dom1.example.org user2(a)dom1.example.org user1(a)dom2.example.org user2(a)dom2.example.org Wenn ich nun E-Mails über diesen Mailserver ins Internet-verschicke (von intern nach extern), kann ich nur die Absenderadressen verwenden die in relay_recipients angeführt sind. Dies funktioniert aber nur wenn die Absender-Domain in relay_domains angeführt sind. Absender user1(a)dom1.example.org funktioniert user2(a)dom2.example.org funktioniert user3(a)dom1.example.org funktioniert nicht NOQUEUE: reject: 550 5.1.0 Sender address rejected: User unknown in relay recipient table; genau so möchte ich das haben. Da die "internen" Mailsysteme auch in mynetworks geführt werden, können diese Mailsysteme E-Mails verschicken, deren Absender komplett unbekannt sind. Absender user0815(a)anderedomain.com funktioniert, sofern diese Domain existiert (Dank reject_unknown_recipient_domain) Kann ich Postfix so kinfigurieren, dass auch hosts in mynetworks nur absender Adressen verwenden dürfen, welche in relay_recipient_maps angegeben sind. Und andernfalls die Nachrichten nicht annimmt. Noch ein paar ergänzende Einstellungen meiner main.cf relay_domains = proxy:mysql:/etc/postfix/relay_domains.mysql transport_maps = hash:/etc/postfix/transport, $relay_domains relay_recipient_maps = proxy:mysql:/etc/postfix/relay_recipients.mysql smtpd_reject_unlisted_sender = yes smtpd_reject_unlisted_recipient = yes smtpd_helo_restrictions = warn_if_reject reject_unknown_helo_hostname smtpd_sender_restrictions = reject_unknown_sender_domain smtpd_relay_restrictions = check_recipient_access hash:/etc/postfix/mxsysallow reject_unknown_recipient_domain permit_mynetworks, reject_unauth_destination smtpd_recipient_restrictions = permit_mynetworks, check_recipient_access hash:/etc/postfix/mxsysallow # reject_unauth_destination is not needed here if the mail # relay policy is specified under smtpd_relay_restrictions # (available with Postfix 2.10 and later). reject_unauth_destination, check_helo_access hash:/etc/postfix/helo_access, reject_rbl_client zen.spamhaus.org, reject_rhsbl_reverse_client dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org, reject_rhsbl_sender dbl.spamhaus.org check_policy_service inet:127.0.0.1:10023, check_policy_service unix:private/policy-spf, reject_rbl_client bl.spamcop.net, reject_rbl_client cbl.abuseat.org, --------------------------------- Folgendes habe ich auch schon probiert smtpd_relay_restrictions = check_recipient_access hash:/etc/postfix/mxsysallow reject_unknown_recipient_domain check_sender_access proxy:mysql:/etc/postfix/my_relay_senders.mysql, check_sender_access hash:/etc/postfix/my_special_relay_senders, REJECT, permit_mynetworks, reject_unauth_destination my_relay_senders.mysql ist eine Mysql-Abfrage auf die gleiche Tabelle, wie proxy:mysql:/etc/postfix/relay_recipients.mysql, Liefert aber OK wenn eine E-Mail Adresse matcht. Das Unschöne an dieser Lösung ist, dass "REJECT," im SMTP - Dialog ein 554 5.7.1 ...Recipient address rejected: Access denied; erzeugt, aber nicht über die falsche Absender-Adresse informiert. Vielleicht hat hier jemand eine Idee für meine Könfigurationswünsche MFG Flo

1 0

Mail von externen Servern abrufen
by Joachim Fahrner 05 Sep '15

05 Sep '15

Hallo, hat jemand einen Tipp mit welchem Tool man am besten/einfachsten Mails von externen POP3/IMAP-Postfächern abrufen kann? Google hat mir fetchmail und getmail ausgespuckt, aber ich habe keine Ahnung wie gut die für meine Umgebung geeignet sind. Mein Mailserver besteht aus Postfix und Dovecot mit virtuellen Nutzern (verwaltet über Postfixadmin). Es reicht wenn ich den Abruf als root einrichte, es ist nicht nötig dass jeder User das selber einrichten können soll. Es geht nur um ein Postfach meines Sohnes von der Uni, das er gerne in seinem normalen Postfach lesen möchte. Weiterleitung bietet die Uni leider nicht an. -- Mit besten Grüßen Joachim Fahrner PGP-Key: http://www.fahrner.name/JoachimFahrner.asc --------------------------------------------------- Es gibt keine Cloud. Es ist nur der Computer eines Anderen.

3 3

check-client-access-not-working ?
by Andre Hohmann 03 Sep '15

03 Sep '15

Hallo zusammen, ich habe immer noch keine Lösung für folgendes Problem: http://stackoverflow.com/questions/32270166/postfix-check-client-access-not… [1] Könnt ihr bitte mal schauen, ob ihr eine Idee habt? Hab die Einstellungen nun schon mehrfach überprüft und auch neu gesetzt, und kann mit immer noch nicht erklären, wo der Fehler liegt. Besten Dank! -- Mit freundlichen Grüssen Andre Hohmann Links: ------ [1] http://stackoverflow.com/questions/32270166/postfix-check-client-access-not…

4 5

Chunking / BDAT
by Philipp Resch 02 Sep '15

02 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Liste, mein Problem hat nicht direkt und ausschließlich mit Postfix zu tun, doch nachdem nun ein kompletter Tag des Forschens dahin ist dachte ich, ich frage mal hier: Kennt jemand einen MTA, der den RFC 3030 implementiert (BINARYMIME / CHUNKING) ? Alles was ich gefunden habe ist irgendein alter Fork von Qmail, und das will man ja eigentlich nicht. Gibt es vielleicht irgendeinen Patch für Postfix, den ich nur nicht gefunden habe? Kennt jemand den Grund, warum kein Mainstream MTA CHUNKING unterstützt, sonderlich kompliziert ist das ja eigentlich nicht... Hintergrund: Wir setzen auf einigen Server den PowerMTA von Port25 ein, haben jetzt aber für eine Applikation vor die Kosten etwas zu optimieren. Die Applikation hat für den Mailversand CHUNKING implementiert - das ließe sich sicherlich "ausbauen", schöner wäre aber wenn der neue MTA das auch unterstützt. Besten Dank schonmal, Philipp -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJV5z/qAAoJEC6sCbYfpzg9ieIH/2fPJoiOnhKZhp6COiAtgffs FPK4mgvvZX5+EHpgnkHfu7aL5YiR39QUw1K12jOCHV/IHcop6+JnzURYcb1abhm+ qQPddde3CvoFf77YWwGhYjXZtiGT7/nxzvHSVADs66fFROUewX0zefI9obhCzh9+ a99ISD84O/yOegt97DwgRArLF0ekR54P8S/O/p6IrmOm/wJDczsmaeDw4PbQacXp Ke+bNQVKjvkRWy1JHwOQgv+xiljGInfaaOnm2ec7PfuVRri5LyVVMELwYMa7qR2p nV4Yv8SfN3Gttres+YzIxPjd9D4cG4cbUZCE3ziA1QrRo5l2sU7TpQhdaGZkfLM= =4Y68 -----END PGP SIGNATURE-----

2 1