June 2013 - postfix-users

[postfix-users] Verständnisprobleme mit mydestination, virtual_alias_domains und virtual_mailbox_domains
by Hubert Schölnast 02 Jul '13

02 Jul '13

Hallo! Meine Frage vom 9.6. wurde nicht bearbeitet (siehe unten). Habe ich etwas falsch gemacht? Wenn Ja: Was muss ich anders machen? Wenn Nein: Ich bitte um Bearbeitung! Danke! Ich habe heute ihre Mailingliste aboniert. Ist ein solches Abo zwingend notwendig um Antworten zu erhalten? Wenn ja, sollten Sie das bitte auf http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users explizit hinschreiben. Ich verstehe den aktuellen Inhalt dieser Seite so, dass man auch Fragen einsenden kann ohne die Liste abonieren zu müssen. Warum gibt es kein deutsches Postfix-Forum, sondern nur diese umständliche Mailingliste? Oder habe ich das Forum (trotz intensiver Suche) nur nicht gefunden? Liebe Grüße Hubert Schölnast Hubert Schölnast schrieb am 09.06.13 21:48: > Hallo! > > > Ich habe Verständnisprobleme mit mydestination, virtual_alias_domains > und virtual_mailbox_domains und habe dazu 4 Fragen. > > Auf meinem Server gibt es nur einen einzigen User, der sich dort > einloggen kann, das ist root. Ein Webserver läuft dort bereits, nun > soll auch ein Mailserver folgen, meine Wahl fiel auf Postfix. > Betriebssystem = Ubuntu Precise Pangolin (12.04 LTS). Der Server ist > ein virtueller Server auf dem ich Root-Rechte habe, der aber 800 km > von mir entfernt im Ausland (nämlich in einer Serverfarm in > Deutschland) steht. Ich bin in Österreich (Wien) daheim. > > Der Server soll Zustellungs-Endpunkt für mehrere Domänen werden (ich > nenne sie hier firstserver.at, secondserver.at und thirdserver.at), > wobei jede Domäne ihre individuellen Mail-Accounts hat (nur virtuelle > E-Mail-User). Alle User haben mehrere Geräte mit denen Sie ihre Mails > verwalten (PC, Notebook, Tablet und Handy) und greifen auf Ihre > E-Mails daher via IMAP (oder besser IMAPS) zu. Alle User, die vial > IMAP auf den Server zugreifen dürfen, nutzen den Server auch als > Postausgangsserver. > > Dann gibt es noch lokale Unix-Prozesse (z.B. cron) die gelegentlich > E-Mails versenden. Alle lokal erzeugten E-Mails sollen an > admin(a)firstserver.at gehen. > > Postfix soll die Mails nicht selbst in Postfächer ablegen, sondern > diesen Job einem anderen Programm überlassen. Der Grund: Je nach > Inhalt sollen eingehende E-Mails in unterschiedliche Ordner > einsortiert werden. Beispielsweise soll es zur E-Mail Adresse > anton(a)firstserver.at die Ordner firstserver_anton_inbox, > firstserver_anton_spam_or_malware und > firstserver_anton_mails_von_berta geben. > > Soweit ich das grundlegende Konzept von Postfix verstanden habe, sind > alle meine Mail-User virtuelle Mail-User, denn keiner von ihnen hat > ein Unix-Account am Server. Daher mache ich diese Einträge in main.cf: > > virtual_mailbox_domains = hash:/etc/postfix/virtual_mailbox_domains > virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps > > Inhalt von virtual_mailbox_domains: > firstserver.at ok > secondserver.at ok > thirdserver.at ok > ... > > Inhalt von virtual_mailbox_maps (Dazu gibts im Anschluss gleich die > Frage 1): > anton(a)firstserver.at firstserver_anton > berta(a)firstserver.at firstserver_berta > clara(a)secondserver.at secondserver_clara > doris(a)thirdserver.at thirdserver_doris > ... > > Frage 1: > Ich weiß nicht genau, was ich in virtual_mailbox_maps wirklich auf den > rechten Seiten hinschreiben soll, denn da sollen ja die Ablageorte der > jeweiligen Konten stehen, aber Postfix legt die Mails selbst ja > nirgends ab, sondern leitet sie an ein anderes Programm weiter, das > dann die Ablage (nach einer Filterung) machen soll. > > Frage 2: > Mir ist auch unklar, ob ich mydestination leer lassen soll, oder ob > dort localhost eingetragen werden muss (wegen der E-Mails die von > lokalen Prozessen erzeugt werden können). Also > Entweder > mydestination = > oder > mydestination = localhost > Was ist richtig? > > > Vorbereitung auf Fragen 3 und 4: > Ich habe verstanden, dass ich allfällige Weiterleitungen in > virtual_alias_maps eintragen muss. Beispielsweise sollen alle E-Mails, > die an postmaster(a)secondserver.at und postmaster(a)thirdserver.at > gesendet werden, an postmaster(a)firstserver.at umgeleitet werden. Und > alles, was an postmaster(a)firstserver.at geht soll als Duplikat auch an > admin(a)firstserver.at weitergeleitet werden. > > Ich glaube, das geht so: > virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps > > Inhalt von virtual_alias_maps: > postmaster(a)secondserver.at postmaster(a)firstserver.at > postmaster(a)thirdserver.at postmaster(a)firstserver.at > postmaster(a)firstserver.at postmaster(a)firstserver.at, admin(a)firstserver.at > > Frage 3: > Kann ich mit diesem Eintrag > @localhost admin(a)firstserver.at > in virtual_alias_maps erreichen, dass alle E-Mails, die lokal am > Server entstehen, an admin(a)firstserver.at zugestellt werden? Wenn > nein: Wie sonst geht das? > > Frage 4: > Ich habe in mehreren Tutorials bezüglich virtual_alias_domains immer > wieder zwei widersprüchliche Aussagen gelesen, und weiß nicht was nun > richtig ist. > > Aussage 1: In virtual_alias_domains müssen alle Domains angegeben > sein, die in virtual_alias_maps bei den Adressen der linken Seite > vorkommen. Demzufolge müsste ich also angeben: > > virtual_alias_domains = firstserver.at secondserver.at thirdserver.at > > Aussage 2a: In virtual_mailbox_domains müssen alle Domains angegeben > sein, die in virtual_mailbox_maps bei den Adressen der linken Seite > vorkommen. > Aussage 2b: Jede Domain darf nur entweder in virtual_mailbox_domains > oder in virtual_alias_domains stehen, aber niemals in beiden. > Die Aussagen 2a und 2b fordern also, dass firstserver.at, > secondserver.at und thirdserver.at nicht in virtual_alias_domains > stehen dürfen, weil es E-Mail-Adressen aus diesen Domänen gibt, die in > virtual_mailbox_maps stehen. Also müsste ich entgegen der > Schlussfolgerung aus Aussage 1 virtual_alias_domains leer lassen. > > virtual_alias_domains = > > Dsa widerspricht aber dem, was aus Aussage 1 zu schließen ist. > Was ist nun richtig? > > > Liebe Grüße > Hubert Schölnast

