From t.schneider at tms-itdienst.at Thu Aug 6 09:58:34 2015 From: t.schneider at tms-itdienst.at (Timm Schneider) Date: Thu, 06 Aug 2015 09:58:34 +0200 Subject: mailman umgezogen - listen importieren Message-ID: <55C313AA.2090003@tms-itdienst.at> Hallo, ich habe mailman auf einen anderen Server umgezogen, welcher auch eine andere distri hat, also von openSuSe auf Debian-wheezy. Mailman startet, aber auf der Webseite werden keine Listen angezeigt. die Verzeichnisse mit den Listen habe ich kopiert, aber wie teile ich nun mailman mit, das er diese findet und anzeigt? Grüße Timm -- TMS IT-Dienst Hinterstadt 2 4840 Vöcklabruck(VB) Austria T(AT).+43.720.501 078(kostenlos per ENUM erreichbar) T(DE).+49.89.721010 77792 T(CH).+41.32.510 9875 F.+43.720.501 078 57 Das Stammzertifikat finden Sie unter www.cacert.org/index.php?id=3 From igor.sverkos at gmail.com Thu Aug 13 16:50:33 2015 From: igor.sverkos at gmail.com (Igor Sverkos) Date: Thu, 13 Aug 2015 16:50:33 +0200 Subject: Connection Cache bei TLS - Was macht ihr bei Rate-Limits? Message-ID: Hallo, über unser Mailsystem ging letzte Woche ein größeres Mailing heraus. Darunter ~130.000 @t-online.de-Empfänger. Es kam dabei - und nur bei T-Online - oft zu "Maximum parallel connections for your IP-Address reached" Fehlern. Mich wunderte die Anzahl an Verbindungen bis ich lernte, dass bei TLS, der Postfix-Verbindungscache gar nicht greift (siehe "Connection Cache Limitation" auf http://www.postfix.org/CONNECTION_CACHE_README.html). Das macht zwar schon Sinn, der Umstand war für mich aber neu. Wie habt ihr das gelöst? Kennt ihr das Problem gar nicht? Habt ihr generell smtp_destination_concurrency_limit gesetzt oder arbeitet ihr mit Transportmaps und setzt die Limits nur für bestimmte Ziele? Ich Grüße, Igor From Christian.Schmidt at chemie.uni-hamburg.de Thu Aug 13 17:41:59 2015 From: Christian.Schmidt at chemie.uni-hamburg.de (Christian Schmidt) Date: Thu, 13 Aug 2015 17:41:59 +0200 Subject: mailman umgezogen - listen importieren In-Reply-To: <55C313AA.2090003@tms-itdienst.at> References: <55C313AA.2090003@tms-itdienst.at> Message-ID: <55CCBAC7.4000403@chemie.uni-hamburg.de> Hallo Timm, On 06.08.2015 09:58, Timm Schneider wrote: > ich habe mailman auf einen anderen Server umgezogen, welcher auch eine > andere distri hat, also von openSuSe auf Debian-wheezy. > > Mailman startet, aber auf der Webseite werden keine Listen angezeigt. > die Verzeichnisse mit den Listen habe ich kopiert, aber wie teile ich > nun mailman mit, das er diese findet und anzeigt? Hilft Dir Schritt 4.3 von https://www.debian-administration.org/article/567/Migrating_mailman_lists weiter? Mit freundlichen Grüßen Christian Schmidt -- No signature available. -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 5306 bytes Beschreibung: S/MIME Cryptographic Signature URL : From t.schneider at tms-itdienst.at Thu Aug 13 18:24:57 2015 From: t.schneider at tms-itdienst.at (Timm Schneider) Date: Thu, 13 Aug 2015 18:24:57 +0200 Subject: mailman umgezogen - listen importieren In-Reply-To: <55CCBAC7.4000403@chemie.uni-hamburg.de> References: <55C313AA.2090003@tms-itdienst.at> <55CCBAC7.4000403@chemie.uni-hamburg.de> Message-ID: <55CCC4D9.7080505@tms-itdienst.at> Hallo Christian, Du meinst der Name wird aus einem PTR erzeugt? Das könnte natürlich vom Namen her sein, da ich das System noch nicht produktiv einsetze, d.h. noch läuft mailman auf dem "alten" Server. Ich wollte erst "umziehen" wenn alles auf dem Neuen läuft. Danke Timm > Hilft Dir Schritt 4.3 von > https://www.debian-administration.org/article/567/Migrating_mailman_lists weiter? > > Mit freundlichen Grüßen > Christian Schmidt > From Christian.Schmidt at chemie.uni-hamburg.de Thu Aug 13 19:20:42 2015 From: Christian.Schmidt at chemie.uni-hamburg.de (Christian Schmidt) Date: Thu, 13 Aug 2015 19:20:42 +0200 Subject: mailman umgezogen - listen importieren In-Reply-To: <55CCC4D9.7080505@tms-itdienst.at> References: <55C313AA.2090003@tms-itdienst.at> <55CCBAC7.4000403@chemie.uni-hamburg.de> <55CCC4D9.7080505@tms-itdienst.at> Message-ID: <55CCD1EA.2000301@chemie.uni-hamburg.de> On 13.08.2015 18:24, Timm Schneider wrote: > Du meinst der Name wird aus einem PTR erzeugt? > Das könnte natürlich vom Namen her sein, da ich das System noch nicht > produktiv einsetze, d.h. noch läuft mailman auf dem "alten" Server. > Ich wollte erst "umziehen" wenn alles auf dem Neuen läuft. Entschuldige, ich habe Tomaten auf den Augen. Ich meine natürlich Abschnitt 4.2 - mit dem "withlist"-Befehl, Die Adresse https://www.debian-administration.org/article/567/Migrating_mailman_lists stimmt aber. ;-) Mit freundlichen Grüßen Christian Schmidt -- No signature available. -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 5306 bytes Beschreibung: S/MIME Cryptographic Signature URL : From daniel at ist-immer-online.de Sat Aug 15 16:54:23 2015 From: daniel at ist-immer-online.de (Daniel) Date: Sat, 15 Aug 2015 16:54:23 +0200 Subject: AW: TLS_cipherlist vs. TLS_ciphers In-Reply-To: <55B6795F.1060000@mldsc.de> References: <55B6795F.1060000@mldsc.de> Message-ID: <005201d0d76a$4645d030$d2d17090$@ist-immer-online.de> Hi, ich habe in meiner Konfig eher einfaches gefunden wie smtpd_tls_mandatory_exclude_ciphers = aNULL, RC4 smtpd_tls_exclude_ciphers = aNULL, RC4 smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 Deine angepassten Parameter sehen besser bzw. konkreter aus. Was ist mit TLS 1.0, sollte es nicht auch verweigert wegen wegen der Beast Atacke? Wieso sollte es also nun am besten aussehen in der Konfig? Gruß Daniel Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Matthias Doering Gesendet: Montag, 27. Juli 2015 20:33 An: postfixbuch-users at listen.jpberlin.de Betreff: TLS_cipherlist vs. TLS_ciphers Hallo Liste. Ich habe noch Probleme bei Postfix zu erkennen welcher Default-Parameter von welchem angepassten Parameter überschrieben wird/ werden kann. Bsp.: Angepasste Parameter: tls_high_cipherlist = aNULL:-aNULL:RC4-SHA:ALL:@STRENGTH smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA smtpd_tls_protocols = !SSLv2 !SSLv3 smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA Mit dieser Konfiguration sollte man ja die höchstmögliche Sicherheit in Punkto TLS erreichen. Soweit sehe Ich das jetzt mal als eine korrekte Annahme an. Freue mich aber gerne über Hinweise wie man da mehr Sicherheit rein bekommt ;) Jetzt gibt es solche Default Parameter: lmtp_tls_ciphers = export smtp_tls_ciphers = export smtpd_tls_ciphers = export tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH Woher kann Ich jetzt wissen das diese Werte mit den obigen außer Kraft gesetzt werden wenn das so ist? Ich überschreibe ja nicht diese Werte sondern "ähnliche" äquivalente Parameter. Wie kann Ich jetzt ohne ein Test herausfinden ob das jetzt wirklich so ist wie Ich mir das denke? Ich will das nur die high_cipherlist genutzt wird für max. Sicherheit aber, was ist mit (smtpd_tls_ciphers, smtp_tls_ciphers, lmtp_tls_ciphers) werden diese komplette ignoriert? Wenn ja, wieso (Zusammenhang)? Testen kann man das ja so auch nur bedingt. Wer kennt schon wirklich alle Fälle die hier eintreten können? -- Mit freundlichen Grüßen Matthias Döring -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From daniel at ist-immer-online.de Mon Aug 17 05:42:42 2015 From: daniel at ist-immer-online.de (Daniel) Date: Mon, 17 Aug 2015 05:42:42 +0200 Subject: AW: TLS_cipherlist vs. TLS_ciphers References: <55B6795F.1060000@mldsc.de> Message-ID: <006901d0d89e$c6065300$5212f900$@ist-immer-online.de> Hi, ich habe auf https://www.rootforum.org/forum/viewtopic.php?t=54550 folgendes gefunden für Postfix: smtp_tls_ciphers = medium smtp_tls_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL smtp_tls_mandatory_ciphers = medium smtp_tls_mandatory_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_security_level = may smtp_use_tls = yes smtpd_tls_auth_only = yes smtpd_tls_ciphers = medium smtpd_tls_eecdh_grade = strong smtpd_tls_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL smtpd_tls_mandatory_ciphers = medium smtpd_tls_mandatory_exclude_ciphers = CAMELLIA, RC4, 3DES, IDEA, SEED, PSK, SRP, DSS, eNULL, aNULL smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_use_tls = yes tls_daemon_random_bytes = 64 tls_high_cipherlist = EECDH+AES256 EECDH+AES128 EDH+AES256 EDH+AES128 tls_medium_cipherlist = EECDH+AES256 EECDH+AES128 EDH+AES256 EDH+AES128 EECDH EDH tls_preempt_cipherlist = yes tls_random_bytes = 64 tls_ssl_options = NO_COMPRESSION Was ist denn nun am besten zu empfehlen nach Heartbleed, Poodle und Beast? Gruß Daniel Von: Daniel [mailto:daniel at ist-immer-online.de] Gesendet: Samstag, 15. August 2015 16:54 An: 'Diskussionen und Support rund um Postfix' Betreff: AW: TLS_cipherlist vs. TLS_ciphers Hi, ich habe in meiner Konfig eher einfaches gefunden wie smtpd_tls_mandatory_exclude_ciphers = aNULL, RC4 smtpd_tls_exclude_ciphers = aNULL, RC4 smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 Deine angepassten Parameter sehen besser bzw. konkreter aus. Was ist mit TLS 1.0, sollte es nicht auch verweigert wegen wegen der Beast Atacke? Wieso sollte es also nun am besten aussehen in der Konfig? Gruß Daniel Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Matthias Doering Gesendet: Montag, 27. Juli 2015 20:33 An: postfixbuch-users at listen.jpberlin.de Betreff: TLS_cipherlist vs. TLS_ciphers Hallo Liste. Ich habe noch Probleme bei Postfix zu erkennen welcher Default-Parameter von welchem angepassten Parameter überschrieben wird/ werden kann. Bsp.: Angepasste Parameter: tls_high_cipherlist = aNULL:-aNULL:RC4-SHA:ALL:@STRENGTH smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA smtpd_tls_protocols = !SSLv2 !SSLv3 smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA Mit dieser Konfiguration sollte man ja die höchstmögliche Sicherheit in Punkto TLS erreichen. Soweit sehe Ich das jetzt mal als eine korrekte Annahme an. Freue mich aber gerne über Hinweise wie man da mehr Sicherheit rein bekommt ;) Jetzt gibt es solche Default Parameter: lmtp_tls_ciphers = export smtp_tls_ciphers = export smtpd_tls_ciphers = export tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH Woher kann Ich jetzt wissen das diese Werte mit den obigen außer Kraft gesetzt werden wenn das so ist? Ich überschreibe ja nicht diese Werte sondern "ähnliche" äquivalente Parameter. Wie kann Ich jetzt ohne ein Test herausfinden ob das jetzt wirklich so ist wie Ich mir das denke? Ich will das nur die high_cipherlist genutzt wird für max. Sicherheit aber, was ist mit (smtpd_tls_ciphers, smtp_tls_ciphers, lmtp_tls_ciphers) werden diese komplette ignoriert? Wenn ja, wieso (Zusammenhang)? Testen kann man das ja so auch nur bedingt. Wer kennt schon wirklich alle Fälle die hier eintreten können? -- Mit freundlichen Grüßen Matthias Döring -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From j_adam at web.de Mon Aug 17 09:07:10 2015 From: j_adam at web.de (Jens Adam) Date: Mon, 17 Aug 2015 09:07:10 +0200 Subject: TLS_cipherlist vs. TLS_ciphers In-Reply-To: <006901d0d89e$c6065300$5212f900$@ist-immer-online.de> References: <55B6795F.1060000@mldsc.de> <006901d0d89e$c6065300$5212f900$@ist-immer-online.de> Message-ID: <20150817090710.20111b3c@titan.byte.cx> Mon, 17 Aug 2015 05:42:42 +0200 "Daniel" : > ich habe auf > folgendes gefunden für Postfix: Ja, Internet ist toll, da findet man so einiges; die Problematik der OpenSSL-Einrichtung ist aber generell und nicht auf Postfix bezogen. Wenn man sich schon etwas länger mit diesem ganzen Snowden/Security/SSL-Krams beschäftigt, landet man weniger bei Forenpostings, sondern bei einem knappen Dutzend an Seiten, die meistens auch ordentlich gepflegt werden, z.B.: - https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ viele Erklärungen/Links und ein Changelog - https://wiki.mozilla.org/Security/Server_Side_TLS seehr ausführlich, natürlich mit einem starken Fokus auf Webserver - https://weakdh.org/sysadmin.html Fokus auf 'LogJam' und Copy+Paste, bis auf die Cipherlist (wer benutzt schon DSS- oder ECDSA-Zertifikate) schön knapp gehalten - https://cipherli.st/ noch knapper, wenn Kompromisse bzgl. Kompatibilität egal sind - https://starttls.info/ Online-Check für Mailserver, nicht sehr ausführlich aber ganz nett Wenn man jetzt genug Grundwissen zusammen hat, um beurteilen zu können, wie sich diese How-Tos in ihren Schwerpunkten unterscheiden und man sich sein Setup zurechtgelegt/kopiert hat, bleibt aber trotzdem noch die Frage, inwiefern das für einen Standardmailserver überhaupt relevant ist. Bei meinen Webserver, dem Jabberserver und auch Dovecot kann ich davon ausgehen, dass alle potentiellen Clients (Start)TLS verstehen, und das auch problemlos forcieren (Zwangsumleitung, HSTS, etc), aber solange man einen MX im Internet betreibt sollte man sich im Klaren sein, dass *bessere* Crypto im Zweifelsfall eher *keine* Crypto bedeutet, wenn die Gegenseite die Cipher-Auswahl nicht akzeptiert und einfach unverschlüsselt anliefert. Gruß, Jens -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 455 bytes Beschreibung: Digitale Signatur von OpenPGP URL : From buettnerp at web.de Mon Aug 17 09:55:47 2015 From: buettnerp at web.de (=?UTF-8?B?UGV0ZXIgQsO8dHRuZXI=?=) Date: Mon, 17 Aug 2015 09:55:47 +0200 Subject: delivery notifications, DANE Message-ID: <55D19383.9090300@web.de> Hallo, seit 14 Tagen versuche ich nach den Anleitungen aus dem Postfix Buch einen Mailserver aufzusetzen. Wichtig war mir die Möglichkeit, DANE Security abzufragen und ein MX-Backup. Postfix 2.11 Alles klappte wunderbar: Nur unix-accounts. TLS , Amavisd+Clamd+ Sammassassin+policy-weight+greylisting. Versenden über mynetworks mit dane-only lief einwandfrei. Eingehende Mails wurden nach Konfiguration abgearbeitet. Was nicht funktionierte ist DSN. Das funktioniert nur, wenn ich direkt auf der Konsole über den sendmail-wrapper sende. Hat jemand eine Idee, wie man DSN einschaltet? Dann habe ich den Rest installiert, um zu testen ob DSN mit Domains funktioniert, für die sich Posfix zuständig fühlt. +Mysql, +Dovecot, +Postfixadmin. Eine virtuelle Domain. Danach musste ich Amavisd auf 127.0.0.1 binden, damit der Dienst überhaupt startet. Muß wohl irgend ein IPv6 Problem dazu gekommen sein. Ich kann Mails über Tunderbird versenden und abrufen. Dane Abfragen funktionieren nun nicht mehr und von delivery notifications immer noch keine Spur. In der Googlewelt haben alle ein Problem damit, DSN auszuschalten. Ich möchte DSN aber gerne haben. Hat jemand eine Idee, was ich falsch mache? Besten Dank im Voraus. Peter Büttner From jost+lists at dimejo.at Mon Aug 17 10:26:12 2015 From: jost+lists at dimejo.at (Alex JOST) Date: Mon, 17 Aug 2015 10:26:12 +0200 Subject: TLS_cipherlist vs. TLS_ciphers In-Reply-To: <20150817090710.20111b3c@titan.byte.cx> References: <55B6795F.1060000@mldsc.de> <006901d0d89e$c6065300$5212f900$@ist-immer-online.de> <20150817090710.20111b3c@titan.byte.cx> Message-ID: <55D19AA4.9060804@dimejo.at> Am 17.08.2015 um 09:07 schrieb Jens Adam: > Mon, 17 Aug 2015 05:42:42 +0200 > "Daniel" : > >> ich habe auf >> folgendes gefunden für Postfix: > > Ja, Internet ist toll, da findet man so einiges; die Problematik der > OpenSSL-Einrichtung ist aber generell und nicht auf Postfix bezogen. > Wenn man sich schon etwas länger mit diesem ganzen > Snowden/Security/SSL-Krams beschäftigt, landet man weniger bei > Forenpostings, sondern bei einem knappen Dutzend an Seiten, die > meistens auch ordentlich gepflegt werden, z.B.: > > - https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ > viele Erklärungen/Links und ein Changelog > - https://wiki.mozilla.org/Security/Server_Side_TLS > seehr ausführlich, natürlich mit einem starken Fokus auf Webserver > - https://weakdh.org/sysadmin.html > Fokus auf 'LogJam' und Copy+Paste, bis auf die Cipherlist (wer > benutzt schon DSS- oder ECDSA-Zertifikate) schön knapp gehalten > - https://cipherli.st/ > noch knapper, wenn Kompromisse bzgl. Kompatibilität egal sind > - https://starttls.info/ > Online-Check für Mailserver, nicht sehr ausführlich aber ganz nett > > Wenn man jetzt genug Grundwissen zusammen hat, um beurteilen zu können, > wie sich diese How-Tos in ihren Schwerpunkten unterscheiden und man sich > sein Setup zurechtgelegt/kopiert hat, bleibt aber trotzdem noch die > Frage, inwiefern das für einen Standardmailserver überhaupt relevant ist. > Bei meinen Webserver, dem Jabberserver und auch Dovecot kann ich davon > ausgehen, dass alle potentiellen Clients (Start)TLS verstehen, und das > auch problemlos forcieren (Zwangsumleitung, HSTS, etc), aber solange man > einen MX im Internet betreibt sollte man sich im Klaren sein, dass > *bessere* Crypto im Zweifelsfall eher *keine* Crypto bedeutet, wenn die > Gegenseite die Cipher-Auswahl nicht akzeptiert und einfach > unverschlüsselt anliefert. > > Gruß, > Jens > Warum folgt ihr nicht einfach der Empfehlung von Viktor Dukhovni auf der Postfix Mailingliste? http://marc.info/?l=postfix-users&m=143884497605106&w=2 -- Alex JOST From daniel at ist-immer-online.de Mon Aug 17 16:18:04 2015 From: daniel at ist-immer-online.de (Daniel) Date: Mon, 17 Aug 2015 16:18:04 +0200 Subject: AW: TLS_cipherlist vs. TLS_ciphers In-Reply-To: <20150817090710.20111b3c@titan.byte.cx> References: <55B6795F.1060000@mldsc.de> <006901d0d89e$c6065300$5212f900$@ist-immer-online.de> <20150817090710.20111b3c@titan.byte.cx> Message-ID: <003c01d0d8f7$8876e780$9964b680$@ist-immer-online.de> Hallo Jens, bin schon froh mit meinem keinen Mailserver für mich und noch paar Leuten zurecht zukommen mit dem meisten Sachen. Sprich Logs auswerten, Missbrauch prüfen, openrelay ect. DNSBL pflegen, sa-updates ect. pp. Die Feinheiten der einzelnen SSL/TLS Varianten ist nicht so ganz meins in der Tiefe. Was kann man den sonst empfehlen für eine Konfiguration, um möglichst hohe Sicherheit zu haben, seitens der Schwachstellen wie in SSL1 und 2 sowie TLS 1.0. Auf https://weakdh.org/sysadmin.html habe ich nur eine Zeile gefunden für Cipher. Dort steht auch was für Dovecot, wieso muss man da was mit SSL einpflegen? Darüber lasse ich nur Mails verschieben nach entsprechenden Regeln im einzelnen Postfach. Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Jens Adam Gesendet: Montag, 17. August 2015 09:07 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: TLS_cipherlist vs. TLS_ciphers Mon, 17 Aug 2015 05:42:42 +0200 "Daniel" : > ich habe auf > folgendes gefunden für Postfix: Ja, Internet ist toll, da findet man so einiges; die Problematik der OpenSSL-Einrichtung ist aber generell und nicht auf Postfix bezogen. Wenn man sich schon etwas länger mit diesem ganzen Snowden/Security/SSL-Krams beschäftigt, landet man weniger bei Forenpostings, sondern bei einem knappen Dutzend an Seiten, die meistens auch ordentlich gepflegt werden, z.B.: - https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ viele Erklärungen/Links und ein Changelog - https://wiki.mozilla.org/Security/Server_Side_TLS seehr ausführlich, natürlich mit einem starken Fokus auf Webserver - https://weakdh.org/sysadmin.html Fokus auf 'LogJam' und Copy+Paste, bis auf die Cipherlist (wer benutzt schon DSS- oder ECDSA-Zertifikate) schön knapp gehalten - https://cipherli.st/ noch knapper, wenn Kompromisse bzgl. Kompatibilität egal sind - https://starttls.info/ Online-Check für Mailserver, nicht sehr ausführlich aber ganz nett Wenn man jetzt genug Grundwissen zusammen hat, um beurteilen zu können, wie sich diese How-Tos in ihren Schwerpunkten unterscheiden und man sich sein Setup zurechtgelegt/kopiert hat, bleibt aber trotzdem noch die Frage, inwiefern das für einen Standardmailserver überhaupt relevant ist. Bei meinen Webserver, dem Jabberserver und auch Dovecot kann ich davon ausgehen, dass alle potentiellen Clients (Start)TLS verstehen, und das auch problemlos forcieren (Zwangsumleitung, HSTS, etc), aber solange man einen MX im Internet betreibt sollte man sich im Klaren sein, dass *bessere* Crypto im Zweifelsfall eher *keine* Crypto bedeutet, wenn die Gegenseite die Cipher-Auswahl nicht akzeptiert und einfach unverschlüsselt anliefert. Gruß, Jens From daniel at ist-immer-online.de Tue Aug 18 12:44:53 2015 From: daniel at ist-immer-online.de (Daniel) Date: Tue, 18 Aug 2015 12:44:53 +0200 Subject: AW: TLS_cipherlist vs. TLS_ciphers In-Reply-To: <20150817090710.20111b3c@titan.byte.cx> References: <55B6795F.1060000@mldsc.de> <006901d0d89e$c6065300$5212f900$@ist-immer-online.de> <20150817090710.20111b3c@titan.byte.cx> Message-ID: <000801d0d9a2$eac3bc50$c04b34f0$@ist-immer-online.de> Hi, nochmal nen Nachtrag, war wohl gestern nicht ganz Anwesend, dovecot ist ja für IMAP, und Mails verschieben ist Procmail, daher macht es mit den SSL Einstellungen für Dovecot auch sinn. Gruß Daniel ========== Hallo Jens, bin schon froh mit meinem keinen Mailserver für mich und noch paar Leuten zurecht zukommen mit dem meisten Sachen. Sprich Logs auswerten, Missbrauch prüfen, openrelay ect. DNSBL pflegen, sa-updates ect. pp. Die Feinheiten der einzelnen SSL/TLS Varianten ist nicht so ganz meins in der Tiefe. Was kann man den sonst empfehlen für eine Konfiguration, um möglichst hohe Sicherheit zu haben, seitens der Schwachstellen wie in SSL1 und 2 sowie TLS 1.0. Auf https://weakdh.org/sysadmin.html habe ich nur eine Zeile gefunden für Cipher. Dort steht auch was für Dovecot, wieso muss man da was mit SSL einpflegen? Darüber lasse ich nur Mails verschieben nach entsprechenden Regeln im einzelnen Postfach. Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Jens Adam Gesendet: Montag, 17. August 2015 09:07 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: TLS_cipherlist vs. TLS_ciphers Mon, 17 Aug 2015 05:42:42 +0200 "Daniel" : > ich habe auf > folgendes gefunden für Postfix: Ja, Internet ist toll, da findet man so einiges; die Problematik der OpenSSL-Einrichtung ist aber generell und nicht auf Postfix bezogen. Wenn man sich schon etwas länger mit diesem ganzen Snowden/Security/SSL-Krams beschäftigt, landet man weniger bei Forenpostings, sondern bei einem knappen Dutzend an Seiten, die meistens auch ordentlich gepflegt werden, z.B.: - https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ viele Erklärungen/Links und ein Changelog - https://wiki.mozilla.org/Security/Server_Side_TLS seehr ausführlich, natürlich mit einem starken Fokus auf Webserver - https://weakdh.org/sysadmin.html Fokus auf 'LogJam' und Copy+Paste, bis auf die Cipherlist (wer benutzt schon DSS- oder ECDSA-Zertifikate) schön knapp gehalten - https://cipherli.st/ noch knapper, wenn Kompromisse bzgl. Kompatibilität egal sind - https://starttls.info/ Online-Check für Mailserver, nicht sehr ausführlich aber ganz nett Wenn man jetzt genug Grundwissen zusammen hat, um beurteilen zu können, wie sich diese How-Tos in ihren Schwerpunkten unterscheiden und man sich sein Setup zurechtgelegt/kopiert hat, bleibt aber trotzdem noch die Frage, inwiefern das für einen Standardmailserver überhaupt relevant ist. Bei meinen Webserver, dem Jabberserver und auch Dovecot kann ich davon ausgehen, dass alle potentiellen Clients (Start)TLS verstehen, und das auch problemlos forcieren (Zwangsumleitung, HSTS, etc), aber solange man einen MX im Internet betreibt sollte man sich im Klaren sein, dass *bessere* Crypto im Zweifelsfall eher *keine* Crypto bedeutet, wenn die Gegenseite die Cipher-Auswahl nicht akzeptiert und einfach unverschlüsselt anliefert. Gruß, Jens From hans.moser at ofd-z.niedersachsen.de Thu Aug 20 11:54:49 2015 From: hans.moser at ofd-z.niedersachsen.de (Marc Patermann) Date: Thu, 20 Aug 2015 11:54:49 +0200 Subject: OT: "T-Online" Spam-Welle Message-ID: <55D5A3E9.5040206@ofd-z.niedersachsen.de> Hallo, von der aktuellen Spam-Welle "von T-Online" hat ja wahrscheinlich schon jeder gehört. Ich habe eine Bekannte, die ebenso diese Mails seit Ende letzter Woche "verschickt" - auch an mich. Warum da lauter mir bekannte Adressen im Empfängerkreis waren, habe ich mich gleich gewundert. Über den Versand der Mails müssen wir uns nicht groß unterhalten, das ist ja eher der normale Spam-Wahnsinn. Aber woher kommen die Adressen? Ich habe etwas den Überblick über die Erkenntnisse verloren. Ich hatte gedacht, sie hat sich da was auf ihrem Rechner eingefangen, das wollte ich mir heute mal ansehen. Es sah bisher auch so aus, als ob die Mails immer dann verschickt wurden, wenn sie mit dem Notebook online war. Mittlerweile häufen sich aber die Aussagen von anderen, dass sie auf ihren Rechnern nichts gefunden hätten. Sie wollte den Rechner auslassen und dennoch kamen heute Nacht Mails. Daher gehe ich davon aus, dass sich die Quelle - wenn sie überhaupt jemals auf dem Notebook war nun - woanders befindet. Wenn die Daten im großen Stil direkt aus den Mail-Konten oder sogar aus dem SMTP-Traffic abgefischt und immer den richtigen Absender zugeordnet worden wären, wäre das schon eine schwerwiegende Sache - auch für die Telekom. Marc From Sven.Lieckfeldt at planethome.com Thu Aug 20 12:03:55 2015 From: Sven.Lieckfeldt at planethome.com (Lieckfeldt, Sven) Date: Thu, 20 Aug 2015 10:03:55 +0000 Subject: AW: "T-Online" Spam-Welle In-Reply-To: <55D5A3E9.5040206@ofd-z.niedersachsen.de> References: <55D5A3E9.5040206@ofd-z.niedersachsen.de> Message-ID: Hi Marc, also bei Heise steht das hier: "Unbekannte haben E-Mail-Adressen aus Adressbüchern von T-Online-Konten gekapert und versenden in deren Namen Spam-Mails." Quelle: http://www.heise.de/newsticker/meldung/Deutsche-Telekom-warnt-vor-Spam-Welle-2786008.html Die Frage die Ich mir stelle, der Artikel aber noch nicht beantworten kann: Wie sind diese Unbekannten an diese Adressbücher von T-Online-Konten gekommen? Bei den ganzen Hacks auf Plattformen verliere Ich langsam den Überblick, aber an was größeres bei der Telekom kann Ich mich gerade nicht erinnern; oder es kommt die nächsten Tage raus. Schöne Grüße, Sven -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Marc Patermann Gesendet: Donnerstag, 20. August 2015 11:55 An: postfixbuch-users at listen.jpberlin.de Betreff: OT: "T-Online" Spam-Welle Hallo, von der aktuellen Spam-Welle "von T-Online" hat ja wahrscheinlich schon jeder gehört. Ich habe eine Bekannte, die ebenso diese Mails seit Ende letzter Woche "verschickt" - auch an mich. Warum da lauter mir bekannte Adressen im Empfängerkreis waren, habe ich mich gleich gewundert. Über den Versand der Mails müssen wir uns nicht groß unterhalten, das ist ja eher der normale Spam-Wahnsinn. Aber woher kommen die Adressen? Ich habe etwas den Überblick über die Erkenntnisse verloren. Ich hatte gedacht, sie hat sich da was auf ihrem Rechner eingefangen, das wollte ich mir heute mal ansehen. Es sah bisher auch so aus, als ob die Mails immer dann verschickt wurden, wenn sie mit dem Notebook online war. Mittlerweile häufen sich aber die Aussagen von anderen, dass sie auf ihren Rechnern nichts gefunden hätten. Sie wollte den Rechner auslassen und dennoch kamen heute Nacht Mails. Daher gehe ich davon aus, dass sich die Quelle - wenn sie überhaupt jemals auf dem Notebook war nun - woanders befindet. Wenn die Daten im großen Stil direkt aus den Mail-Konten oder sogar aus dem SMTP-Traffic abgefischt und immer den richtigen Absender zugeordnet worden wären, wäre das schon eine schwerwiegende Sache - auch für die Telekom. Marc From wn at neessen.net Thu Aug 20 12:09:24 2015 From: wn at neessen.net (Winfried Neessen) Date: Thu, 20 Aug 2015 12:09:24 +0200 Subject: AW: "T-Online" Spam-Welle In-Reply-To: References: <55D5A3E9.5040206@ofd-z.niedersachsen.de> Message-ID: <98770b8f7af210c578a5c208f0c38e44@neessen.net> Hi, Am 2015-08-20 12:03, schrieb Lieckfeldt, Sven: > Die Frage die Ich mir stelle, der Artikel aber noch nicht beantworten > kann: Wie sind > diese Unbekannten an diese Adressbücher von T-Online-Konten gekommen? > Schuss ins Blaue... User sind mal wieder auf eine der 100.000 Fakemails reingefallen, haben das Attachment geoeffnet und sich einen Trojaner installiert. Die letzten Varianten die bei uns reingeflattert sind, waren genau solche Varianten die die Festplatte nach bekannter Software durchsuchen (Firefox, Thunderbird, FTP Programme, etc.) und daraus die Zugangsdaten ausgelesen haben. Die Daten werden dann vom Trojaner an die "Unbekannten" geschickt und dort gesammelt. Winni From hans.moser at ofd-z.niedersachsen.de Thu Aug 20 15:58:25 2015 From: hans.moser at ofd-z.niedersachsen.de (Marc Patermann) Date: Thu, 20 Aug 2015 15:58:25 +0200 Subject: "T-Online" Spam-Welle In-Reply-To: <98770b8f7af210c578a5c208f0c38e44@neessen.net> References: <55D5A3E9.5040206@ofd-z.niedersachsen.de> <98770b8f7af210c578a5c208f0c38e44@neessen.net> Message-ID: <55D5DD01.6050008@ofd-z.niedersachsen.de> Hallo, Am 20.08.2015 um 12:09 Uhr schrieb Winfried Neessen: > Am 2015-08-20 12:03, schrieb Lieckfeldt, Sven: > >> Die Frage die Ich mir stelle, der Artikel aber noch nicht beantworten >> kann: Wie sind >> diese Unbekannten an diese Adressbücher von T-Online-Konten gekommen? >> > > Schuss ins Blaue... User sind mal wieder auf eine der 100.000 > Fakemails > reingefallen, haben das Attachment geoeffnet und sich einen Trojaner > installiert. möglich. Die aktuellen Berichte zeigen aber, dass der Trojaner dann quasi alle Betriebssysteme gleichsam befallen können müsste und reihenweise auf den "betroffenen Rechnern" nichts gefunden wurde. So einfach scheint es diesmal nicht zu sein. Dass der Zusammenhang mutmaßlicher Absender und Empfängerkreis in den Mails erhalten bleibt, ist mir so auch neu. Marc From driessen at fblan.de Thu Aug 20 16:43:22 2015 From: driessen at fblan.de (=?UTF-8?Q?Uwe_Drie=C3=9Fen?=) Date: Thu, 20 Aug 2015 16:43:22 +0200 Subject: AW: "T-Online" Spam-Welle In-Reply-To: <55D5DD01.6050008@ofd-z.niedersachsen.de> References: <55D5A3E9.5040206@ofd-z.niedersachsen.de> <98770b8f7af210c578a5c208f0c38e44@neessen.net> <55D5DD01.6050008@ofd-z.niedersachsen.de> Message-ID: <006001d0db56$91f83e60$b5e8bb20$@fblan.de> Im Auftrag von Marc Patermann > Die aktuellen Berichte zeigen aber, dass der Trojaner dann quasi alle > Betriebssysteme gleichsam befallen können müsste und reihenweise auf den > "betroffenen Rechnern" nichts gefunden wurde. > So einfach scheint es diesmal nicht zu sein. Nunja das Antivirensoftware nicht alles Findet und auch erstmal etwas benötigt das erkannt wurde das es schädliches Verhalten oder eben ausspioniert hat ... Ob da auf den Rechner was gefunden wurde oder auch nicht ist nicht ausschlaggebend Trojaner gibt es zu tausende die noch nie erkannt wurden weil zum einen gut zum anderen eben nicht mit der Brechstange arbeiten und direkt etwas kaputt machen Man merkt es in der Regel wenn Konto gehackt und PW geändert dennoch sofort der Versand wieder weiter geht Und wer sagt denn das das auf den Rechnern gehackt wurde ?? Alle mal die Hand heben die Ihre Mails auf dem Tablet und oder Handy auch empfangen ... Irgendwann zuletzt mal eine MMS bekommen ? mit einem Link drin und da ging ein Bild auf ?? So langsam muss man auch da 3 Dimensional anfangen zu denken.. > > Dass der Zusammenhang mutmaßlicher Absender und Empfängerkreis in den > Mails erhalten bleibt, ist mir so auch neu. > > > Marc Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From wn at neessen.net Thu Aug 20 16:54:09 2015 From: wn at neessen.net (Winfried Neessen) Date: Thu, 20 Aug 2015 16:54:09 +0200 Subject: "T-Online" Spam-Welle In-Reply-To: <55D5DD01.6050008@ofd-z.niedersachsen.de> References: <55D5A3E9.5040206@ofd-z.niedersachsen.de> <98770b8f7af210c578a5c208f0c38e44@neessen.net> <55D5DD01.6050008@ofd-z.niedersachsen.de> Message-ID: Hi, Am 2015-08-20 15:58, schrieb Marc Patermann: > Die aktuellen Berichte zeigen aber, dass der Trojaner dann quasi alle > Betriebssysteme > gleichsam befallen können müsste und reihenweise auf den "betroffenen > Rechnern" > nichts gefunden wurde. > Nunja, alles was wir hier machen ist Spekulation. Aber es ist nunmal so, dass a) immernoch auf sehr vielen Rechnern kein System zur Malware Erkennung/-Abwehr vorhanden ist und das b) A/V Systeme halt immer Blacklist-basiert sind - sprich sie erkennen nur, wenn die Malware schom vom A/V Software Hersteller in die Signaturdatei eingepflegt wurde. Und ja, es gibt schon genug Malware Varianten, die sowohl fuer Windows als fuer Mac verfuegbar sind. Und gerade im Mac-Umfeld ist es ja immernoch an der Tagesordnung zu sagen: "Fuer Macs gibts keine Viren". Die von mir untersuchten Varianten wurden zu dem Zeitpunkt als sie bei uns ankamen nur von 3 von 54 Antivirenprogrammen erkannt. Zudem waren Varianten dabei, die nicht persistent waren. Sie haben den Rechner abgegrast, die Daten verschickt und sich dann selbst entfernt. Kann man also nicht so ganz verallgemeinern. Auch kommt natuerlich dazu, dass die "Unbekannten" die gesammelten Daten nicht umbedingt sofort verwerten sondern erstmal "auf Halde legen" und dann irgendwann gezielt auf einen Schlag in Massen einsetzen. Aber wie schon gesagt, alles nur Spekulationen. Was wirklich passiert ist, kann man z. Zt. wohl nicht sagen, ich denke aber persoenlich nicht, dass dieser Vorfall (nur weil diesmal halt T-Online Adressen betroffen waren) etwas Besonderes ist, sondern sich mit den ueblichen Faellen von Datendiebstahl einreihen kann. Winni From max.grobecker at ml.grobecker.info Fri Aug 21 23:08:54 2015 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Fri, 21 Aug 2015 23:08:54 +0200 Subject: "T-Online" Spam-Welle In-Reply-To: <55D5DD01.6050008@ofd-z.niedersachsen.de> References: <55D5A3E9.5040206@ofd-z.niedersachsen.de> <98770b8f7af210c578a5c208f0c38e44@neessen.net> <55D5DD01.6050008@ofd-z.niedersachsen.de> Message-ID: <55D79366.3030004@ml.grobecker.info> Ola! Am 20.08.2015 um 15:58 schrieb Marc Patermann: > Die aktuellen Berichte zeigen aber, dass der Trojaner dann quasi alle Betriebssysteme gleichsam befallen können müsste und reihenweise auf den "betroffenen Rechnern" nichts gefunden wurde. > So einfach scheint es diesmal nicht zu sein. Was durchaus im Kommen ist, sind irgendwelche obskuren Browser-Addons, die irgendeine tolle Funktion anbieten/vorgaukeln, aber auf allen Seiten die der Benutzer besucht nach URLs und E-Mail-Adressen angeln. Teilweise werden auch Cookies direkt mitkopiert. Da eine Gemeinsamkeit die Nutzung der Weboberfläche von T-Online zu sein scheint wäre das (von einem ernsthaften Sicherheitsproblem bei der Telekom mal abgesehen) eine durchaus plausible Erklärung. Der "Vorteil" dieser Addons ist, dass sie tatsächlich unter praktisch allen Betriebssystemen laufen und teilweise auch auf Tablets installierbar sind. Wie das in den Browser des Nutzers gelangt bleibt sein Geheimnis, aber in der Regel werden die entweder in gutem Glauben installiert oder kommen ungefragt mit irgendwelcher anderen Software mit. Wenn ich da an die Toolbar-Galerie bei meinem Vater denke.... *grusel* Einer der bekannteren Fälle war z.B. "Awesome Screenshot", die irgendwann angefangen haben alle besuchten URLs und Cookies zum Anbieter rauszutragen. Ich könnte mir daher im aktuellen Fall sehr gut ein verbreitetes Addon vorstellen, was derartiges Tracking betreibt. Im Zweifel auch, dass irgendeinem halbgaren Anbieter dieser Plugins die Datenbank aufgemacht wurde. Bietet die Telekom eigentlich eine Schnittstelle an (entweder offen oder für ihre Apps), mit der man innerhalb einer Smartphone-App oder z.B. Outlook via Exchange Zugriff auf das Adressbuch hat? Dann reichen im Prinzip wirklich einfach geknackte Kennwörter, um mal eben mit wenig Aufwand die Adressbücher zu kopieren. Ich habe bisher keine derartigen Spam-Mails bekommen, obwohl ich mehrere @t-online.de-Nutzer kenne, denen ich auch zutrauen würde, dass deren System einmal von vorne bis hinten mit irgendwelcher Schadsoftware vollgestopft ist. Entweder betrifft das wirklich nur einen relativ kleinen Teil der Nutzer oder mein Spamfilter-Setup ist patentreif ;-) Viele Grüße aus dem Tal Max -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 819 bytes Beschreibung: OpenPGP digital signature URL : From klaus at tachtler.net Sun Aug 23 08:37:50 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Sun, 23 Aug 2015 08:37:50 +0200 Subject: Frage zu check_policy_service... Message-ID: <20150823083750.Horde.8Q0Oor5SISOfcsXokj0U2n6@buero.tachtler.net> Hallo, lt. Dovecot Buch (ja ein wenig "off topic") sollte check_policy_service = inet:imap.example.com:12340 am ENDE der smptd_recipient_restrictions (vor permit, natürlich) stehen (Dovecot-Buch: Seite 221). Laut "Wietse Venema's" Beschreibung hier: http://www.postfix.org/SMTPD_ACCESS_README.html#lists könnte dies aber auch so aussehen: # Enforce mail volume quota via policy service callouts. smtpd_end_of_data_restrictions = check_policy_service unix:private/policy Frage: Ist es denn schon richtig, in den smptd_recipient_restrictions den Policy-Service (Quota) aus Dovecot zu befragen, da bei einer Prüfung in smptd_recipient_restrictions die --> Größe <-- der gerade zur Einlieferung anstehenden E-Mail noch gar nicht bekannt ist. Dies wäre doch erst nach der Übermittlung der Daten nach smtpd_end_of_data_restrictions der Fall? Wäre dann nicht die Prüfung via Policy-Service (Quota) aus Dovecot nicht in smtpd_end_of_data_restrictions sinnvoller? Danke, Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From p at sys4.de Sun Aug 23 09:27:39 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Sun, 23 Aug 2015 09:27:39 +0200 Subject: Frage zu check_policy_service... In-Reply-To: <20150823083750.Horde.8Q0Oor5SISOfcsXokj0U2n6@buero.tachtler.net> References: <20150823083750.Horde.8Q0Oor5SISOfcsXokj0U2n6@buero.tachtler.net> Message-ID: <20150823072739.GA3771@sys4.de> * Klaus Tachtler : > Hallo, > > lt. Dovecot Buch (ja ein wenig "off topic") sollte > > check_policy_service = inet:imap.example.com:12340 > > am ENDE der smptd_recipient_restrictions (vor permit, natürlich) > stehen (Dovecot-Buch: Seite 221). > > Laut "Wietse Venema's" Beschreibung hier: > http://www.postfix.org/SMTPD_ACCESS_README.html#lists könnte dies > aber auch so aussehen: > > # Enforce mail volume quota via policy service callouts. > smtpd_end_of_data_restrictions = check_policy_service unix:private/policy > > Frage: Ist es denn schon richtig, in den > smptd_recipient_restrictions den Policy-Service (Quota) aus Dovecot > zu befragen, da bei einer Prüfung in smptd_recipient_restrictions > die --> Größe <-- der gerade zur Einlieferung anstehenden E-Mail > noch gar nicht bekannt ist. Dies wäre doch erst nach der > Übermittlung der Daten nach smtpd_end_of_data_restrictions der Fall? > > Wäre dann nicht die Prüfung via Policy-Service (Quota) aus Dovecot > nicht in smtpd_end_of_data_restrictions sinnvoller? Ja, das wäre sinnvoller. Davor bist Du auf die Size-Angabe des Clients im "MAIL FROM" angewiesen, wenn er denn das RFC unterstützt und sich daran hält. Wir trauen dem Client lieber nicht und finden es lieber selbst heraus - am Ende der DATA Phase. Dann kann Postfix die Grösse der Nachricht selbst berechnen. p at rick -- [*] 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 From klaus at tachtler.net Sun Aug 23 09:36:30 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Sun, 23 Aug 2015 09:36:30 +0200 Subject: Frage zu check_policy_service... In-Reply-To: <20150823072739.GA3771@sys4.de> References: <20150823083750.Horde.8Q0Oor5SISOfcsXokj0U2n6@buero.tachtler.net> <20150823072739.GA3771@sys4.de> Message-ID: <20150823093630.Horde.tkSiOEuHG45CQUmiCSJlo8z@buero.tachtler.net> Hallo Patrick, > * Klaus Tachtler : >> Hallo, >> >> lt. Dovecot Buch (ja ein wenig "off topic") sollte >> >> check_policy_service = inet:imap.example.com:12340 >> >> am ENDE der smptd_recipient_restrictions (vor permit, natürlich) >> stehen (Dovecot-Buch: Seite 221). >> >> Laut "Wietse Venema's" Beschreibung hier: >> http://www.postfix.org/SMTPD_ACCESS_README.html#lists könnte dies >> aber auch so aussehen: >> >> # Enforce mail volume quota via policy service callouts. >> smtpd_end_of_data_restrictions = check_policy_service >> unix:private/policy >> >> Frage: Ist es denn schon richtig, in den >> smptd_recipient_restrictions den Policy-Service (Quota) aus Dovecot >> zu befragen, da bei einer Prüfung in smptd_recipient_restrictions >> die --> Größe <-- der gerade zur Einlieferung anstehenden E-Mail >> noch gar nicht bekannt ist. Dies wäre doch erst nach der >> Übermittlung der Daten nach smtpd_end_of_data_restrictions der Fall? >> >> Wäre dann nicht die Prüfung via Policy-Service (Quota) aus Dovecot >> nicht in smtpd_end_of_data_restrictions sinnvoller? > > Ja, das wäre sinnvoller. Davor bist Du auf die Size-Angabe des Clients im > "MAIL FROM" angewiesen, wenn er denn das RFC unterstützt und sich daran hält. > Wir trauen dem Client lieber nicht und finden es lieber selbst heraus - am > Ende der DATA Phase. Dann kann Postfix die Grösse der Nachricht selbst > berechnen. Danke für die schnelle und klare Antwort, und das sogar am Sonntag! Grüße Klaus. > p at rick > > > -- > [*] 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 ----- Ende der Nachricht von Patrick Ben Koetter

----- -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From postfixbuch at cboltz.de Sun Aug 23 16:16:06 2015 From: postfixbuch at cboltz.de (Christian Boltz) Date: Sun, 23 Aug 2015 16:16:06 +0200 Subject: Frage zu check_policy_service... In-Reply-To: <20150823083750.Horde.8Q0Oor5SISOfcsXokj0U2n6@buero.tachtler.net> References: <20150823083750.Horde.8Q0Oor5SISOfcsXokj0U2n6@buero.tachtler.net> Message-ID: <1509496.QZx477Hynh@tux.boltz.de.vu> Hallo Klaus, hallo Leute, Am Sonntag, 23. August 2015 schrieb Klaus Tachtler: > Frage: Ist es denn schon richtig, in den smptd_recipient_restrictions > den Policy-Service (Quota) aus Dovecot zu befragen, da bei einer > Prüfung in smptd_recipient_restrictions die --> Größe <-- der gerade > zur Einlieferung anstehenden E-Mail noch gar nicht bekannt ist. Dies > wäre doch erst nach der Übermittlung der Daten nach > smtpd_end_of_data_restrictions der Fall? > > Wäre dann nicht die Prüfung via Policy-Service (Quota) aus Dovecot > nicht in smtpd_end_of_data_restrictions sinnvoller? Wie wärs mit "kommt drauf an"? ;-) Du hast die Wahl zwischen: - Ablehnungsmöglichkeit für einzelne Empfänger und Vertrauen, dass der Absender die Größe vorab richtig angibt (smptd_recipient_restrictions) - sichere Kenntnis der exakten Größe, aber Ablehnung für alle Empfänger (smtpd_end_of_data_restrictions) Das alles unter der Annahme, dass da kein receive_override_options=no_address_mappings im Weg steht. So, und jetzt such Dir aus, was in Deinem Setup wichtiger/passender ist ;-) Gruß Christian Boltz -- Nichts hält so lange wie ein Provisorium [Uwe Drießen in postfixbuch-users] From klaus at tachtler.net Sun Aug 23 16:51:13 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Sun, 23 Aug 2015 16:51:13 +0200 Subject: Frage zu check_policy_service... In-Reply-To: <1509496.QZx477Hynh@tux.boltz.de.vu> References: <20150823083750.Horde.8Q0Oor5SISOfcsXokj0U2n6@buero.tachtler.net> <1509496.QZx477Hynh@tux.boltz.de.vu> Message-ID: <20150823165113.Horde.EG_YBR3oPkHmre-KApMmglP@buero.tachtler.net> Hallo Christian, danke erst mal für Deine Antwort! > Hallo Klaus, hallo Leute, > > Am Sonntag, 23. August 2015 schrieb Klaus Tachtler: >> Frage: Ist es denn schon richtig, in den smptd_recipient_restrictions >> den Policy-Service (Quota) aus Dovecot zu befragen, da bei einer >> Prüfung in smptd_recipient_restrictions die --> Größe <-- der gerade >> zur Einlieferung anstehenden E-Mail noch gar nicht bekannt ist. Dies >> wäre doch erst nach der Übermittlung der Daten nach >> smtpd_end_of_data_restrictions der Fall? >> >> Wäre dann nicht die Prüfung via Policy-Service (Quota) aus Dovecot >> nicht in smtpd_end_of_data_restrictions sinnvoller? > > Wie wärs mit "kommt drauf an"? ;-) > > Du hast die Wahl zwischen: > - Ablehnungsmöglichkeit für einzelne Empfänger und Vertrauen, dass der > Absender die Größe vorab richtig angibt (smptd_recipient_restrictions) > - sichere Kenntnis der exakten Größe, aber Ablehnung für alle Empfänger > (smtpd_end_of_data_restrictions) Verstehe ich es richtig, wenn die e-Mail eingeliefert wird und der check_policy_service in smptd_recipient_restrictions steht, wird dieser für JEDE - RCPT TO-Adresse - durchgeführt und ich muss darauf Vertrauen, das die Größe via RFC fähigem Client (wie Patrick schreibt) richtig übermittelt wird. Was aber, wenn dieser gar keine Größe übermittelt, weil er nicht kann oder will? Wenn ich den check_policy_service allerdings in smtpd_end_of_data_restrictions durchführe, dann würde die e-Mail für alle Empfänger abgelehnt werden, aber was ich dabei nicht verstehe, wenn ich den Dovecot via check_policy_service = inet:imap.example.com:12340 frage, für welchen Empfänger ermittelt Postfix dann die Quota, für den ersten RCPT TO, den letzten RCPT TO oder alle RCPT TO nacheinander, wie kann ich mir das vorstellen? > Das alles unter der Annahme, dass da kein > receive_override_options=no_address_mappings im Weg steht. > > So, und jetzt such Dir aus, was in Deinem Setup wichtiger/passender > ist ;-) Danke! > > Gruß > > Christian Boltz > -- > Nichts hält so lange wie ein Provisorium > [Uwe Drießen in postfixbuch-users] Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From postfixbuch at cboltz.de Sun Aug 23 17:55:54 2015 From: postfixbuch at cboltz.de (Christian Boltz) Date: Sun, 23 Aug 2015 17:55:54 +0200 Subject: Frage zu check_policy_service... In-Reply-To: <20150823165113.Horde.EG_YBR3oPkHmre-KApMmglP@buero.tachtler.net> References: <20150823083750.Horde.8Q0Oor5SISOfcsXokj0U2n6@buero.tachtler.net> <1509496.QZx477Hynh@tux.boltz.de.vu> <20150823165113.Horde.EG_YBR3oPkHmre-KApMmglP@buero.tachtler.net> Message-ID: <7261061.14Z69y0zCt@tux.boltz.de.vu> Hallo Klaus, hallo Leute, Am Sonntag, 23. August 2015 schrieb Klaus Tachtler: > > Am Sonntag, 23. August 2015 schrieb Klaus Tachtler: > >> Frage: Ist es denn schon richtig, in den > >> smptd_recipient_restrictions > >> den Policy-Service (Quota) aus Dovecot zu befragen, da bei einer > >> Prüfung in smptd_recipient_restrictions die --> Größe <-- der > >> gerade > >> zur Einlieferung anstehenden E-Mail noch gar nicht bekannt ist. > >> Dies > >> wäre doch erst nach der Übermittlung der Daten nach > >> smtpd_end_of_data_restrictions der Fall? > >> > >> Wäre dann nicht die Prüfung via Policy-Service (Quota) aus Dovecot > >> nicht in smtpd_end_of_data_restrictions sinnvoller? > > > > Wie wärs mit "kommt drauf an"? ;-) > > > > Du hast die Wahl zwischen: > > - Ablehnungsmöglichkeit für einzelne Empfänger und Vertrauen, dass > > der> > > Absender die Größe vorab richtig angibt > > (smptd_recipient_restrictions)> > > - sichere Kenntnis der exakten Größe, aber Ablehnung für alle > > Empfänger> > > (smtpd_end_of_data_restrictions) > > Verstehe ich es richtig, wenn die e-Mail eingeliefert wird und der > check_policy_service in smptd_recipient_restrictions steht, wird > dieser für JEDE - RCPT TO-Adresse - durchgeführt und ich muss darauf Jepp. > Vertrauen, das die Größe via RFC fähigem Client (wie Patrick schreibt) > richtig übermittelt wird. > Was aber, wenn dieser gar keine Größe übermittelt, weil er nicht kann > oder will? Dann hast Du den Nachteil dieser Variante entdeckt ;-) (IIRC gibt es eine Dovecot-Option, um das Quota "ein wenig" überschreiten zu dürfen - das könnte ein Workaround sein.) > Wenn ich den check_policy_service allerdings in > smtpd_end_of_data_restrictions durchführe, dann würde die e-Mail für > alle Empfänger abgelehnt werden, aber was ich dabei nicht verstehe, > wenn ich den Dovecot via check_policy_service = > inet:imap.example.com:12340 frage, für welchen Empfänger ermittelt > Postfix dann die Quota, für den ersten RCPT TO, den letzten RCPT TO > oder alle RCPT TO nacheinander, wie kann ich mir das vorstellen? Das ist eine Beschränkung des SMTP-Protokolls - nach DATA kannst Du nur noch _für alle Empfänger_ entscheiden (annehmen oder ablehnen), aber nicht mehr für einzelne Empfänger. Was bei unterschiedlichen Antworten seitens Dovecot für unterschiedliche Empfänger passiert, habe ich noch nie getestet - jedenfalls wird es nur für einen Teil der Empfänger das gewünschte Verhalten ergeben ;-) Gruß Christian Boltz -- You could just randomly throw darts at the list of packages on the DVD and not on the CD and any of them can be removed with little or no end-user visibility. [Greg Freemyer in opensuse-factory] From klaus at tachtler.net Sun Aug 23 19:13:48 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Sun, 23 Aug 2015 19:13:48 +0200 Subject: Frage zu check_policy_service... In-Reply-To: <7261061.14Z69y0zCt@tux.boltz.de.vu> References: <20150823083750.Horde.8Q0Oor5SISOfcsXokj0U2n6@buero.tachtler.net> <1509496.QZx477Hynh@tux.boltz.de.vu> <20150823165113.Horde.EG_YBR3oPkHmre-KApMmglP@buero.tachtler.net> <7261061.14Z69y0zCt@tux.boltz.de.vu> Message-ID: <20150823191348.Horde.YpF2NbIclsvHCW1MFBEARRZ@buero.tachtler.net> Hallo Christian, >> >> Verstehe ich es richtig, wenn die e-Mail eingeliefert wird und der >> check_policy_service in smptd_recipient_restrictions steht, wird >> dieser für JEDE - RCPT TO-Adresse - durchgeführt und ich muss darauf > > Jepp. > >> Vertrauen, das die Größe via RFC fähigem Client (wie Patrick schreibt) >> richtig übermittelt wird. >> Was aber, wenn dieser gar keine Größe übermittelt, weil er nicht kann >> oder will? > > Dann hast Du den Nachteil dieser Variante entdeckt ;-) > (IIRC gibt es eine Dovecot-Option, um das Quota "ein wenig" > überschreiten zu dürfen - das könnte ein Workaround sein.) Nun, das habe ich bereits in Dovecot so eingerichtet. >> Wenn ich den check_policy_service allerdings in >> smtpd_end_of_data_restrictions durchführe, dann würde die e-Mail für >> alle Empfänger abgelehnt werden, aber was ich dabei nicht verstehe, >> wenn ich den Dovecot via check_policy_service = >> inet:imap.example.com:12340 frage, für welchen Empfänger ermittelt >> Postfix dann die Quota, für den ersten RCPT TO, den letzten RCPT TO >> oder alle RCPT TO nacheinander, wie kann ich mir das vorstellen? > > Das ist eine Beschränkung des SMTP-Protokolls - nach DATA kannst Du nur > noch _für alle Empfänger_ entscheiden (annehmen oder ablehnen), aber > nicht mehr für einzelne Empfänger. > > Was bei unterschiedlichen Antworten seitens Dovecot für unterschiedliche > Empfänger passiert, habe ich noch nie getestet - jedenfalls wird es nur > für einen Teil der Empfänger das gewünschte Verhalten ergeben ;-) Das bedeutet, könnte es evtl. sein, das aufgrund des check_policy_service in smtpd_end_of_data_restrictions, was ja eigentlich für JEDEN RCPT TO durchgeführt werden müsste, auch dann unterschiedliche Ergebnisse bei der Abgabe an Dovecot ergeben müsste. Es kann doch nicht sein, das die e-Mail generell abgelehnt wird, nur weil einer von vielen RCPT TO ein volles Postfach hat, oder verstehe ich das jetzt ganz falsch? Da sollte aber doch eine Ablegung auch pro RCPT TO logisch sein, da ich ja das gleiche Problem hätte, wenn ich überhaupt keinen check_policy_service egal in welcher restriction hätte, da ja bei einem RCPT TO das Postfach voll sein könnte und beim anderen nicht? Je nach dem was ich mache (content_filter oder proxy_filter) muss ich bei mehreren Empfänger ja auch unterschiedliche Reaktionen erhalten können, auch wenn ich gar keinen check_policy_service habe? Ich danke Dir auf jeden Fall für Deine Anmerkungen, da mir das so nicht im Detail bewusst war und ich zuerst gar nicht an mehrere RCPT TO gedacht hatte, vielen dank für's Augen öffnen! Darf ich fragen, ob und wo Du check_policy_service hast - ich denke in smtpd_recipient_restrictions ? > > Gruß > > Christian Boltz > -- > You could just randomly throw darts at the list of packages on the > DVD and not on the CD and any of them can be removed with little or > no end-user visibility. [Greg Freemyer in opensuse-factory] Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From postfixbuch at cboltz.de Tue Aug 25 22:58:38 2015 From: postfixbuch at cboltz.de (Christian Boltz) Date: Tue, 25 Aug 2015 22:58:38 +0200 Subject: Frage zu check_policy_service... In-Reply-To: <20150823191348.Horde.YpF2NbIclsvHCW1MFBEARRZ@buero.tachtler.net> References: <20150823083750.Horde.8Q0Oor5SISOfcsXokj0U2n6@buero.tachtler.net> <7261061.14Z69y0zCt@tux.boltz.de.vu> <20150823191348.Horde.YpF2NbIclsvHCW1MFBEARRZ@buero.tachtler.net> Message-ID: <4506603.yx4044OUz4@tux.boltz.de.vu> Hallo Klaus, hallo Leute, Am Sonntag, 23. August 2015 schrieb Klaus Tachtler: > Das bedeutet, könnte es evtl. sein, das aufgrund des > check_policy_service in smtpd_end_of_data_restrictions, was ja > eigentlich für JEDEN RCPT TO durchgeführt werden müsste, auch dann > unterschiedliche Ergebnisse bei der Abgabe an Dovecot ergeben müsste. > > Es kann doch nicht sein, das die e-Mail generell abgelehnt wird, nur > weil einer von vielen RCPT TO ein volles Postfach hat, oder verstehe > ich das jetzt ganz falsch? Doch, das kann schon sein. Die einzig funktionierende Alternative wäre, die Mail doch anzunehmen und dann Bounces für die abgelehnte Adresse zu generieren. Wie gesagt: Einschränkung des SMTP-Protokolls - nach DATA gibt es nur noch eine Antwort für alle Empfänger. > Da sollte aber doch eine Ablegung auch pro RCPT TO logisch sein, da > ich ja das gleiche Problem hätte, wenn ich überhaupt keinen > check_policy_service egal in welcher restriction hätte, da ja bei > einem RCPT TO das Postfach voll sein könnte und beim anderen nicht? > > Je nach dem was ich mache (content_filter oder proxy_filter) muss > ich bei mehreren Empfänger ja auch unterschiedliche Reaktionen > erhalten können, auch wenn ich gar keinen check_policy_service habe? Ich mache mir das Leben leichter und habe nur eine serverweite Config für Amavis, aber keine User-spezifische ;-) > Darf ich fragen, ob und wo Du check_policy_service hast - ich denke > in smtpd_recipient_restrictions ? Genau. Gruß Christian Boltz -- Wer braucht z.B. einen 3 GHz - getakteten PC mit 1 GByte DDR-RAM, wenn dann daran nur eine lahme DMA-133-IDE-Festplatte rödelt, aber auch ein geiles Modem für superschnelles Surfvergnügen und eine analoge TV-Karte integriert sind? Das ist wie ein Ferrari auf Holzspeichenrädern und mit 2 x 15 Watt Lenco-Auto-Kassettenradio im Handschuhfach. [Matthias Houdek in suse-linux] From daniel at ist-immer-online.de Wed Aug 26 21:20:34 2015 From: daniel at ist-immer-online.de (Daniel) Date: Wed, 26 Aug 2015 21:20:34 +0200 Subject: =?UTF-8?Q?Optionen_f=C3=BCr_Mail_Versand_=C3=BCbern_?= =?UTF-8?Q?DSL_Anschluss?= Message-ID: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> Huhu, welche Optionen habe ich um vom DSL Anschluss Mails zu versenden? Telekom Tarifwechsel möchte ich vermeiden, der Tarif mit fester IP kostet fast 30? mehr im Monat. Smarthost bzw. Relay von Telekom, 1&1 oder ähnlichen möchte ich nicht verwenden, lieber wenn direkt zustellen. Problem ist ja nicht unbedingt die IP selbst sondern der Pool aus dip0.t-ipconnect.de, welche ja auf der DNSBL stehen. Noch ne Überlegung war sonst nen sehr günstiger VPN Zugang, und dann im Postfix evt. über transport portmap anzupassen. Weiß jedoch nicht direkt was ich da dann dafür in main.cf eintragen müsste, damit nur der Versand (smtp) über das VPN erfolgt, empfang soll weiterhin direkt möglich sein, dafür ist der IP Pool ja egal. In Firewall bzw. iptables wollte ich ungern mit Regeln was umbiegen. Mit statischen Route oder so komme ich ja auch nicht weiter, müsste ja wenn 25 oder 587 entsprechend ausgehend nur umleiten durch nen Tunnel oder ähnliches. Gruß Daniel -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From mailingliste-postfixbuch+spamtrap at pothe.de Wed Aug 26 21:35:11 2015 From: mailingliste-postfixbuch+spamtrap at pothe.de (Andreas Pothe) Date: Wed, 26 Aug 2015 21:35:11 +0200 Subject: =?UTF-8?Q?Re:_Optionen_f=c3=bcr_Mail_Versand_=c3=bcbern_DSL_Anschlu?= =?UTF-8?Q?ss?= In-Reply-To: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> Message-ID: <55DE14EF.8010608@pothe.de> Am 26.08.2015 um 21:20 schrieb Daniel: > > welche Optionen habe ich um vom DSL Anschluss Mails zu versenden? > > > > Telekom Tarifwechsel möchte ich vermeiden, der Tarif mit fester IP > kostet fast 30? mehr im Monat. > > > > Smarthost bzw. Relay von Telekom, 1&1 oder ähnlichen möchte ich nicht > verwenden, lieber wenn direkt zustellen. > > > > Hol dir einen günstigen vServer, zum Beispiel den CX10 bei Hetzner für 3,90 EUR/Monat zzgl. USt. (in D also 4,64 EUR Brutto), da kannst du alles mit machen und hast deine festen IPv6- und IPv4-Adressen. CU Andreas -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From daniel at ist-immer-online.de Wed Aug 26 22:20:52 2015 From: daniel at ist-immer-online.de (Daniel) Date: Wed, 26 Aug 2015 22:20:52 +0200 Subject: =?UTF-8?Q?AW:_Optionen_f=C3=BCr_Mail_Versand_=C3=BCb?= =?UTF-8?Q?ern_DSL_Anschluss?= In-Reply-To: <55DE14EF.8010608@pothe.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> Message-ID: <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> Hallo Andreas, danke für den Vorschlag, jedoch soll Server im Büro stehen, möchte keine Root oder v-Server in externen Rechenzentren, gab in Vergangenheit öfters mal Probleme was Verfügbarkeit angeht oder Bandbreite ect. egal ob 1&1, Strato, Server4you ect. Gruß Daniel Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Andreas Pothe Gesendet: Mittwoch, 26. August 2015 21:35 An: Diskussionen und Support rund um Postfix Betreff: Re: Optionen für Mail Versand übern DSL Anschluss Am 26.08.2015 um 21:20 schrieb Daniel: welche Optionen habe ich um vom DSL Anschluss Mails zu versenden? Telekom Tarifwechsel möchte ich vermeiden, der Tarif mit fester IP kostet fast 30? mehr im Monat. Smarthost bzw. Relay von Telekom, 1&1 oder ähnlichen möchte ich nicht verwenden, lieber wenn direkt zustellen. Hol dir einen günstigen vServer, zum Beispiel den CX10 bei Hetzner für 3,90 EUR/Monat zzgl. USt. (in D also 4,64 EUR Brutto), da kannst du alles mit machen und hast deine festen IPv6- und IPv4-Adressen. CU Andreas -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From ad+lists at uni-x.org Wed Aug 26 22:28:01 2015 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Wed, 26 Aug 2015 22:28:01 +0200 Subject: =?UTF-8?Q?Re:_Optionen_f=c3=bcr_Mail_Versand_=c3=bcbern_DSL_Anschlu?= =?UTF-8?Q?ss?= In-Reply-To: <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> Message-ID: <55DE2151.6080108@uni-x.org> Am 26.08.2015 um 22:20 schrieb Daniel: > Hallo Andreas, > > > > danke für den Vorschlag, jedoch soll Server im Büro stehen, möchte keine Root oder v-Server in externen Rechenzentren, gab in Vergangenheit öfters mal Probleme was Verfügbarkeit angeht oder Bandbreite ect. egal ob 1&1, Strato, Server4you ect. > > > > > > Gruß Daniel Bitte kein TOFU-Posting. Und HTML-Mails mit Office sind auch unnötig. Welche Art von Wunder erwartest Du? Du hast richtig erkannt, dass ein MTA an einer DSL-Anbindung nicht sinnvoll zu betreiben ist. Einen externen Relayhost willst Du auch nicht. Für eine statische IP-Adresse auch nicht. Dein Weg ist hier dann wohl zu Ende. Alexander From p at sys4.de Wed Aug 26 22:48:17 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Wed, 26 Aug 2015 22:48:17 +0200 Subject: Optionen =?utf-8?Q?f=C3=BCr_Mail_Versa?= =?utf-8?B?bmQgw7xiZXJu?= DSL Anschluss In-Reply-To: <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> Message-ID: <20150826204817.GC31388@sys4.de> * Daniel : > danke für den Vorschlag, jedoch soll Server im Büro stehen, möchte keine > Root oder v-Server in externen Rechenzentren, gab in Vergangenheit öfters > mal Probleme was Verfügbarkeit angeht oder Bandbreite ect. egal ob 1&1, > Strato, Server4you ect. Der bei Weitem überwiegende Teil der Mailwelt nimmt keine E-Mails von Systemen mit dynamischer IP an. Wenn Du ein Mailsystem 'zuuhause' betreiben willst, dann hast Du mehrere Möglichkeiten: - Business DSL mit 'sauberen IPs', die nicht auf einer Blacklist stehen und keine 'dynnamic IP' Vorgeschichte haben - Relayen über eigenen Server bei einem Hoster - Relayen über eine Access Provider. Die DTAG bietet (IIRC) ihren Business Kunden eigene Relay-Server an. Andere Access Provider bieten ähnliches. Falls es Dir um Security geht, werfe ich mal folgende Überlegung in den Raum: Einen Server gegen IP access zu schützen, das musst Du immer - egal ob Du den Dienst in den eigenen Räumen oder in einem RZ betreibst. Aber ist das Büro so gut gegen physischen Zugang geschützt wie ein RZ? Diese Überlegung kommt einem nicht sofort in den Sinn, weil man aus dem Reflex heraus annimmt, die eigenen vier Wände seien sicherer. Ist das so? Ein ordentliches RZ bietet - Mehrstufige Zugangssperren - Wachpersonal - Authentifizierung - Videoüberwachung - RZ Firewalling - RZ Monitoring my 2ct p at rick -- [*] 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 From daniel at ist-immer-online.de Wed Aug 26 22:50:10 2015 From: daniel at ist-immer-online.de (Daniel) Date: Wed, 26 Aug 2015 22:50:10 +0200 Subject: =?UTF-8?Q?AW:_Optionen_f=C3=BCr_Mail_Versand_=C3=BCb?= =?UTF-8?Q?ern_DSL_Anschluss?= In-Reply-To: <55DE2151.6080108@uni-x.org> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> <55DE2151.6080108@uni-x.org> Message-ID: <005b01d0e040$cc600d00$65202700$@ist-immer-online.de> Hallo Alexander, ich erwarte keine Wunder, schaue noch nach Optionen. Derzeit wird ein Relay verwendet, was auch weiter laufen wird, wenn keine andere Option sich ergibt. Ich möchte schon gerne feste IP, bzw. Reserve Name zur IP, jedoch vermeiden 30? mehr zu Zahlen an Telekom, wenn es auch günstigere Optionen gibt. Daher war ja Gedanke z.B. VPN und nen Transportmap Eintrag über VPN Tunnel für den Versand. Gruß Daniel From daniel at ist-immer-online.de Wed Aug 26 23:08:49 2015 From: daniel at ist-immer-online.de (Daniel) Date: Wed, 26 Aug 2015 23:08:49 +0200 Subject: =?UTF-8?Q?AW:_Optionen_f=C3=BCr_Mail_Versand_=C3=BCb?= =?UTF-8?Q?ern_DSL_Anschluss?= In-Reply-To: <20150826204817.GC31388@sys4.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> <20150826204817.GC31388@sys4.de> Message-ID: <006101d0e043$677a18b0$366e4a10$@ist-immer-online.de> Hallo Patrick, die 4 Optionen hatte ich schon in der Eingangsmail, bei T-Online Email kann man sich 10 Adressen einzeln verifizieren mit den man versenden kann, ne danke. Da zahle ich lieber nen paar Euros und nutzt und Unterstützt da Anbieter wie Posteo, wo ich solchen gedöns nicht habe und einzelne Absender noch verifizieren muss und so. VPN und Postmap Transport über den Tunnel geht nicht wie angedacht? RZ ist übertrieben für die paar Leutchen die ganze nutzen, und keine Lust haben auf die Freemailer die ein noch mit Werbung und so nerven, oder Eigenwerbung in Signatur werfen ect. Derzeit wird bei Telekom einer der Meganta Tarife verwendet geschäftlich. Bevor ich nur wegen IP 30? mehr zahle, würde ich es z.B. lieber über Posteo und co relayen. Gruß Daniel From p at sys4.de Wed Aug 26 23:40:11 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Wed, 26 Aug 2015 23:40:11 +0200 Subject: Optionen =?utf-8?Q?f=C3=BCr_Mail_Versa?= =?utf-8?B?bmQgw7xiZXJu?= DSL Anschluss In-Reply-To: <006101d0e043$677a18b0$366e4a10$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> <20150826204817.GC31388@sys4.de> <006101d0e043$677a18b0$366e4a10$@ist-immer-online.de> Message-ID: <20150826214011.GA6280@sys4.de> Hi, * Daniel : > die 4 Optionen hatte ich schon in der Eingangsmail, bei T-Online Email kann man sich 10 Adressen einzeln verifizieren mit den man versenden kann, ne danke. die erste Mail hatte ich gelöscht. :/ > Da zahle ich lieber nen paar Euros und nutzt und Unterstützt da Anbieter wie Posteo, wo ich solchen gedöns nicht habe und einzelne Absender noch verifizieren muss und so. Deine Arbeitszeit für die Einrichtung und Betreuung eingerechnet, kann auch schnell was zusammenkommem und ? 30 könnten vergleichbar sein. > VPN und Postmap Transport über den Tunnel geht nicht wie angedacht? Hab Deine erste Mail nicht, sorry. > RZ ist übertrieben für die paar Leutchen die ganze nutzen, und keine Lust haben auf die Freemailer die ein noch mit Werbung und so nerven, oder Eigenwerbung in Signatur werfen ect. > Derzeit wird bei Telekom einer der Meganta Tarife verwendet geschäftlich. Bevor ich nur wegen IP 30? mehr zahle, würde ich es z.B. lieber über Posteo und co relayen. Posteo bietet kein Mailhosting für andere Domains als posteo.... Du kannst Dir für ? 3,99/Monat bei netcup eine VM holen: https://www.netcup.de/vserver/ Die bieten auch v6 und haben guten Support. Oder Du gehst zu Heckrath.net und gibst ? 4,99 aus: http://www.heckrath.net/vserver_kvm Auch hier fähige Leute und v6. Es geht also auch gut für weitaus weniger als ? 30. p at rick -- [*] 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 From daniel at ist-immer-online.de Wed Aug 26 23:52:05 2015 From: daniel at ist-immer-online.de (Daniel) Date: Wed, 26 Aug 2015 23:52:05 +0200 Subject: =?UTF-8?Q?AW:_Optionen_f=C3=BCr_Mail_Versand_=C3=BCb?= =?UTF-8?Q?ern_DSL_Anschluss?= In-Reply-To: <20150826214011.GA6280@sys4.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> <20150826204817.GC31388@sys4.de> <006101d0e043$677a18b0$366e4a10$@ist-immer-online.de> <20150826214011.GA6280@sys4.de> Message-ID: <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> Hi Patrick, Posteo soll ja auch keine Emails empfangen, es geht mir nur um den Versand bzw. andere IP. Der Empfang ist direkt, da ist die IP ja egal. Große Arbeitszeit und Aufwand habe ich nicht, User sind fix angelegt, und mal Updates ect. Beschäftigen einen nicht täglich Stunden, zumindest nicht bei dem kleinen Nutzerkreis. Wie in zweiter Mail geschrieben, kommen v- oder Rootserver im RZ nicht in Frage. Anbei nochmal 1. Mail unten. dir noch schönen Abend, Gruß Daniel ============================ Betreff: Optionen für Mail Versand übern DSL Anschluss Huhu, welche Optionen habe ich um vom DSL Anschluss Mails zu versenden? Telekom Tarifwechsel möchte ich vermeiden, der Tarif mit fester IP kostet fast 30? mehr im Monat. Smarthost bzw. Relay von Telekom, 1&1 oder ähnlichen möchte ich nicht verwenden, lieber wenn direkt zustellen. Problem ist ja nicht unbedingt die IP selbst sondern der Pool aus dip0.t-ipconnect.de, welche ja auf der DNSBL stehen. Noch ne Überlegung war sonst nen sehr günstiger VPN Zugang, und dann im Postfix evt. über transport portmap anzupassen. Weiß jedoch nicht direkt was ich da dann dafür in main.cf eintragen müsste, damit nur der Versand (smtp) über das VPN erfolgt, empfang soll weiterhin direkt möglich sein, dafür ist der IP Pool ja egal. In Firewall bzw. iptables wollte ich ungern mit Regeln was umbiegen. Mit statischen Route oder so komme ich ja auch nicht weiter, müsste ja wenn 25 oder 587 entsprechend ausgehend nur umleiten durch nen Tunnel oder ähnliches. Gruß Daniel From driessen at fblan.de Thu Aug 27 01:00:19 2015 From: driessen at fblan.de (=?UTF-8?Q?Uwe_Drie=C3=9Fen?=) Date: Thu, 27 Aug 2015 01:00:19 +0200 Subject: =?UTF-8?Q?AW:_Optionen_f=C3=BCr_Mail_Versand_=C3=BCb?= =?UTF-8?Q?ern_DSL_Anschluss?= In-Reply-To: <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> <20150826204817.GC31388@sys4.de> <006101d0e043$677a18b0$366e4a10$@ist-immer-online.de> <20150826214011.GA6280@sys4.de> <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> Message-ID: <014e01d0e052$fc13f1d0$f43bd570$@fblan.de> Im Auftrag von Daniel > > Der Empfang ist direkt, da ist die IP ja egal. > > Große Arbeitszeit und Aufwand habe ich nicht, User sind fix angelegt, und mal > Updates ect. Beschäftigen einen nicht täglich Stunden, zumindest nicht bei dem > kleinen Nutzerkreis. Mailserver bedürfen immer einer gewissen Aufmerksamkeit. Gehackte PW der User haben schon so manchen auf eine Blacklist beim Versand gebracht. Von fehlender Filterung im Versand/Empfang und dem Einschleusen von Trojaner usw. mal abgesehen.... ...... > > Wie in zweiter Mail geschrieben, kommen v- oder Rootserver im RZ nicht in > Frage. Ob ein DSL-Anschluss bessere Erreichbarkeiten als RZ's oder Server in RZ's haben lassen wir mal dahingestellt sein. Und wer es denn wirklich rund um die Uhr mit 24/7 benötigt muss immer 2 ganz unterschiedliche Standorte unterhalten. Höher Gewalt gibt es Immer wieder (oder auch nen Admin der den falschen Knopf gedrückt hat) > > Anbei nochmal 1. Mail unten. > > dir noch schönen Abend, > Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From driessen at fblan.de Thu Aug 27 01:02:40 2015 From: driessen at fblan.de (=?UTF-8?Q?Uwe_Drie=C3=9Fen?=) Date: Thu, 27 Aug 2015 01:02:40 +0200 Subject: =?UTF-8?Q?AW:_Optionen_f=C3=BCr_Mail_Versand_=C3=BCb?= =?UTF-8?Q?ern_DSL_Anschluss?= In-Reply-To: <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> <20150826204817.GC31388@sys4.de> <006101d0e043$677a18b0$366e4a10$@ist-immer-online.de> <20150826214011.GA6280@sys4.de> <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> Message-ID: <014f01d0e053$4fc43330$ef4c9990$@fblan.de> Im Auftrag von Daniel > > Der Empfang ist direkt, da ist die IP ja egal. > > Große Arbeitszeit und Aufwand habe ich nicht, User sind fix angelegt, und mal > Updates ect. Beschäftigen einen nicht täglich Stunden, zumindest nicht bei dem > kleinen Nutzerkreis. Mailserver bedürfen immer einer gewissen Aufmerksamkeit. Gehackte PW der User haben schon so manchen auf eine Blacklist beim Versand gebracht. Von fehlender Filterung im Versand/Empfang und dem Einschleusen von Trojaner usw. mal abgesehen.... ...... > > Wie in zweiter Mail geschrieben, kommen v- oder Rootserver im RZ nicht in > Frage. Ob ein DSL-Anschluss bessere Erreichbarkeiten als RZ's oder Server in RZ's haben lassen wir mal dahingestellt sein. Und wer es denn wirklich rund um die Uhr mit 24/7 benötigt muss immer 2 ganz unterschiedliche Standorte unterhalten. Höher Gewalt gibt es Immer wieder (oder auch nen Admin der den falschen Knopf gedrückt hat) > > Anbei nochmal 1. Mail unten. > > dir noch schönen Abend, > Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From max.grobecker at ml.grobecker.info Thu Aug 27 01:30:05 2015 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Thu, 27 Aug 2015 01:30:05 +0200 Subject: =?UTF-8?Q?Re:_Optionen_f=c3=bcr_Mail_Versand_=c3=bcbern_DSL_Anschlu?= =?UTF-8?Q?ss?= In-Reply-To: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> Message-ID: <55DE4BFD.8040201@ml.grobecker.info> Hallo, Am 26.08.2015 um 21:20 schrieb Daniel: > Noch ne Überlegung war sonst nen sehr günstiger VPN Zugang, und dann im Postfix evt. über transport portmap anzupassen. > Weiß jedoch nicht direkt was ich da dann dafür in main.cf eintragen müsste, damit nur der Versand (smtp) über das VPN erfolgt, > empfang soll weiterhin direkt möglich sein, dafür ist der IP Pool ja egal. Um darauf der Vollständigkeit halber zu antworten: Sofern du über den VPN-Tunnel eine statische IP bekommst, kannst du einfach in die main.cf eintragen: smtp_bind_address = a.b.c.d Damit wird der gesamte ausgehende SMTP-Verkehr über diese IP abgewickelt. Falls diese nicht zur Verfügung steht (z.B. weil der Tunnel nicht aufgebaut ist) kriegt Postfix keine Verbindung mehr nach draußen und die Mails bleiben in der Queue hängen. Voraussetzung dafür ist aber, dass die Tunnelverbindung auch auf dem Mailserver läuft - denn sonst hat er ja kein Interface, an dem diese IP gebunden ist. Viele Grüße aus dem Tal Max -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 819 bytes Beschreibung: OpenPGP digital signature URL : From mailingliste-postfixbuch+spamtrap at pothe.de Thu Aug 27 08:00:23 2015 From: mailingliste-postfixbuch+spamtrap at pothe.de (Andreas Pothe) Date: Thu, 27 Aug 2015 08:00:23 +0200 Subject: =?utf-8?B?UmU6IEFXOiBPcHRpb25lbiBmw7xyIE1haWwgVmVyc2FuZCDDvGJlcm4gRFNM?= =?utf-8?B?IEFuc2NobHVzcw==?= In-Reply-To: <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> <20150826204817.GC31388@sys4.de> <006101d0e043$677a18b0$366e4a10$@ist-immer-online.de> <20150826214011.GA6280@sys4.de> <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> Message-ID: <07c5a32937f603985dfeefe87bdb6ef4.squirrel@www.pothe.de> > Der Empfang ist direkt, da ist die IP ja egal. Nur der Vollständigkeit halber: Auch diese IP sollte statisch sein. Ich zumindest würde keine Mailserver mit dynamischer IP betreiben wollen... From max at freecards.de Thu Aug 27 09:19:51 2015 From: max at freecards.de (Markus Heinze) Date: Thu, 27 Aug 2015 09:19:51 +0200 Subject: Optionen =?UTF-8?Q?f=C3=BCr=20Mail=20Versand=20=C3=BCbern=20D?= =?UTF-8?Q?SL=20Anschluss?= In-Reply-To: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> Message-ID: Moin moin Am 2015-08-26 21:20, schrieb Daniel: > Huhu, > > welche Optionen habe ich um vom DSL Anschluss Mails zu versenden? Keine, die bereits erwähnte Möglichkeiten sind alternativlos. > > Telekom Tarifwechsel möchte ich vermeiden, der Tarif mit fester IP > kostet fast 30EUR mehr im Monat. Dann habt Ihr andere Preise oder eine andere Telekom, uns kostet dies gerad mal einen 10er mehr im Monat,trotzalledem betreiben wir unseren MTA auf einem eigenen Root Server, da selbst Business IP's auf vielen Blocklists stehen. > > Smarthost bzw. Relay von Telekom, 1&1 oder ähnlichen möchte ich nicht > verwenden, lieber wenn direkt zustellen. Warum, das löst das komplette Problem mit wenigen Handgriffen und es kommt nur 1 Hop dazu > > Problem ist ja nicht unbedingt die IP selbst sondern der Pool aus > dip0.t-ipconnect.de, welche ja auf der DNSBL stehen. Und das ist gut so. MTA an privaten DSL Anschlüssen sind potentiell Böse und wenn die AGB der Telekom nicht geändert wurde auch verboten. > > Noch ne Überlegung war sonst nen sehr günstiger VPN Zugang, und dann im > Postfix evt. über transport portmap anzupassen. Weiß jedoch nicht > direkt was ich da dann dafür in main.cf eintragen müsste, damit nur der > Versand (smtp) über das VPN erfolgt, empfang soll weiterhin direkt > möglich sein, dafür ist der IP Pool ja egal. > > In Firewall bzw. iptables wollte ich ungern mit Regeln was umbiegen. > Mit statischen Route oder so komme ich ja auch nicht weiter, müsste ja > wenn 25 oder 587 entsprechend ausgehend nur umleiten durch nen Tunnel > oder ähnliches. Ich weiss nicht warum man sich sowas umständliches antut nur um ein paar Pfennig zu sparen, das ganz lässt viel Freiraum für Spekulationen. > > Gruß Daniel lg max From wn at neessen.net Thu Aug 27 09:30:15 2015 From: wn at neessen.net (Winfried Neessen) Date: Thu, 27 Aug 2015 09:30:15 +0200 Subject: =?UTF-8?Q?Re=3A_AW=3A_Optionen_f=C3=BCr_Mail_Versand_=C3=BCbern_?= =?UTF-8?Q?DSL_Anschluss?= In-Reply-To: <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> <20150826204817.GC31388@sys4.de> <006101d0e043$677a18b0$366e4a10$@ist-immer-online.de> <20150826214011.GA6280@sys4.de> <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> Message-ID: <9c34b0ccd33528fe60ccc53e84476f88@neessen.net> Hi, Am 2015-08-26 23:52, schrieb Daniel: > Der Empfang ist direkt, da ist die IP ja egal. > In wieweit ist die IP beim empfang egal. Wenn sich die IP bei jeder einwahl aender, musst Du zumindest den MX entsprechend anpassen. Klar kann man das ueber DynDNS Hoster "loesen", wie ich aber gerade gestern wieder lernen durfte, ist vielen Providern die TTL vom DNS egal und sie cachen bereits aufgeloeste Eintraege bis zu 24h. Das waere fuer mich keine Option. > Wie in zweiter Mail geschrieben, kommen v- oder Rootserver im RZ nicht > in Frage. > Warum nicht? Was spricht dagegen? Das "Nichterreichbarkeit"-Argument beisst sich gewaltig mit dem Argument "DSL-Leitung". Ich wage hart zu bezweifeln, dass auch nur eine DSL Leitung mit dynamischer IP (sprich min. 24h Disconnect) mit der Uptime eines RZ mithalten kann. Winni From klaus at tachtler.net Thu Aug 27 10:49:02 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Thu, 27 Aug 2015 10:49:02 +0200 Subject: Frage zu SASL... Message-ID: <20150827104902.Horde.SAP3HcJExS_k-udrq9ciRkl@buero.tachtler.net> Hallo Liste, ich frage mich gerade, ob ich SASL-AUTH auf Port 25 überhaupt anbieten soll, da clients, welche nicht aus meinen Netzen kommen, nur über submission Port 587 einliefern sollen/können/dürfen und eine Server zu Server Kommunikation doch gar kein SMTP-AUTH nutzt? Stehe ich gerade total auf dem Schlauch, oder ist das total abwegig? Danke schon mal in Voraus und Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From gregor at a-mazing.de Thu Aug 27 11:09:58 2015 From: gregor at a-mazing.de (Gregor Hermens) Date: Thu, 27 Aug 2015 11:09:58 +0200 Subject: Frage zu SASL... In-Reply-To: <20150827104902.Horde.SAP3HcJExS_k-udrq9ciRkl@buero.tachtler.net> References: <20150827104902.Horde.SAP3HcJExS_k-udrq9ciRkl@buero.tachtler.net> Message-ID: <201508271109.58458@office.a-mazing.net> Hallo Klaus, Am Donnerstag, 27. August 2015 schrieb Klaus Tachtler: > ich frage mich gerade, ob ich SASL-AUTH auf Port 25 überhaupt anbieten > soll, da clients, welche nicht aus meinen Netzen kommen, nur über > submission Port 587 einliefern sollen/können/dürfen und eine Server zu > Server Kommunikation doch gar kein SMTP-AUTH nutzt? > > Stehe ich gerade total auf dem Schlauch, oder ist das total abwegig? wenn du alle User dazu bringen kannst, Port 587 zu nutzen, kannst und solltest du SMTP-Auth für Port 25 problemlos abschalten, Gruß, Gregor -- @mazing fon +49 8142 6528665 Gregor Hermens fax +49 8142 6528669 Brucker Strasse 12 gregor.hermens at a-mazing.de D-82216 Gernlinden http://www.a-mazing.de/ From driessen at fblan.de Thu Aug 27 11:10:26 2015 From: driessen at fblan.de (=?UTF-8?Q?Uwe_Drie=C3=9Fen?=) Date: Thu, 27 Aug 2015 11:10:26 +0200 Subject: AW: Frage zu SASL... In-Reply-To: <20150827104902.Horde.SAP3HcJExS_k-udrq9ciRkl@buero.tachtler.net> References: <20150827104902.Horde.SAP3HcJExS_k-udrq9ciRkl@buero.tachtler.net> Message-ID: <017b01d0e0a8$36b9faf0$a42df0d0$@fblan.de> Im Auftrag von Klaus Tachtler > ich frage mich gerade, ob ich SASL-AUTH auf Port 25 überhaupt anbieten Nö eigentlich nicht weil da geht doch keiner mehr drüber bzw. es lässt auch keiner mehr zu 587, 465, 995 .... das sind die Alternativen z.T. mit TLS und SSL gesicherten ports da drüber soll nichts von den eigenen Usern kommen seit 2 Jahren hier schon umgestellt und auch extra DNS / IP für die eigenen User angelegt > soll, da clients, welche nicht aus meinen Netzen kommen, nur über > submission Port 587 einliefern sollen/können/dürfen und eine Server zu > Server Kommunikation doch gar kein SMTP-AUTH nutzt? Das geht auch aber dann über die alternativen Ports (Server wird dann zum Client) > > Stehe ich gerade total auf dem Schlauch, oder ist das total abwegig? > > > Danke schon mal in Voraus und > Grüße Klaus. > Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From klaus at tachtler.net Thu Aug 27 11:35:10 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Thu, 27 Aug 2015 11:35:10 +0200 Subject: Frage zu SASL... In-Reply-To: <20150827104902.Horde.SAP3HcJExS_k-udrq9ciRkl@buero.tachtler.net> Message-ID: <20150827113510.Horde.AdV3oE8HljikMS3t5MpiZW0@buero.tachtler.net> Hallo Liste, > ich frage mich gerade, ob ich SASL-AUTH auf Port 25 überhaupt > anbieten soll, da clients, welche nicht aus meinen Netzen kommen, > nur über submission Port 587 einliefern sollen/können/dürfen und > eine Server zu Server Kommunikation doch gar kein SMTP-AUTH nutzt? wie sollte das dann in Postfix konfiguriert werden, bzw. was ist da "good practise"? Wie sieht es z.B. mit den smptd_relay_restrictions und smtpd_recipient_restrictions aus, diese dann auch entsprechend in der /etc/postfix/master.cf angepasst, jeweils extra für smtp und submission? Oder in der /etc/postfix/main.cf die smptd_relay_restrictions und smtpd_recipient_restrictions mit z.B. permit_sasl_authenticated generell, da permit_sasl_authenticated ja nur dann greift, wenn auf dem Port auch SMTP-AUTH möglich ist? Vielen Dank, schon mal für die Rückmeldungen! Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From p at sys4.de Thu Aug 27 11:50:16 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Thu, 27 Aug 2015 11:50:16 +0200 Subject: Frage zu SASL... In-Reply-To: <20150827104902.Horde.SAP3HcJExS_k-udrq9ciRkl@buero.tachtler.net> References: <20150827104902.Horde.SAP3HcJExS_k-udrq9ciRkl@buero.tachtler.net> Message-ID: <20150827095016.GD22854@sys4.de> * Klaus Tachtler : > ich frage mich gerade, ob ich SASL-AUTH auf Port 25 überhaupt > anbieten soll, da clients, welche nicht aus meinen Netzen kommen, > nur über submission Port 587 einliefern sollen/können/dürfen und > eine Server zu Server Kommunikation doch gar kein SMTP-AUTH nutzt? > > Stehe ich gerade total auf dem Schlauch, oder ist das total abwegig? Ich finde das schlüssig zu Ende gedacht. Wenn Du keine Altlasten supporten musst - User, die noch nicht auf 587 umgestellt haben - dann schalte SMTP AUTH auf Port 25 ab. p at rick -- [*] 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 From mailingliste-postfixbuch+spamtrap at pothe.de Thu Aug 27 12:53:21 2015 From: mailingliste-postfixbuch+spamtrap at pothe.de (Andreas Pothe) Date: Thu, 27 Aug 2015 12:53:21 +0200 Subject: =?utf-8?B?UmU6IEFXOiBPcHRpb25lbiBmw7xyIE1haWwgVmVyc2FuZCDDvGJlcm4gRFNM?= =?utf-8?B?IEFuc2NobHVzcw==?= In-Reply-To: <9c34b0ccd33528fe60ccc53e84476f88@neessen.net> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> <20150826204817.GC31388@sys4.de> <006101d0e043$677a18b0$366e4a10$@ist-immer-online.de> <20150826214011.GA6280@sys4.de> <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> <9c34b0ccd33528fe60ccc53e84476f88@neessen.net> Message-ID: <78abae68d9f687db1cc291fee203eac3.squirrel@www.pothe.de> Moin, > mit dem Argument "DSL-Leitung". Ich wage hart zu bezweifeln, dass auch > nur eine DSL Leitung > mit dynamischer IP (sprich min. 24h Disconnect) mit der Uptime eines RZ > mithalten kann. Das eine hat mit dem anderen nichts zu tun. Ich habe an meinem DSL-Anschluss eine dynamische IP, aber einen Disconnect gibt es nur, wenn ich hier den Strom abschalte oder ein sonstiger, die Verbindung trennender, Fehler auf der Leitung vorliegt. Man kann also durchaus auch über Wochen, Monate, Jahre hinweg die gleiche, dynamische IP haben. Aber wehe, die Verbindung wird gekappt, dann gibt es auch eine neue IP (wobei mir ein Kollege, der bei KD Kunde ist, berichtete, dass er von KD immer die gleiche IP zugewiesen bekommt, sofern die Verbindung nicht längere Zeit unterbrochen wird). Grüße Andreas From klaus at tachtler.net Thu Aug 27 13:38:16 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Thu, 27 Aug 2015 13:38:16 +0200 Subject: Frage zu smtpd_relay_restrictions und smptd_recipient_restrictions... Message-ID: <20150827133816.Horde._9WgJ_JweZ2dmJTxJwg7wFs@buero.tachtler.net> Hallo Liste, ich hoffe ich nerve nicht zu sehr mit meinen vielen Fragen... Kann ich ALLE Einträge, welche ich bereits in smtpd_relay_restrictions habe aus smtpd_recipient_restrictions entfernen? DOPPELT WÄREN: permit_sasl_authenticated, permit_mynetworks, permit_mx_backup, reject_unauth_destination? smtpd_relay_restrictions = # Permit all SASL authenticated users or clients from mynetworks. permit_sasl_authenticated, permit_mynetworks, # Permit Backup-MX server. permit_mx_backup, # Reject relaying all others, to prevent to be an "open relay server". reject_unauth_destination smtpd_recipient_restrictions = # RFC or important ROLE-Accounts - Whitelisting - like: postmaster, abuse. check_recipient_access btree:/etc/postfix/check_recipient_access_rfc, # White- and Blacklisting. check_client_access cidr:/etc/postfix/check_client_access, check_helo_access btree:/etc/postfix/check_helo_access, check_sender_access btree:/etc/postfix/check_sender_access, check_recipient_access btree:/etc/postfix/check_recipient_access, # Reject unclean e-Mail. reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_invalid_helo_hostname, # Permit all SASL authenticated users, or clients from mynetworks. permit_sasl_authenticated, permit_mynetworks, # RBL and RHSBL checks. reject_rbl_client zen.spamhaus.org=127.0.0.10, reject_rbl_client zen.spamhaus.org=127.0.0.11, reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, reject_rhsbl_client multi.uribl.com, # Check dynamicaly existing Relay-Recipient. reject_unverified_recipient, # Permit Backup-MX. permit_mx_backup, # Reject relaying all others, to prevent to be an "open relay server". reject_unauth_destination, # Check dynamicaly the Quota-Status of the user against the dovecot imap server. check_policy_service inet:192.168.0.80:12340 Danke, Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From andreas.schulze at datev.de Thu Aug 27 13:59:11 2015 From: andreas.schulze at datev.de (Andreas Schulze) Date: Thu, 27 Aug 2015 13:59:11 +0200 Subject: Frage zu SASL... In-Reply-To: <20150827095016.GD22854@sys4.de> References: <20150827104902.Horde.SAP3HcJExS_k-udrq9ciRkl@buero.tachtler.net> <20150827095016.GD22854@sys4.de> Message-ID: <20150827115910.GB7923@spider.services.datevnet.de> Am 27.08.2015 11:50 schrieb Patrick Ben Koetter: > Ich finde das schlüssig zu Ende gedacht. Wenn Du keine Altlasten supporten > musst - User, die noch nicht auf 587 umgestellt haben - dann schalte SMTP AUTH > auf Port 25 ab. das macht auch die Konfiguration sauberer: Port 25 - inbound / MX Traffic - von anonymen, externen, untrusted clients, STARTTLS opportunistisch Port 587 - outbound, von eigenen Usern - Authentisierung nur nach STARTTLS - Mailtransport nur nach Authentisierung Wenn man das auch noch auf unterschiedliche DNS-Namen mappt, kann man bei bedarf auch noch 2 verschiedene Server draus machen. -- Andreas Schulze Internetdienste | P252 DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info at datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dr. Robert Mayr (stellv. Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Dr. Peter Krug Jörg Rabe von Pappenheim Vorsitzender des Aufsichtsrates: Dirk Schmale From daniel at ist-immer-online.de Thu Aug 27 17:48:04 2015 From: daniel at ist-immer-online.de (Daniel) Date: Thu, 27 Aug 2015 17:48:04 +0200 Subject: =?utf-8?Q?Re:_Optionen_f=C3=BCr_Mail_Versand_=C3=BCbern_DSL_Ansc?= =?utf-8?Q?hluss?= In-Reply-To: References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> Message-ID: <069E6A3E-AAE4-4E4C-8122-FB9EB15FE95C@ist-immer-online.de> Hallo Max, Der Magenta Zuhause mit 50k liegt Effektiv unter 30? durch Aktionsgutschriften. Der Voice Data kostet 60?. Jeweils noch VSt abzug. Es geht also nicht um paar Pfennige sparen. Posteo finde ich schon nicht schlecht als Relay. Gruß Daniel From daniel at ist-immer-online.de Thu Aug 27 17:54:58 2015 From: daniel at ist-immer-online.de (Daniel) Date: Thu, 27 Aug 2015 17:54:58 +0200 Subject: =?utf-8?Q?Re:_AW:_Optionen_f=C3=BCr_Mail_Versand_=C3=BCbern_DSL_?= =?utf-8?Q?Anschluss?= In-Reply-To: <9c34b0ccd33528fe60ccc53e84476f88@neessen.net> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DE14EF.8010608@pothe.de> <004901d0e03c$b49be6c0$1dd3b440$@ist-immer-online.de> <20150826204817.GC31388@sys4.de> <006101d0e043$677a18b0$366e4a10$@ist-immer-online.de> <20150826214011.GA6280@sys4.de> <007701d0e049$72e06f50$58a14df0$@ist-immer-online.de> <9c34b0ccd33528fe60ccc53e84476f88@neessen.net> Message-ID: <600DD326-409F-414B-8180-539B7210F92A@ist-immer-online.de> Hallo Winni, Bei neueren Telekom Tarifen hat man keine 24h Trennung mehr. Wird also eher alle paar Wochen oder Monate neue IP bezogen wenn Router neue Firmware bekommt. Natürlich wird MX immer angepasst, gab selbst bei 24h Trennung keine Probleme. Dafür kann man ja Scripte laufen lassen was nen DDNS Dienst ähnlich kommt. Gruß Daniel From max.grobecker at ml.grobecker.info Thu Aug 27 21:00:01 2015 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Thu, 27 Aug 2015 21:00:01 +0200 Subject: =?UTF-8?Q?Re:_Optionen_f=c3=bcr_Mail_Versand_=c3=bcbern_DSL_Anschlu?= =?UTF-8?Q?ss?= In-Reply-To: References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> Message-ID: <55DF5E31.4010307@ml.grobecker.info> Hallo, Am 27.08.2015 um 09:19 schrieb Markus Heinze: >> Noch ne Überlegung war sonst nen sehr günstiger VPN Zugang, und dann im Postfix evt. über transport portmap anzupassen. Weiß jedoch nicht direkt was ich da dann dafür in main.cf eintragen müsste, >> damit nur der Versand (smtp) über das VPN erfolgt, empfang soll weiterhin direkt möglich sein, dafür ist der IP Pool ja egal. > > Ich weiss nicht warum man sich sowas umständliches antut nur um ein paar Pfennig zu sparen, das ganz lässt viel Freiraum für Spekulationen. Es gibt Gründe. Vielleicht nicht unbedingt im privaten Bereich, aber im Büro wo du die Mails gerne auf dem InHouse-Server verwalten willst, ist der VPN-Zugang garnicht mal so eine dumme Idee. Du hast über den Zugang eine statische öffentliche IP (ggf. auch ein geroutetes Subnetz) und kannst diese unabhängig von der derunter liegenden Internetverbindung bekommen. Wenn also mal der Internetzugang per DSL/Kabel ausfällt, kann man in allergrößter Not immer noch einen LTE-Stick an der Ecke kaufen, sich darüber per VPN verbinden und so zumindest den Mailserver wieder erreichbar bekommen. Viele Grüße aus dem Tal Max -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 819 bytes Beschreibung: OpenPGP digital signature URL : From max at freecards.de Fri Aug 28 06:00:13 2015 From: max at freecards.de (Markus Heinze) Date: Fri, 28 Aug 2015 06:00:13 +0200 Subject: =?UTF-8?Q?Re:_Optionen_f=c3=bcr_Mail_Versand_=c3=bcbern_DSL_Anschlu?= =?UTF-8?Q?ss?= In-Reply-To: <55DF5E31.4010307@ml.grobecker.info> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DF5E31.4010307@ml.grobecker.info> Message-ID: <55DFDCCD.6090708@freecards.de> Moin moin, Am 27.08.2015 um 21:00 schrieb Max Grobecker: > Hallo, > > Am 27.08.2015 um 09:19 schrieb Markus Heinze: > >>> Noch ne Überlegung war sonst nen sehr günstiger VPN Zugang, und dann im Postfix evt. über transport portmap anzupassen. Weiß jedoch nicht direkt was ich da dann dafür in main.cf eintragen müsste, >>> damit nur der Versand (smtp) über das VPN erfolgt, empfang soll weiterhin direkt möglich sein, dafür ist der IP Pool ja egal. >> Ich weiss nicht warum man sich sowas umständliches antut nur um ein paar Pfennig zu sparen, das ganz lässt viel Freiraum für Spekulationen. > Es gibt Gründe. Vielleicht nicht unbedingt im privaten Bereich, aber im Büro wo du die Mails gerne auf dem InHouse-Server verwalten willst, > ist der VPN-Zugang garnicht mal so eine dumme Idee. > Du hast über den Zugang eine statische öffentliche IP (ggf. auch ein geroutetes Subnetz) und kannst diese unabhängig von der derunter liegenden Internetverbindung bekommen. > Wenn also mal der Internetzugang per DSL/Kabel ausfällt, kann man in allergrößter Not immer noch einen LTE-Stick an der Ecke kaufen, sich darüber per VPN verbinden > und so zumindest den Mailserver wieder erreichbar bekommen. Ich meinte damit nicht den VPN mit umständlich, wie gesagt wir haben unseren MTA auf einem Root im Internet, dieser ist mit der Firma auch via VPN angebunden und intern werkelt ein Exchange, das ist ja alles Ok aber warum man mit aller macht über den DSL empfangen/versenden möchte da macht man sich mehr Ärger als Nutzen mit. Wenn's nicht unbedingt ein dedizierter Server sein muss tuts dafür ja auch ein minimalistischer vServer, dann hat man auch alles unter Kontrolle und bezahlt nur kleines Geld. vServer gibts ja auch schon für'n 10er im Monat. Ich meins ja nicht bös ich will ja nur helfen. > > Viele Grüße aus dem Tal > Max > lg max From daniel at ist-immer-online.de Fri Aug 28 07:27:28 2015 From: daniel at ist-immer-online.de (Daniel) Date: Fri, 28 Aug 2015 07:27:28 +0200 Subject: =?UTF-8?Q?AW:_Optionen_f=C3=BCr_Mail_Versand_=C3=BCb?= =?UTF-8?Q?ern_DSL_Anschluss?= In-Reply-To: <55DFDCCD.6090708@freecards.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DF5E31.4010307@ml.grobecker.info> <55DFDCCD.6090708@freecards.de> Message-ID: <001701d0e152$3ba45e20$b2ed1a60$@ist-immer-online.de> Hallo Max, ich nehme es auch nicht als böse auf. In zweiter Email schrieb ich bereits, dass ich keine Lust habe auf V-Server da es irgendwie immer mit ner Zeit Probleme gab. Mal hat nen Plesk Update halbe System zerschossen oder plötzlich werden Prozesse beendet weil Software Limit auf der VM erreicht sind oder ähnliches. Daher lieber nen inHouse Server, der läuft, und kann jeder Zeit ran, und muss nicht Nachts 0900 Support oder so anrufen weil VM mal wieder nicht erreichbar ist und so. Oder wenn es nen Problem gibt, immer Kunde schuld sein soll pauschal und die sich teils nicht zuständig fühlen. Nebeneffekt ist, sollte mal etwas sein im Rahmen irgendeiner Ermittlung, kann die nicht einfach ne heimliche Kopie beim Hoster mitnehmen, der einen dann nicht mal informieren darf. Da müsste man schon dann vorbei kommen, und dann wüsste man auch bescheid. Also nicht dass ich es erwarte oder hoffe, aber ist eben auch einer von mehreren Aspekten. Genau wie dass man intern noch Mailen kann wären man grade Offline ist, weil man Updates macht und so. Und wieso wozu extra übers Internet drauf zugreifen und Leitung belasten wenn man es auch schön mit GBit Netzwerk haben kann? Der Server hier der läuft und läuft soweit ohne Probleme, und kann den ggf. auch jederzeit an Hardware anpassen wenn erforderlich. Mit dem Relay läuft auch ohne Probleme, wollte zumindest prüfen welche Möglichkeiten man nicht hat, um möglichst direkt auszuliefern. Das Relay nimmt ja erstmal sogut wie alles an, ob Mail dann direkt am Ziel ankommt, oder am Relay in Warteschleife hängt kann man bei fremden Anbietern halt nicht sehen. Und für den kleinen Nutzerkreis brauche ich auch keine Hochverfügbarkeits Server im Cluster in mehreren RZ die noch über Kreuz synchronisieren falls mal nen RZ ausfällt oder so. Letztendlich muss es ja jeder selbst wissen, hat alles Vor- und Nachteile. Gruß Daniel -----Ursprüngliche Nachricht----- Ich meinte damit nicht den VPN mit umständlich, wie gesagt wir haben unseren MTA auf einem Root im Internet, dieser ist mit der Firma auch via VPN angebunden und intern werkelt ein Exchange, das ist ja alles Ok aber warum man mit aller macht über den DSL empfangen/versenden möchte da macht man sich mehr Ärger als Nutzen mit. Wenn's nicht unbedingt ein dedizierter Server sein muss tuts dafür ja auch ein minimalistischer vServer, dann hat man auch alles unter Kontrolle und bezahlt nur kleines Geld. vServer gibts ja auch schon für'n 10er im Monat. Ich meins ja nicht bös ich will ja nur helfen. lg max From max at freecards.de Fri Aug 28 08:29:20 2015 From: max at freecards.de (Markus Heinze) Date: Fri, 28 Aug 2015 08:29:20 +0200 Subject: AW: Optionen =?UTF-8?Q?f=C3=BCr=20Mail=20Versand=20=C3=BCbern?= =?UTF-8?Q?=20DSL=20Anschluss?= In-Reply-To: <001701d0e152$3ba45e20$b2ed1a60$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DF5E31.4010307@ml.grobecker.info> <55DFDCCD.6090708@freecards.de> <001701d0e152$3ba45e20$b2ed1a60$@ist-immer-online.de> Message-ID: Hallo Daniel, Am 2015-08-28 7:27, schrieb Daniel: > Hallo Max, > > ich nehme es auch nicht als böse auf. In zweiter Email schrieb ich > bereits, dass ich keine Lust habe auf V-Server da es irgendwie immer > mit ner Zeit Probleme gab. Mal hat nen Plesk Update halbe System > zerschossen oder plötzlich werden Prozesse beendet weil Software Limit > auf der VM erreicht sind oder ähnliches. Daher lieber nen inHouse > Server, der läuft, und kann jeder Zeit ran, und muss nicht Nachts 0900 > Support oder so anrufen weil VM mal wieder nicht erreichbar ist und > so. Oder wenn es nen Problem gibt, immer Kunde schuld sein soll > pauschal und die sich teils nicht zuständig fühlen. > > Nebeneffekt ist, sollte mal etwas sein im Rahmen irgendeiner > Ermittlung, kann die nicht einfach ne heimliche Kopie beim Hoster > mitnehmen, der einen dann nicht mal informieren darf. Da müsste man > schon dann vorbei kommen, und dann wüsste man auch bescheid. Also > nicht dass ich es erwarte oder hoffe, aber ist eben auch einer von > mehreren Aspekten. > > Genau wie dass man intern noch Mailen kann wären man grade Offline > ist, weil man Updates macht und so. Und wieso wozu extra übers > Internet drauf zugreifen und Leitung belasten wenn man es auch schön > mit GBit Netzwerk haben kann? > > Der Server hier der läuft und läuft soweit ohne Probleme, und kann den > ggf. auch jederzeit an Hardware anpassen wenn erforderlich. Mit dem > Relay läuft auch ohne Probleme, wollte zumindest prüfen welche > Möglichkeiten man nicht hat, um möglichst direkt auszuliefern. Das > Relay nimmt ja erstmal sogut wie alles an, ob Mail dann direkt am Ziel > ankommt, oder am Relay in Warteschleife hängt kann man bei fremden > Anbietern halt nicht sehen. Und für den kleinen Nutzerkreis brauche > ich auch keine Hochverfügbarkeits Server im Cluster in mehreren RZ die > noch über Kreuz synchronisieren falls mal nen RZ ausfällt oder so. > > Letztendlich muss es ja jeder selbst wissen, hat alles Vor- und > Nachteile. Danke für diese Erklärung das lässt einiges in einem anderen Licht erscheinen und macht es klarer, leider ändert es wenig an dem Problem. Was ich aber noch kenne, da ich es früher daheim benutzt habe ist der DSL von Manitu. https://www.manitu.de/dsl/dsl-flatrate/ Der setzt auf den T-DSL auf allerdings geht dann kein 50k weil VDSL nicht unterstützt wird, dort ist eine ipv4 inklusive. Mit vServern hab ich allerdings keine so schlechten Erfahrungen gemacht. Auf Panels und ähnlich Oberflächen verzichte ich gänzlich und konfiguriere alles 'zu Fuß' und wenn nicht grad Kernelupdates waren liefen die Kisten bis ich sie nicht mehr brauchte ohne weiteres Zutun. Naja aber wie Du sagtest is nich gewünscht. Mehr fällt mir diesbezüglich nun leider nicht mehr ein aber vllt. hat jemand noch eine Idee. > > Gruß Daniel > > -----Ursprüngliche Nachricht----- > Ich meinte damit nicht den VPN mit umständlich, wie gesagt wir haben > unseren MTA auf einem Root im Internet, dieser ist mit der Firma auch > via VPN angebunden und intern werkelt ein Exchange, das ist ja alles Ok > aber warum man mit aller macht über den DSL empfangen/versenden möchte > da macht man sich mehr Ärger als Nutzen mit. Wenn's nicht unbedingt ein > dedizierter Server sein muss tuts dafür ja auch ein minimalistischer > vServer, dann hat man auch alles unter Kontrolle und bezahlt nur > kleines > Geld. vServer gibts ja auch schon für'n 10er im Monat. Ich meins ja > nicht bös ich will ja nur helfen. > > > lg max lg max From daniel at ist-immer-online.de Fri Aug 28 13:45:24 2015 From: daniel at ist-immer-online.de (Daniel) Date: Fri, 28 Aug 2015 13:45:24 +0200 Subject: =?utf-8?Q?Re:_AW:_Optionen_f=C3=BCr_Mail_Versand_=C3=BCbern_DSL_?= =?utf-8?Q?Anschluss?= In-Reply-To: References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> <55DF5E31.4010307@ml.grobecker.info> <55DFDCCD.6090708@freecards.de> <001701d0e152$3ba45e20$b2ed1a60$@ist-immer-online.de> Message-ID: <6D9A6103-6BB7-4EC3-9CEC-D178C0DED31B@ist-immer-online.de> Hi Max, Anbei noch Link zum Transperenzbericht von 2014 zu den Behörden Anfragen. https://posteo.de/site/transparenzbericht_2014 Was bei Telekom und co abgeht will man glaub garnicht wissen... From klaus at tachtler.net Sat Aug 29 07:26:56 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Sat, 29 Aug 2015 07:26:56 +0200 Subject: Frage zu smtpd_relay_restrictions und smptd_recipient_restrictions... In-Reply-To: <20150827133816.Horde._9WgJ_JweZ2dmJTxJwg7wFs@buero.tachtler.net> Message-ID: <20150829072656.Horde.kxxWl1KiIMdvm_q6q9a4rv8@buero.tachtler.net> Hallo Liste, > Hallo Liste, > > ich hoffe ich nerve nicht zu sehr mit meinen vielen Fragen... > > Kann ich ALLE Einträge, welche ich bereits in > smtpd_relay_restrictions habe aus smtpd_recipient_restrictions > entfernen? > > DOPPELT WÄREN: permit_sasl_authenticated, permit_mynetworks, > permit_mx_backup, reject_unauth_destination? > > > smtpd_relay_restrictions = > # Permit all SASL authenticated users or clients from mynetworks. > permit_sasl_authenticated, > permit_mynetworks, > # Permit Backup-MX server. > permit_mx_backup, > # Reject relaying all others, to prevent to be an "open relay server". > reject_unauth_destination > Ich hab das jetzt mal so gemacht: smtpd_relay_restrictions = # Permit all clients from mynetworks. permit_mynetworks, # Reject relaying all others, to prevent to be an "open relay server". reject_unauth_destination > > smtpd_recipient_restrictions = > # RFC or important ROLE-Accounts - Whitelisting - like: postmaster, abuse. > check_recipient_access btree:/etc/postfix/check_recipient_access_rfc, > # White- and Blacklisting. > check_client_access cidr:/etc/postfix/check_client_access, > check_helo_access btree:/etc/postfix/check_helo_access, > check_sender_access btree:/etc/postfix/check_sender_access, > check_recipient_access btree:/etc/postfix/check_recipient_access, > # Reject unclean e-Mail. > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_invalid_helo_hostname, > # Permit all SASL authenticated users, or clients from mynetworks. > permit_sasl_authenticated, > permit_mynetworks, > # RBL and RHSBL checks. > reject_rbl_client zen.spamhaus.org=127.0.0.10, > reject_rbl_client zen.spamhaus.org=127.0.0.11, > reject_rbl_client zen.spamhaus.org, > reject_rbl_client ix.dnsbl.manitu.net, > reject_rbl_client bl.spamcop.net, > reject_rhsbl_client multi.uribl.com, > # Check dynamicaly existing Relay-Recipient. > reject_unverified_recipient, > # Permit Backup-MX. > permit_mx_backup, > # Reject relaying all others, to prevent to be an "open relay server". > reject_unauth_destination, > # Check dynamicaly the Quota-Status of the user against the dovecot > imap server. > check_policy_service inet:192.168.0.80:12340 > > und das so gemacht: smtpd_recipient_restrictions = # RFC or important ROLE-Accounts - Whitelisting - like: postmaster, abuse. check_recipient_access btree:/etc/postfix/check_recipient_access_rfc, # White- and Blacklisting. check_client_access cidr:/etc/postfix/check_client_access, check_helo_access btree:/etc/postfix/check_helo_access, check_sender_access btree:/etc/postfix/check_sender_access, check_recipient_access btree:/etc/postfix/check_recipient_access, # Reject unclean e-Mail. reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_invalid_helo_hostname, # RBL and RHSBL checks. reject_rbl_client zen.spamhaus.org=127.0.0.10, reject_rbl_client zen.spamhaus.org=127.0.0.11, reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, reject_rhsbl_client multi.uribl.com, # Check dynamicaly existing Relay-Recipient. reject_unverified_recipient, # Permit Backup-MX. permit_mx_backup, # Check dynamicaly the Quota-Status of the user against the dovecot imap server. check_policy_service inet:192.168.0.80:12340 Irgendwelche Kommentare, Anregungen oder Verbesserungen dazu? Danke schon in Voraus... Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From cvb at kruemel.org Sat Aug 29 16:46:26 2015 From: cvb at kruemel.org (cvb at kruemel.org) Date: Sat, 29 Aug 2015 16:46:26 +0200 Subject: Optionen =?UTF-8?Q?f=C3=BCr=20Mail=20Versand=20=C3=BCbern=20D?= =?UTF-8?Q?SL=20Anschluss?= In-Reply-To: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> References: <002401d0e034$48821430$d9863c90$@ist-immer-online.de> Message-ID: Am 2015-08-26 21:20, schrieb Daniel: > welche Optionen habe ich um vom DSL Anschluss Mails zu versenden? > Telekom Tarifwechsel möchte ich vermeiden, der Tarif mit fester IP > kostet fast 30? mehr im Monat. > Smarthost bzw. Relay von Telekom, 1&1 oder ähnlichen möchte ich > nicht verwenden, lieber wenn direkt zustellen. Aber Du kannst Dir bei einem Cloud-Hoster einen (virtuellen) Server mit IP buchen (das ist günstiger als die feste IP bei der Telekom) und dann ausgehenden Mailtraffic z.B. über Dein eigenes VPN zu dieser festen IP und dann weiter an den Zielhost routen. Das erfordert allerdings keine Änderungen an der Postfix-Konfiguration, sondern nur IP routing (und ggf. tagging / route und iptables). Deswegen sind weitere Fragen dazu vielleicht auch besser anderswo als auf dieser Mailingliste aufgehoben. > Problem ist ja nicht unbedingt die IP selbst sondern der Pool aus > dip0.t-ipconnect.de, welche ja auf der DNSBL stehen. Dieselben Probleme kannst Du allerdings bekommen, wenn die neue IP, die Du Dir beschaffst, eine schlechte Historie hat und deswegen auch auf vielen Listen zu finden ist. Gruß, Christian From django at nausch.org Sat Aug 29 20:55:07 2015 From: django at nausch.org (Django) Date: Sat, 29 Aug 2015 20:55:07 +0200 Subject: Frage zu SASL... In-Reply-To: <20150827113510.Horde.AdV3oE8HljikMS3t5MpiZW0@buero.tachtler.net> References: <20150827113510.Horde.AdV3oE8HljikMS3t5MpiZW0@buero.tachtler.net> Message-ID: <55E2000B.2010505@nausch.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 HI! Am 27.08.2015 um 11:35 schrieb Klaus Tachtler: > wie sollte das dann in Postfix konfiguriert werden, bzw. was ist > da "good practise"? Mogsd a Schein? ;) > Vielen Dank, schon mal für die Rückmeldungen! Biddsche! Servus Django -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV4gALAAoJEAdOz2FQpr/tUQ0P/RMEGQeRf9g9HjVG7d+gnAf/ dtbRA9tsOzj+OwdfDDI7V+E04X+CeHZsLzHNlogg44pmdZaMHIo0zW/bBLDQMswn R9UNLgvg3Hh50FVYKtkdPuq61Pq5edKxX7va5vWH0tvN/MrliSstgAd7CXPWr2oK boHI+C8xkxTyK9G0WC6HeBzcvE/8H6D4AgdMPvHTCVz1BQTd08rWIM801gWbg0S+ NfUzj1u2LMJOB2qRGh2L/V8FYZRVvK4Ux0JWxGFP6UScjMgO5V9j0hmkBVs86P1M KrLhl+jMYzUD9G5huUqcfVRBs63yKs1Hiost+E20cpelxi7IUKugS3RjD40RyZ41 lx4a9wRZDAz23W/FNq1uLHTc/Sfl1fKWh64NkLkc6SbzhzOBHARtzrSVp8S+wdDH If+tRTk8WDk/IBp6VQab+s+wnqxx5MEa26iAxxvrZOJelVw/gMxUtS86AnwUWzgl WSxzGwJPy32+xV/DOQh5m4g1Kr/rlKoK0ZsrSTGHADunUTH9zCr9yVFtVt6GhPM2 I3ZQz+VVZsyhlnnF30MZphwGA2GS/SYZ6qvd0Yg3gKqIFGBAxNF/i8cgCVMzprtT jqayeOsQOcgBO4FU5EAcwZrq8J0IjT8P5WViHBJO01XjZM/cz+4HuCm07U69flMO zbcXjzmuh+KzrU0C5jJ+ =1grI -----END PGP SIGNATURE----- From klaus at tachtler.net Sun Aug 30 07:08:27 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Sun, 30 Aug 2015 07:08:27 +0200 Subject: Frage zu SASL... In-Reply-To: <55E2000B.2010505@nausch.org> References: <20150827113510.Horde.AdV3oE8HljikMS3t5MpiZW0@buero.tachtler.net> <55E2000B.2010505@nausch.org> Message-ID: <20150830070827.Horde.yVOmhK-ztvo0dsECzj1Q03Z@buero.tachtler.net> Hallo Django, > HI! > > Am 27.08.2015 um 11:35 schrieb Klaus Tachtler: > >> wie sollte das dann in Postfix konfiguriert werden, bzw. was ist >> da "good practise"? > > Mogsd a Schein? ;) geht's auch ein bisschen konstruktiver, Herr Kollege! > >> Vielen Dank, schon mal für die Rückmeldungen! > > Biddsche! > Vielen Dank - erschöpfend wie immer ;-) > > Servus > Django p.s. - Beantworte mal meine letzte e-Mail, DANKE! Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From anmeyer at mailbox.org Sun Aug 30 12:50:06 2015 From: anmeyer at mailbox.org (Andreas Meyer) Date: Sun, 30 Aug 2015 12:50:06 +0200 Subject: Problem mit DKIM-Signatur Message-ID: <20150830125006.3c4f02b9@workstation.bitcorner.intern> Hallo Leute! Gestern habe ich ein neues Zertifkat für DKIM erzeugt und im DNS eingetragen. Das Problem ist z.B. folgendes: Authentication-Results: gerste.heinlein-support.de (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nimmini.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nimmini.de; h= content-transfer-encoding:content-type:content-type:mime-version :x-mailer:message-id:subject:subject:from:from:date:date; s= 20150830; t=1440925957; x=1442740358; bh=YJWMysPl36audKpPjWIG/TO l/JVGuKuq1l4/HEAjxb8=; b=hW0KgBBaoageOIpfMgEkLNVd//R0YKM7SdY0qDx lffcpWRySC+FN7Qm8p/FD9ofOVTVGgc4OvxqVg0dTSFBR1An7QBK959CpKo1Pocf QLi+8uwCMPMv7H4lKLDuY9ukgBFB8eQJ0cRFM/B1LfD8uSvK9oU/AnRVYkodzWEx Zw+U= im Gegensatz zu: Authentication-Results: mail.bitcorner.de (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=nimmini.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nimmini.de; h= content-transfer-encoding:content-type:content-type:mime-version :x-mailer:message-id:subject:subject:from:from:date:date; s= 20150830; t=1440931113; x=1442745514; bh=iQwdeyYe4eyyFdLLYcnWKOH rp15fjDsK43dq50gskW8=; b=b0fNvWM2LvKxRFEOdujJwkOQUpPODzIWIalhNmh RSukTSDPHAcQ7TSFel23VxpkJdFG4bM4jQ4zZIqcj2qYmAe3iYVNKDIN/S4bbBaR mkDfT2ooRg2F+L9w+Sd2rfVQZgJVDbbpKVOwWcAmiDU5dtBDyt6ZlYd+Qkf4pBXA TvJc= In der amavis.conf habe ich $signed_header_fields{'received'} = 0; gesetzt, aber das löst das Problem des dkim=fail nicht. Hat jemand Rat? Grüße Andreas