6 24

[postfix-users] Verschiedene Ansätze, Mail zuzustellen (auch für Hubert Schölnast)
by Ralf Hildebrandt 01 Jul '13

01 Jul '13

Es gibt so im großen und ganzen zwei verschiedene Ansätze um einen IMAP Server (z.B. Dovecot oder Cyrus) anzubinden. Der eine Ansatz ist: * Domain in relay_domains auflisten (Postfix "relayed" das Zeug - nämlich zum LMTP-Server von cyrus oder dovecot, oder in einen transport hinein, der seinerseits eine PIPE aufruft) * Empfänger in relay_recipient_maps auflisten Internet --smtp--> Postfix --lmtp--> cyrus/dovecot Internet --smtp--> Postfix --pipe--> programm Vorteil: ======== * cyrus/dovecot kriegen Mails mit der vollen Emailadresse als Usernamen * d.h. man kann sich ohne Tricks mit seiner Emailadresse anmelden * die Mail im Transit hat auch immer dieselbe Adresse (keine Umschreibung nötig) Nachteil: ========= * irgendwoher muss die relay_recipient_maps Info kommen, am besten aus einer gemeinschaftlich genutzten Quelle von Postfix und cyrus/dovecot (Datenbank, LDAP, sowas...) Der andere Ansatz ist: * Domain in virtual_alias_domains auflisted, dann wird die Emailadresse auf irgendwas "umgeschrieben" (username4711@localhost) Und username4711@localhost wird dann irgendwie local zugestellt (dovecot-deliver, cyrus-deliver, pipe, sonstwas...) * Empfänger müssen dann in virtual_alias_maps auf die dem cyrus/dovecot bekannten Usernamen gemappt werden (damit die Mail korrekt ankommt) Vorteil: ======== * Alle Domains sind virtuell, bis auf EINE, und die eine ist die einzige, für die man die Zustellung dann konfigurieren muss. Nachteil: ========= * Im Transit ändert sich die Emailadresse irgendwann -- [*] sys4 AG http://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, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

3 3

[postfix-users] Ungewöhnliche Fehlermeldung "your DNS server is hosting spam provider"
by Hubert Schölnast 28 Jun '13

28 Jun '13

Hallo Uwe Drießen, ich schrieb dir gestern die untenstehende Antwort an deine persönliche E-Mail-Adresse (bei fblan.de), erhielt von deinem Mailserver aber diese Antwort: does not like recipient. Remote host said: 550 5.7.1 <hubert(a)schoelnast.at>: Sender address rejected: your DNS server is hosting spam provider( KEY-SYSTEMS ) Key-Systems bzw. http://www.domaindiscount24.com ist ein Domain-Name-Registrar mit vermutlich tausenden Kunden, die diesen Dienst nutzen, um ihre Domain-Names zu registrieren. Viele brave und anständige Webmaster, die nie auf die Idee kämen Spam zu versenden (darunter jener Freund, dessen Mailserver derzeit meine Mails verwaltet, und auch ich selbst), nutzen die Dienste dieses Registrars. Es kann gut sein, dass auch Spam-Schleudern ihre Domain-Namen dort gekauft haben, aber deswegen gleich alle Kunden des Registrars zu verbannen geht wohl etwas zu weit. Ich denke, dass die Firma Key-Systems auch wenig Möglichkeiten hat zu erkennen, welche Ihrer Kunden nicht ganz so sauber sind. Meine Meinung: Du schießt mit Kanonen auf Spatzen und machst einen Registrar schlecht, der nichts weiter tut als sein Geschäft auszuüben. Da ich dich per E-Mail offenbar nicht direkt erreichen kann, bleibt mir nichts anderes übrig, als dich mit Hilfe dieser Mailing-Liste davon in Kenntnis zu setzen. Übrigens habe ich in den ca. 10 Jahren, in denen ich meine E-Mail-Adresse nun schon habe, noch nie eine failur notice mit so einer seltsamen Begründung erhalten. Liebe Grüße Hubert Schölnast Hubert Schölnast schrieb am 26.06.13 16:06: > Hallo Uwe! > > Ad Postfixbücher: > Die Version aus dem Jahr 2004 liegt auf meinem Schreibtisch, ich habe > die Version aus 2008 im Buchhandel bestellt, aber sie ist vergriffen. > Die dritte Auflage (2013) ist noch nicht erhältlich. Ich habe die > Ausgabe aus 2004 mehrmals aufmerksam durchgelesen, fand aber auf die > hier gestellten Fragen dennoch keine Antwort. Ich habe mir bereits vor > etwa einem Jahr die Auflage von 2008 ausgeliehen und auch diese > durchgelesen. Schon damals waren mir die hier nachgefragten Punkte > unklar. > Das Buch "POP3 und IMAP" (von Heinlein u. Hartleben) in der aktuellen > Ausgabe besitze ich ebenfalls, es hilft beim fraglichen Problem aber > noch weniger weiter. > > Ad "das weiß man": > Wer ist "man"? Ich jedenfalls offenbar nicht. Es gibt also mindestens > eine Person, die das mit dem Abo-Zwang nicht verstanden hat. Das > heißt: Es besteht Verbesserungpotential. Der von mir vorgeschlagene > ausdrückliche Hinweis auf den Zwang die Liste zu abonieren wäre gut > geeignet dieses Potential auszuschöpfen. > > > LG > Hubert schölnast > > > Uwe Drießen schrieb am 26.06.13 15:31: >> Im Auftrag von Hubert Schölnast >>> Hallo! >>> >>> Meine Frage vom 9.6. wurde nicht bearbeitet (siehe unten). Habe ich >>> etwas falsch gemacht? Wenn Ja: Was muss ich anders machen? Wenn Nein: >>> Ich bitte um Bearbeitung! >> Die Liste ist eine FREIWILLIGE Leistung aller derer die die Liste >> abonniert >> haben. >> >> Du setzt eine FREIE Software ein, Das setzt voraus das du auch mal >> Google >> und das Archiv der Mailinglisten (dieser und der postfixbuch Liste auf >> listen.jpberlin.de) >> Durchforstet. >> Zu deinem Problem gibt es schon etliche Postings. >> >> Die Empfehlung eins oder besser Beide Postfixbücher (deutschsprachig) >> kaufen >> und Schritt für Schritt vorgehen. >> 1. bleiben dann nur ein Bruchteil deiner Fragen und Probleme übrig >> und man >> erkennt das du dich mit dem Thema auseinandergesetzt hast. >> 2. die meisten der hier Aktiven haben mal so angefangen >> 3. Grundwissen und Konfiguration kann gerne gegen Bezahlung eingekauft >> werden >> >>> Danke! >>> >>> Ich habe heute ihre Mailingliste aboniert. Ist ein solches Abo zwingend >>> notwendig um Antworten zu erhalten? Wenn ja, sollten Sie das bitte auf >>> http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users explizit >>> hinschreiben. Ich verstehe den aktuellen Inhalt dieser Seite so, dass >>> man auch Fragen einsenden kann ohne die Liste abonieren zu müssen. >> Das weis man! Die Antworten gehen immer an die Mailingliste und >> werden nur >> an die eingetragenen verteilt. >> >> >>> Warum gibt es kein deutsches Postfix-Forum, sondern nur diese >>> umständliche Mailingliste? Oder habe ich das Forum (trotz intensiver >>> Suche) nur nicht gefunden? >> Mach eins auf keiner hindert dich daran. >> Die Postfix admins die ich kenne kommunizieren nur hierüber. >> Für die ist es Umständlicher irgendwo ein Forum zu besuchen. >> Hier kommt die Info automatisch und wer das Thema Interessant findet >> wird >> sich dessen annehmen und auch mit diskutieren. >> >> >>> >>> Liebe Grüße >>> Hubert Schölnast >>> >>> >>> Hubert Schölnast schrieb am 09.06.13 21:48: >>>> Hallo! >>>> >>>> >>>> Ich habe Verständnisprobleme mit mydestination, virtual_alias_domains >>>> und virtual_mailbox_domains und habe dazu 4 Fragen. >>>> >>>> Auf meinem Server gibt es nur einen einzigen User, der sich dort >>>> einloggen kann, das ist root. Ein Webserver läuft dort bereits, nun >>>> soll auch ein Mailserver folgen, meine Wahl fiel auf Postfix. >>>> Betriebssystem = Ubuntu Precise Pangolin (12.04 LTS). Der Server ist >>>> ein virtueller Server auf dem ich Root-Rechte habe, der aber 800 km >>>> von mir entfernt im Ausland (nämlich in einer Serverfarm in >>>> Deutschland) steht. Ich bin in Österreich (Wien) daheim. >>>> >>>> Der Server soll Zustellungs-Endpunkt für mehrere Domänen werden (ich >>>> nenne sie hier firstserver.at, secondserver.at und thirdserver.at), >>>> wobei jede Domäne ihre individuellen Mail-Accounts hat (nur virtuelle >>>> E-Mail-User). Alle User haben mehrere Geräte mit denen Sie ihre Mails >>>> verwalten (PC, Notebook, Tablet und Handy) und greifen auf Ihre >>>> E-Mails daher via IMAP (oder besser IMAPS) zu. Alle User, die vial >>>> IMAP auf den Server zugreifen dürfen, nutzen den Server auch als >>>> Postausgangsserver. >>>> >>>> Dann gibt es noch lokale Unix-Prozesse (z.B. cron) die gelegentlich >>>> E-Mails versenden. Alle lokal erzeugten E-Mails sollen an >>>> admin(a)firstserver.at gehen. >>>> >>>> Postfix soll die Mails nicht selbst in Postfächer ablegen, sondern >>>> diesen Job einem anderen Programm überlassen. Der Grund: Je nach >>>> Inhalt sollen eingehende E-Mails in unterschiedliche Ordner >>>> einsortiert werden. Beispielsweise soll es zur E-Mail Adresse >>>> anton(a)firstserver.at die Ordner firstserver_anton_inbox, >>>> firstserver_anton_spam_or_malware und >>>> firstserver_anton_mails_von_berta geben. >>>> >>>> Soweit ich das grundlegende Konzept von Postfix verstanden habe, sind >>>> alle meine Mail-User virtuelle Mail-User, denn keiner von ihnen hat >>>> ein Unix-Account am Server. Daher mache ich diese Einträge in main.cf: >>>> >>>> virtual_mailbox_domains = hash:/etc/postfix/virtual_mailbox_domains >>>> virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps >>>> >>>> Inhalt von virtual_mailbox_domains: >>>> firstserver.at ok >>>> secondserver.at ok >>>> thirdserver.at ok >>>> ... >>>> >>>> Inhalt von virtual_mailbox_maps (Dazu gibts im Anschluss gleich die >>>> Frage 1): >>>> anton(a)firstserver.at firstserver_anton >>>> berta(a)firstserver.at firstserver_berta >>>> clara(a)secondserver.at secondserver_clara >>>> doris(a)thirdserver.at thirdserver_doris >>>> ... >>>> >>>> Frage 1: >>>> Ich weiß nicht genau, was ich in virtual_mailbox_maps wirklich auf den >>>> rechten Seiten hinschreiben soll, denn da sollen ja die Ablageorte der >>>> jeweiligen Konten stehen, aber Postfix legt die Mails selbst ja >>>> nirgends ab, sondern leitet sie an ein anderes Programm weiter, das >>>> dann die Ablage (nach einer Filterung) machen soll. >>>> >>>> Frage 2: >>>> Mir ist auch unklar, ob ich mydestination leer lassen soll, oder ob >>>> dort localhost eingetragen werden muss (wegen der E-Mails die von >>>> lokalen Prozessen erzeugt werden können). Also >>>> Entweder >>>> mydestination = >>>> oder >>>> mydestination = localhost >>>> Was ist richtig? >>>> >>>> >>>> Vorbereitung auf Fragen 3 und 4: >>>> Ich habe verstanden, dass ich allfällige Weiterleitungen in >>>> virtual_alias_maps eintragen muss. Beispielsweise sollen alle E-Mails, >>>> die an postmaster(a)secondserver.at und postmaster(a)thirdserver.at >>>> gesendet werden, an postmaster(a)firstserver.at umgeleitet werden. Und >>>> alles, was an postmaster(a)firstserver.at geht soll als Duplikat auch an >>>> admin(a)firstserver.at weitergeleitet werden. >>>> >>>> Ich glaube, das geht so: >>>> virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps >>>> >>>> Inhalt von virtual_alias_maps: >>>> postmaster(a)secondserver.at postmaster(a)firstserver.at >>>> postmaster(a)thirdserver.at postmaster(a)firstserver.at >>>> postmaster(a)firstserver.at postmaster(a)firstserver.at, >>> admin(a)firstserver.at >>>> Frage 3: >>>> Kann ich mit diesem Eintrag >>>> @localhost admin(a)firstserver.at >>>> in virtual_alias_maps erreichen, dass alle E-Mails, die lokal am >>>> Server entstehen, an admin(a)firstserver.at zugestellt werden? Wenn >>>> nein: Wie sonst geht das? >>>> >>>> Frage 4: >>>> Ich habe in mehreren Tutorials bezüglich virtual_alias_domains immer >>>> wieder zwei widersprüchliche Aussagen gelesen, und weiß nicht was nun >>>> richtig ist. >>>> >>>> Aussage 1: In virtual_alias_domains müssen alle Domains angegeben >>>> sein, die in virtual_alias_maps bei den Adressen der linken Seite >>>> vorkommen. Demzufolge müsste ich also angeben: >>>> >>>> virtual_alias_domains = firstserver.at secondserver.at thirdserver.at >>>> >>>> Aussage 2a: In virtual_mailbox_domains müssen alle Domains angegeben >>>> sein, die in virtual_mailbox_maps bei den Adressen der linken Seite >>>> vorkommen. >>>> Aussage 2b: Jede Domain darf nur entweder in virtual_mailbox_domains >>>> oder in virtual_alias_domains stehen, aber niemals in beiden. >>>> Die Aussagen 2a und 2b fordern also, dass firstserver.at, >>>> secondserver.at und thirdserver.at nicht in virtual_alias_domains >>>> stehen dürfen, weil es E-Mail-Adressen aus diesen Domänen gibt, die in >>>> virtual_mailbox_maps stehen. Also müsste ich entgegen der >>>> Schlussfolgerung aus Aussage 1 virtual_alias_domains leer lassen. >>>> >>>> virtual_alias_domains = >>>> >>>> Dsa widerspricht aber dem, was aus Aussage 1 zu schließen ist. >>>> Was ist nun richtig? >>>> >>>> >>>> Liebe Grüße >>>> Hubert Schölnast >> >> Mit freundlichen Grüßen >> >> Uwe Drießen >> -- >> Software & Computer >> Uwe Drießen >> Lembergstraße 33 >> 67824 Feilbingert >> >> Tel.: 06708660045 >> >> >> >

8 14

Re: [postfix-users] Ungewöhnliche Fehlermeldung "your DNS server is hosting spam provider"
by Hubert Schölnast 28 Jun '13

28 Jun '13

Uwe Drießen schrieb am 27.06.13 16:12: > Fein jetzt noch die Kommentarzeichen einfügen.... (>) Menno! Ihr sei aber schon ziemlich pingelig mit euren ungeschriebenen Regeln hier in dieser Mailingliste! Wollt ihr allen ernstes, das ich jetzt auch noch vor jede Zeile, die ich kommentiere, dieses Zeichen von Hand eintrage? Was denn noch alles??? Ihr solltet echt mal ernsthaft über ein Forum nachdenken, das diese mühsame Mailingliste ersetzt, denn dann hättet ihr all diese Sorgen nicht. Falls euer Webserver unter einer Linux-Version läuft, müsst ihr nur phpBB runterladen, es entpacken, ein paar Parameter einstellen, und fertig ist das Forum. Siehe https://www.phpbb.com. Das habt ihr innerhalb von 2 Stunden erledigt. Ich bin bei solchen Sachen immer extrem genau, vorsichtig und lieber etwas zu paranoid, und ich habe im Jahr 2006 4 Stunden gebraucht um ein Forum für meine damaligen Mit-Studenten aufzusetzen. In diesen 4 Stunden waren ein eigenes Logo und grundlegende Anpassungen des Layouts bereits enthalten. Da dieser Studiengang 2009 wieder zu Ende war, gibt es dieses Forum heute nicht mehr, daher kann ich es euch leider nicht zeigen. Mit einem Forum gibt es keine Probleme mit irgendwelchen Zitierregeln die außer euch keiner kennt, html-Probleme gibts auch keine, und es ist sowas von egal mit welchem Client (Browser) man sich das Forum anschaut. Ihr könnte Bereiche freischalten, wo jeder posten darf, und gleichzeitig auch Bereiche haben, wo nur registrierte User posten dürfen. Ihr behaltet die Kontrolle darüber, wer sich registrieren darf. Es ist sogar möglich, Bereiche zu haben, die ihr für eure interen Kommunikation nutzen könnt, ohne dass Unbeteiligte etwas davon mitbekommen (wobei ihr das vermutlich auch weiterhin mit einer Mailingliste lösen wollt, was bei einer kleiner Gruppe, deren Mitglieder sich kennen, auch eine gute Lösung ist). E-Mail ist ein ganz tolles Kommunikationsmedium, aber man sollte es dort verwenden, wo es sinnvoll ist. Für Anfragen von Benutzern aus aller Welt, die man der Öffentlichkeit zur Verfügung stellen will, ist es - meiner Meinung nach - das falsche Medium. Dafür sind Foren wesentlich besser geeignet. Ihr könnt euren Usern nicht vorschreiben, welche Clients (Browser bzw. MUAs) sie verwenden dürfen wenn sie Fragen zu der von euch betreuten Software haben. Und ihr könnt von Ihnen nicht verlangen, dass sie sich an Regeln halten, die innerhalb eurer Gruppe vielleicht als selbstverständlich gelten, die ihr aber nach außen hin nicht bekannt gemacht habt. Liebe Grüße Hubert Schölnast

11 17

[postfix-users] Erweiterte Konfiguration
by Mathias Reineke 26 Jun '13

26 Jun '13

Guten werte Mailinglisten Benutzer, ich habe letztendlich zwei relativ einfache Fragen, diesen geht allerdings eine recht lange Erklärung voraus, um die Rahmenbedingungen erschöpfend zu erleutern. Also bitte ich vorab um Entschuldigung für die leicht romanartigen Züge meines Beitrags Ich bin derzeit damit befasst ein kleines Mailsystem auf meiner Ubuntu-Box einzurichten. Die Box ist im Web unter der beispielhaften Domain "example.de", mit wechselnder IP, zu erreichen. Die erklärten ziele sind dabei: 1. Bereitstellung eines IMAP-Postfachs für verschiedene Nutzer, z.B. Füruser1(a)example.de (umgesetzt mit Dovecot) 2. Einsammeln der Mails aus verschiedenen Externen Postfächern pro Benutzer (z.b. Von user1myfirstidentity@web.de,mysecondidentity@googlemail.com; umgesetzt mittels Dovecot PostLoginScript und getmail) 3. Versenden von Mails über die Externen Postfächer (z.B. User1 kann über die Box als Absendermyfirstidentity(a)web.de verwenden, was dazu führt, dass die Mail über User1s Mailaccount bei Web.de geleitet wird; umzusetzen mit Postfix) (4.) Versand von @example.de Mails an externe Accounts soll nicht umgesetzt werden (z.b. Vonuser1(a)example.de anuser(a)de.postfix.org), dazu fehlt mir mindestens eine statische IP 5. Erzwungene Verschlüsselung der Verbindungen eines Benutzers zum den Komponenten des Mailsystems (dank verbreiteter Unterstützung von TLS in allen Komponenten ein Leichtes) Das so beschriebene Setup ist natürlich problemfrei umzusetzen. Jetzt folgt aber der schwierige Teil, nämlich die Randbedingungen zu den oben genannten Zielen: 1.a) Asymmetrische Verschlüsselung (PGP) aller Mails im Postfach des Benutzers 2.a) Pro Benutzer symmetrisch verschlüsselte Speicherung der Zugangsdaten zu den Externen Postfächern bzw. SMTP Servern 3.a) siehe 2.a) 5.a) die von den Benutzern zum Mailsystem übertragenen Anmeldedaten müssen in Klartext, oder mindestens in vorhersehbarer Form (bekannte Digest-Methode) vorliegen Diese Randbedingungen sollen es den Administratoren (ich bin nicht allein, und ich will auch nicht "aus Versehen" die Daten der Nutzer sehen können) und vor allem eventuellen Einbrechern erschweren die Mail- beziehungsweise Zugangsdaten der einzelnen Benutzer einzusehen. Ich schreibe "erschweren", da am Ende ein super user mindestens die Zugangsdaten lesen können wird, dazu aber in den Prozess der Mailzustellung eingreifen muss. Mir ist kein Ansatz eingefallen, die Daten meiner Benutzer noch stärker zu sichern, leider. Randbedingung 1.a) wird von Dovecot mit pro Benutzer verwalteten PGP Schlüsseln, beim einsortieren der Mails, umgesetzt werden (Evaluierung steht noch aus, zu förderst muss das Relaying an externe SMTP Server funktionieren). Randbedingung 2.a) basiert erneut auf Dovecot. Dovecot ermöglicht es über Prefetch-Queries das Klartextpasswort der sich gerade angemeldeten Benutzer kurz vorzuhalten und eine über die "Post Login Script" Funktionalität ausgelöste Aktion auszuführen. Somit ist es mir möglich, bei der Anmeldung eines Benutzers, seine mit seinem Box-Passwort verschlüsselten Zugangsdaten zu den externen Postfächern zu holen und zu entschlüsseln, und damit getmail zu füttern. Getmail stellt dann die Mails der externen Postfächer dem Benutzer zu (hier ist ein Ansatzpunkt für einen Einbrecher mit super user Rechten, da dieser das Post Login Script manipulieren kann, oder aber die Nutzerdaten aus dem getmail Prozess auszulesen vermag). Das ganze ist transparent für den Benutzer und funktioniert wunderbar (transparent in dem Sinne, dass der Benutzer eh erst sieht, dass er neue Mails hat, wenn es sich anmeldet, und nicht bemerkt [von einer k leine Verzögerung abgesehen], dass die Mails erst in diesem Moment eingesammelt werden). Nun folgen die eigentliche Probleme. 3. Ist mit Postfix und dessen sender_based_relay_maps sowie sender_restrictions pro Benutzer (ein Benutzer darf nur @example.de und seine externen Adressen als Absender angeben) sehr schön umzusetzen. Die Schwierigkeit liegt bei der Randbedingung 3.a). Ich benötige eine Möglichkeit, im Kontext des Sendens einer Mail über Postfix an das Klartextpasswort des Benutzer heranzukommen, um damit das Ergebnis des sender_based_relay Lookups zu modifizieren (Entschlüsselung der gespeicherten Daten entsprechend 2.a)). Frage 1: Gibt es ist Postfix eine Möglichkeit das Ergebnis des sender_based_relay Lookups mit dem Klartextpasswort aus der SMTP Anmeldung zu vermischen? Beim sender_based_relay-ing ergibt sich, in meiner Installation, ein weiteres Problem. Sollte der Postfix die Mail nicht sofort zum Zielserver (beispielsweise dem SMTP vom Web.de) zustellen können, wird er dies später erneut versuchen. Dazu benötigt er dann "später" die Zugangsdaten des Benutzers zum externen Server, befindet sich aber nicht mehr im Kontext der Anmeldung des Benutzers, und hat somit auch nicht mehr dessen Klartextpasswort zur Verfügung. Der Schlüssel, der für die Entschlüsselung der Zugangsdaten benötigt wird, muss bis zum erfolgreichen Zustellen (oder zum letztendlichen Aufgeben der Zustellung) der Mail vorgehalten werden. (Alternativ könnte die Mail in diesem Moment abgelehnt werden.) Darum Frage 2: ist es möglich, Postfix spezielle Informationen in den Envelope einer sich in der "ausgehenden" Queue befindlichen Mail zu schreiben, und diese beim Zustellungsversuch zur Manipulation der Relay-Lookups zu verwenden? Mit Envelope meine ich an dieser Stelle den Satz an Verwaltungsdaten, den Postfix für die Zustellung einer Mail verwendet, und der in keinem Fall jemals in einer Mail auftaucht, weder bei erfolgreicher Zustellung noch bei Bounce noch bei Benachrichtigung des Postmasters über unzustellbare Mails. (An dieser Stelle sei angemerkt, dass dann das Klartextpasswort des Benutzers, oder besser eine Ableitung davon, temporär auf der Festplatte gespeichert würde, was es einem Angreifer mit super user Rechten ermöglichte, dies zu lesen.) Sind jemandem von Ihnen Ansätze bekannt, die zugrunde liegenden Probleme von Frage 1 und Frage 2 zu lösen? Erneut muss ich mich entschuldigen, dass dieser Beitrag recht lang ist, jedoch denke ich, dass dies durch die Komplexität des entstehenden Systems bedingt ist. Ich hoffen meine Ausführungen ermöglichen eine Einordnung und bestenfalls positive Beantwortung meiner Fragen. Haben Sie vorab schon vielen Dank für die Beschäftigung mit meinen Fragen. Mit freundlichen Grüszen, Mathias Reineke

2 6

[postfix-users] Erweiterte Konfiguration
by Mathias Reineke 26 Jun '13

26 Jun '13

Guten Tag werte Mailinglisten Benutzer, ich habe letztendlich zwei relativ einfache Fragen, diesen geht allerdings eine recht lange Erklärung voraus, um die Rahmenbedingungen erschöpfend zu erleutern. Also bitte ich vorab um Entschuldigung für die leicht romanartigen Züge meines Beitrags Ich bin derzeit damit befasst ein kleines Mailsystem auf meiner Ubuntu-Box einzurichten. Die Box ist im Web unter der beispielhaften Domain "example.de", mit wechselnder IP, zu erreichen. Die erklärten ziele sind dabei: 1. Bereitstellung eines IMAP-Postfachs für verschiedene Nutzer, z.B. Füruser1(a)example.de (umgesetzt mit Dovecot) 2. Einsammeln der Mails aus verschiedenen Externen Postfächern pro Benutzer (z.b. Von user1myfirstidentity@web.de,mysecondidentity@googlemail.com; umgesetzt mittels Dovecot PostLoginScript und getmail) 3. Versenden von Mails über die Externen Postfächer (z.B. User1 kann über die Box als Absendermyfirstidentity(a)web.de verwenden, was dazu führt, dass die Mail über User1s Mailaccount bei Web.de geleitet wird; umzusetzen mit Postfix) (4.) Versand von @example.de Mails an externe Accounts soll nicht umgesetzt werden (z.b. Vonuser1(a)example.de anuser(a)de.postfix.org), dazu fehlt mir mindestens eine statische IP 5. Erzwungene Verschlüsselung der Verbindungen eines Benutzers zum den Komponenten des Mailsystems (dank verbreiteter Unterstützung von TLS in allen Komponenten ein Leichtes) Das so beschriebene Setup ist natürlich problemfrei umzusetzen. Jetzt folgt aber der schwierige Teil, nämlich die Randbedingungen zu den oben genannten Zielen: 1.a) Asymmetrische Verschlüsselung (PGP) aller Mails im Postfach des Benutzers 2.a) Pro Benutzer symmetrisch verschlüsselte Speicherung der Zugangsdaten zu den Externen Postfächern bzw. SMTP Servern 3.a) siehe 2.a) 5.a) die von den Benutzern zum Mailsystem übertragenen Anmeldedaten müssen in Klartext, oder mindestens in vorhersehbarer Form (bekannte Digest-Methode) vorliegen Diese Randbedingungen sollen es den Administratoren (ich bin nicht allein, und ich will auch nicht "aus Versehen" die Daten der Nutzer sehen können) und vor allem eventuellen Einbrechern erschweren die Mail- beziehungsweise Zugangsdaten der einzelnen Benutzer einzusehen. Ich schreibe "erschweren", da am Ende ein super user mindestens die Zugangsdaten lesen können wird, dazu aber in den Prozess der Mailzustellung eingreifen muss. Mir ist kein Ansatz eingefallen, die Daten meiner Benutzer noch stärker zu sichern, leider. Randbedingung 1.a) wird von Dovecot mit pro Benutzer verwalteten PGP Schlüsseln, beim einsortieren der Mails, umgesetzt werden (Evaluierung steht noch aus, zu förderst muss das Relaying an externe SMTP Server funktionieren). Randbedingung 2.a) basiert erneut auf Dovecot. Dovecot ermöglicht es über Prefetch-Queries das Klartextpasswort der sich gerade angemeldeten Benutzer kurz vorzuhalten und eine über die "Post Login Script" Funktionalität ausgelöste Aktion auszuführen. Somit ist es mir möglich, bei der Anmeldung eines Benutzers, seine mit seinem Box-Passwort verschlüsselten Zugangsdaten zu den externen Postfächern zu holen und zu entschlüsseln, und damit getmail zu füttern. Getmail stellt dann die Mails der externen Postfächer dem Benutzer zu (hier ist ein Ansatzpunkt für einen Einbrecher mit super user Rechten, da dieser das Post Login Script manipulieren kann, oder aber die Nutzerdaten aus dem getmail Prozess auszulesen vermag). Das ganze ist transparent für den Benutzer und funktioniert wunderbar (transparent in dem Sinne, dass der Benutzer eh erst sieht, dass er neue Mails hat, wenn es sich anmeldet, und nicht bemerkt [von einer k leine Verzögerung abgesehen], dass die Mails erst in diesem Moment eingesammelt werden). Nun folgen die eigentliche Probleme. 3. Ist mit Postfix und dessen sender_based_relay_maps sowie sender_restrictions pro Benutzer (ein Benutzer darf nur @example.de und seine externen Adressen als Absender angeben) sehr schön umzusetzen. Die Schwierigkeit liegt bei der Randbedingung 3.a). Ich benötige eine Möglichkeit, im Kontext des Sendens einer Mail über Postfix an das Klartextpasswort des Benutzer heranzukommen, um damit das Ergebnis des sender_based_relay Lookups zu modifizieren (Entschlüsselung der gespeicherten Daten entsprechend 2.a)). Frage 1: Gibt es ist Postfix eine Möglichkeit das Ergebnis des sender_based_relay Lookups mit dem Klartextpasswort aus der SMTP Anmeldung zu vermischen? Beim sender_based_relay-ing ergibt sich, in meiner Installation, ein weiteres Problem. Sollte der Postfix die Mail nicht sofort zum Zielserver (beispielsweise dem SMTP vom Web.de) zustellen können, wird er dies später erneut versuchen. Dazu benötigt er dann "später" die Zugangsdaten des Benutzers zum externen Server, befindet sich aber nicht mehr im Kontext der Anmeldung des Benutzers, und hat somit auch nicht mehr dessen Klartextpasswort zur Verfügung. Der Schlüssel, der für die Entschlüsselung der Zugangsdaten benötigt wird, muss bis zum erfolgreichen Zustellen (oder zum letztendlichen Aufgeben der Zustellung) der Mail vorgehalten werden. (Alternativ könnte die Mail in diesem Moment abgelehnt werden.) Darum Frage 2: ist es möglich, Postfix spezielle Informationen in den Envelope einer sich in der "ausgehenden" Queue befindlichen Mail zu schreiben, und diese beim Zustellungsversuch zur Manipulation der Relay-Lookups zu verwenden? Mit Envelope meine ich an dieser Stelle den Satz an Verwaltungsdaten, den Postfix für die Zustellung einer Mail verwendet, und der in keinem Fall jemals in einer Mail auftaucht, weder bei erfolgreicher Zustellung noch bei Bounce noch bei Benachrichtigung des Postmasters über unzustellbare Mails. (An dieser Stelle sei angemerkt, dass dann das Klartextpasswort des Benutzers, oder besser eine Ableitung davon, temporär auf der Festplatte gespeichert würde, was es einem Angreifer mit super user Rechten ermöglichte, dies zu lesen.) Sind jemandem von Ihnen Ansätze bekannt, die zugrunde liegenden Probleme von Frage 1 und Frage 2 zu lösen? Erneut muss ich mich entschuldigen, dass dieser Beitrag recht lang ist, jedoch denke ich, dass dies durch die Komplexität des entstehenden Systems bedingt ist. Ich hoffen meine Ausführungen ermöglichen eine Einordnung und bestenfalls positive Beantwortung meiner Fragen. Haben Sie vorab schon vielen Dank für die Beschäftigung mit meinen Fragen. Mit freundlichen Grüszen, Mathias Reineke

2 2

[postfix-users] SMTP AUTH mit Cyrus SASL und auxprop
by Andreas Hahne 22 Jun '13

22 Jun '13

Guten Tag, zur Zeit versuche ich, auf einem Ubuntu-System (10.04) einen Postfix-Mailserver einzurichten und zur externen Authentifizierung Cyrus SASL zu verwenden. Bei der Konfiguration habe ich mich nach dem Buch "Postfix" von Ralf Hildebrandt und Patrick Ben Koetter gerichtet. Bis zum Einrichten von Cyrus hatte ich dabei auch keine Probleme, leider scheitere ich jetzt bei der Authentifizierung mit der Passwort-Check-Methode auxprop gegen eine MySQL-Datenbank. Die fehlenden Log-Ausgaben von MySQL sprechen in meinen Augen dafür, dass gar keine SQL-Anfrage an die DB gesendet wird (manuelle SQL-Anfragen werden geloggt). Hier komme ich bei meiner Fehlersuche allerdings nicht weiter. Daher habe ich die Ausgaben von saslfinger angehängt und hoffe, dass mir jemand weiterhelfen kann. Ich muss gestehen, dass ich nach langem Probieren den Versuch abgebrochen habe, den Sample-Server/Client zu testen, da zwischen Client und Server überhaupt keine Kommunikation zustande kam. Offenbar sind die Kommandozeilenparameter der Ubuntu-Packages grundsätzlich andere als bei der im Buch verwendeten Variante. Grüße Andreas

2 1

[postfix-users] Kann man die receipents_map umgehen?
by Martin Rabl 11 Jun '13

11 Jun '13

Hallo, ich habe einen (vorgelagerten) Postfix-Server, der anhand einer receipents_map prüft, ob er eine Mail an eine bestimmte Mailadresse auf den eigentliche Postfix weiterleitet - das funktioniert sehr gut. Jetzt allerdings soll eine neue Bedingung dazu kommen: leite alle Mails "nach innen" weiter, ohne auf einen Empfänger in der receipents_map zu prüfen, aber nur dann, wenn diese Mail von einem bestimmten Server kommt. Ich habe den "vertrauenswürdigen" Server, der alles an alle einliefern darf, bereits in mynetworks eingetragen, die Annahme von Mails wird aber für unbekannte Adressen verweigert. Zur Eräuterung: "unbekannte" Adressen sind in unserem Wording "interne" Adressen, die nur im Hause genutzt werden und von außen nicht erreichbar sind - es sei denn, sie werden von einem bestimmten client kommend eingeliefert. Habt ihr einen Tipp? Danke, Martin

3 5