From daniel at ist-immer-online.de Fri Apr 1 20:44:41 2016 From: daniel at ist-immer-online.de (Daniel) Date: Fri, 1 Apr 2016 20:44:41 +0200 Subject: Problem mit tls_security_level Message-ID: <007701d18c46$8d416e90$a7c44bb0$@ist-immer-online.de> Huhu, ich habe 2 Probleme, wenn ich smtpd_tls_security_level von "may" auf "encrypt" setze, kommen keine Mails mehr an. Im log steht dann z.B. postfix/smtpd[30166]: connect from verifier.port25.com[38.95.177.125] postfix/smtpd[30166]: disconnect from verifier.port25.com[38.95.177.125] ehlo=1 mail=0/1 rcpt=0/1 data=0/1 quit=1 commands=2/5 Ich möchte verschlüsselt erzwingen, und nicht nur optional. Unverschlüsselt wird i.d.R. eh nicht mehr verwendet, und wenn doch kann man auch drauf verzichten, daher nicht mehr optional. Und wenn ich Mails versende an Server wie z.B. Posteo die DANE verwenden ist die Verbindung nur " Trusted" und nicht "Verified". Woran liegt es? Konfig Auszug: broken_sasl_auth_clients = yes disable_vrfy_command = yes duplicate_filter_limit = 32768 inet_protocols = ipv4, ipv6 mailbox_size_limit = 0 message_drop_headers = bcc, content-length, resent-bcc strict_rfc821_envelopes = yes smtp_dns_support_level = dnssec smtp_host_lookup = dns, native smtp_tls_CApath = /etc/ssl/certs/ smtp_tls_ciphers = high smtp_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDB3-SHA, KRB5-DES, CBC3-SHA smtp_tls_fingerprint_digest = SHA256 smtp_tls_loglevel = 1 smtp_tls_mandatory_ciphers= high smtp_tls_mandatory_protocols = !SSLv2,!SSLv3 smtp_tls_note_starttls_offer = yes smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_security_level = dane smtpd_client_restrictions = check_client_access hash:/etc/access/client_access, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname smtpd_data_restrictions = reject_unauth_pipelining, reject_multi_recipient_bounce smtpd_relay_restrictions = $smtpd_recipient_restrictions smtpd_sasl_authenticated_header = yes smtpd_tls_ask_ccert = yes smtpd_tls_auth_only = yes smtpd_tls_cert_file = /usr/etc/postfix/fullchain.pem smtpd_tls_ciphers = high smtpd_tls_dh1024_param_file = /usr/etc/ssl/dh4096.pem smtpd_tls_eecdh_grade = strong smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDB3-SHA, KRB5-DES, CBC3-SHA smtpd_tls_fingerprint_digest = SHA256 smtpd_tls_key_file = /usr/etc/postfix/privkey.pem smtpd_tls_loglevel = 1 smtpd_tls_mandatory_ciphers= high smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3 smtpd_tls_protocols = !SSLv2,!SSLv3 smtpd_tls_received_header = yes smtpd_tls_security_level = may tls_daemon_random_bytes = 64 tls_high_cipherlist = EECDH+AESGCM:AES+EECDH:+ECDHE-RSA-AES256-SHA:+ECDHE-RSA-AES128-SHA:RSA+AESGCM:RSA+AES:RSA+CAMELLIA:+AES256-SHA:+AES128-SHA:!EXPORT:! eNULL:!aNULL:!DES:!3DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK tls_preempt_cipherlist = yes tls_random_bytes = 64 tls_ssl_options = no_ticket, no_compression Gruß Daniel From postfixbuch-users at 0xaffe.de Fri Apr 1 20:47:46 2016 From: postfixbuch-users at 0xaffe.de (Mathias Jeschke) Date: Fri, 1 Apr 2016 20:47:46 +0200 Subject: Problem mit tls_security_level In-Reply-To: <007701d18c46$8d416e90$a7c44bb0$@ist-immer-online.de> References: <007701d18c46$8d416e90$a7c44bb0$@ist-immer-online.de> Message-ID: <56FEC252.7000202@0xaffe.de> Am 01.04.16 um 20:44 schrieb Daniel: > ich habe 2 Probleme, wenn ich smtpd_tls_security_level von "may" auf "encrypt" setze, kommen keine Mails mehr an. Im log steht dann > z.B. > > postfix/smtpd[30166]: connect from verifier.port25.com[38.95.177.125] > postfix/smtpd[30166]: disconnect from verifier.port25.com[38.95.177.125] ehlo=1 mail=0/1 rcpt=0/1 data=0/1 quit=1 commands=2/5 > > Ich möchte verschlüsselt erzwingen, und nicht nur optional. Unverschlüsselt wird i.d.R. eh nicht mehr verwendet, und wenn doch kann > man auch drauf verzichten, daher nicht mehr optional. Das scheint wohl "verifier.port25.com" anders zu sehen - er will offenbar nicht mit Dir verschlüsselt kommunizieren ;-) SCNR. Mathias. From daniel at ist-immer-online.de Fri Apr 1 21:04:39 2016 From: daniel at ist-immer-online.de (Daniel) Date: Fri, 1 Apr 2016 21:04:39 +0200 Subject: AW: Problem mit tls_security_level In-Reply-To: <56FEC252.7000202@0xaffe.de> References: <007701d18c46$8d416e90$a7c44bb0$@ist-immer-online.de> <56FEC252.7000202@0xaffe.de> Message-ID: <007901d18c49$57a530c0$06ef9240$@ist-immer-online.de> Hi Mathias, postfix/smtpd[22500]: connect from verifier.port25.com[38.95.177.125] postfix/policy-spf[22505]: Policy action=PREPEND Received-SPF: pass (verifier.port25.com: 38.95.177.125 is authorized to use 'auth-results at verifier.port25.com' in 'mfrom' identity (mechanism 'a' matched)) receiver=Server; identity=mailfrom; envelope-from="auth-results at verifier.port25.com"; helo=verifier.port25.com; client-ip=38.95.177.125 postfix/policy-spf[22505]: Policy action=DUNNO postfix/smtpd[22500]: D17E032E8021: client=verifier.port25.com[38.95.177.125] ... postfix/smtpd[22500]: disconnect from verifier.port25.com[38.95.177.125] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Stimmt wenn mit may angenommen wird, fehlt da wohl wirklich was. Posteo hat der aber auch nicht genommen, da "Untrusted" obwohl Cert vertrauenswürdig ist, und zusätzlich DANE verwende. postfix/smtpd[594]: connect from mout01.posteo.de[185.67.36.65] postfix/smtpd[594]: Untrusted TLS connection established from mout01.posteo.de[185.67.36.65]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) postfix/smtpd[594]: NOQUEUE: abort: TLS from mout01.posteo.de[185.67.36.65]: Client certificate not trusted postfix/smtpd[594]: disconnect from mout01.posteo.de[185.67.36.65] ehlo=1 starttls=1 commands=2 -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Mathias Jeschke Gesendet: Freitag, 1. April 2016 20:48 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: Problem mit tls_security_level Am 01.04.16 um 20:44 schrieb Daniel: > ich habe 2 Probleme, wenn ich smtpd_tls_security_level von "may" auf "encrypt" setze, kommen keine Mails mehr an. Im log steht dann > z.B. > > postfix/smtpd[30166]: connect from verifier.port25.com[38.95.177.125] > postfix/smtpd[30166]: disconnect from verifier.port25.com[38.95.177.125] ehlo=1 mail=0/1 rcpt=0/1 data=0/1 quit=1 commands=2/5 > > Ich möchte verschlüsselt erzwingen, und nicht nur optional. Unverschlüsselt wird i.d.R. eh nicht mehr verwendet, und wenn doch kann > man auch drauf verzichten, daher nicht mehr optional. Das scheint wohl "verifier.port25.com" anders zu sehen - er will offenbar nicht mit Dir verschlüsselt kommunizieren ;-) SCNR. Mathias. From jra at byte.cx Fri Apr 1 23:28:56 2016 From: jra at byte.cx (Jens Adam) Date: Fri, 1 Apr 2016 23:28:56 +0200 Subject: Problem mit tls_security_level In-Reply-To: <007901d18c49$57a530c0$06ef9240$@ist-immer-online.de> References: <007701d18c46$8d416e90$a7c44bb0$@ist-immer-online.de> <56FEC252.7000202@0xaffe.de> <007901d18c49$57a530c0$06ef9240$@ist-immer-online.de> Message-ID: <20160401232856.284215c2.jra@byte.cx> Fri, 1 Apr 2016 21:04:39 +0200 "Daniel" : > postfix/smtpd[22500]: disconnect from verifier.port25.com[38.95.177.125] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 > > Stimmt wenn mit may angenommen wird, fehlt da wohl wirklich was. Der Client macht halt kein STARTTLS, so what? Ist anhand des Hostnamens wohl auch zu vermuten. > Posteo hat der aber auch nicht genommen, da "Untrusted" obwohl Cert > vertrauenswürdig ist, und zusätzlich DANE verwende. > > postfix/smtpd[594]: connect from mout01.posteo.de[185.67.36.65] > postfix/smtpd[594]: Untrusted TLS connection established from mout01.posteo.de[185.67.36.65]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) > postfix/smtpd[594]: NOQUEUE: abort: TLS from mout01.posteo.de[185.67.36.65]: Client certificate not trusted > postfix/smtpd[594]: disconnect from mout01.posteo.de[185.67.36.65] ehlo=1 starttls=1 commands=2 Wozu brauchst du smtpd_tls_ask_ccert? Du hast kein smtpd_tls_CA(path|file) gesetzt. Vielleicht auch chroot-Problem? Die Cipher-Auswahl bzw. -Zusammenschrumpfung sehe ich auch recht kritisch. Ansonsten bleibt nur die obligatorische Frage - warum "encrypt"? Den Part mit "According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced SMTP server." hast du ja bestimmt gesehen. Und du schriebst selbst "und wenn doch kann man auch drauf verzichten" - tja, so ist das dann halt, dass diverse Server ihre Mails nicht mehr bei dir loswerden. --byte -------------- 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 daniel at ist-immer-online.de Sat Apr 2 06:33:38 2016 From: daniel at ist-immer-online.de (Daniel) Date: Sat, 2 Apr 2016 06:33:38 +0200 Subject: AW: Problem mit tls_security_level In-Reply-To: <20160401232856.284215c2.jra@byte.cx> References: <007701d18c46$8d416e90$a7c44bb0$@ist-immer-online.de> <56FEC252.7000202@0xaffe.de> <007901d18c49$57a530c0$06ef9240$@ist-immer-online.de> <20160401232856.284215c2.jra@byte.cx> Message-ID: <000701d18c98$d399ba80$7acd2f80$@ist-immer-online.de> Moin byte, smtpd_tls_CApath = /etc/ssl/certs/ habe ich nun noch gesetzt. Nun kommt auch Testmail von Posteo durch mit encrypt. In dem Fall sowie bei may steht dort nun "Untrusted" und kein "Anonymous" mehr. Ich lass es sonst nun weiterhin auf may vorerst. Jetzt bleibt Frage, wieso alles "Untrusted" ist, besonders beim Versand mit Dane. root:~# posttls-finger -t30 -T180 -c -L verbose,summary posteo.de posttls-finger: initializing the client-side TLS engine posttls-finger: setting up TLS connection to mx01.posteo.de[185.67.36.61]:25 posttls-finger: mx01.posteo.de[185.67.36.61]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL" posttls-finger: mx01.posteo.de[185.67.36.61]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Extended Validation Server CA posttls-finger: mx01.posteo.de[185.67.36.61]:25: depth=0 verify=1 subject=/C=DE/ST=Berlin/L=Berlin/postalCode=10965/street=Methfesselstra\xDFe 38/O=Posteo e.K./CN=www.posteo.de/emailAddress=postmaster at posteo.de/serialNumber=HRA 47592/businessCategory=Private Organization/jurisdictionL=Charlottenburg/jurisdictionST=Berlin posttls-finger: certificate verification failed for mx01.posteo.de[185.67.36.61]:25: untrusted issuer /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority posttls-finger: mx01.posteo.de[185.67.36.61]:25: subject_CN=www.posteo.de, issuer_CN=StartCom Extended Validation Server CA, fingerprint=3A:89:D8:AD:DC:A7:23:5C:8F:44:E9:DD:2E:85:6A:31:D2:D3:C9:70, pkey_fingerprint=6B:63:F4:BD:E8:1F:0E:BA:52:85:51:3D:EF:DF:51:46:E1:C2:3C:4D posttls-finger: Untrusted TLS connection established to mx01.posteo.de[185.67.36.61]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Die Cipher-Auswahl habe ich extra beschränkt, wegen ganzen Schwachstellen (beast, poodle, ect.), und bisher habe ich damit noch keine Probleme gehabt. Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Jens Adam Gesendet: Freitag, 1. April 2016 23:29 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: Problem mit tls_security_level Fri, 1 Apr 2016 21:04:39 +0200 "Daniel" : > postfix/smtpd[22500]: disconnect from verifier.port25.com[38.95.177.125] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 > > Stimmt wenn mit may angenommen wird, fehlt da wohl wirklich was. Der Client macht halt kein STARTTLS, so what? Ist anhand des Hostnamens wohl auch zu vermuten. > Posteo hat der aber auch nicht genommen, da "Untrusted" obwohl Cert > vertrauenswürdig ist, und zusätzlich DANE verwende. > > postfix/smtpd[594]: connect from mout01.posteo.de[185.67.36.65] > postfix/smtpd[594]: Untrusted TLS connection established from mout01.posteo.de[185.67.36.65]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) > postfix/smtpd[594]: NOQUEUE: abort: TLS from mout01.posteo.de[185.67.36.65]: Client certificate not trusted > postfix/smtpd[594]: disconnect from mout01.posteo.de[185.67.36.65] ehlo=1 starttls=1 commands=2 Wozu brauchst du smtpd_tls_ask_ccert? Du hast kein smtpd_tls_CA(path|file) gesetzt. Vielleicht auch chroot-Problem? Die Cipher-Auswahl bzw. -Zusammenschrumpfung sehe ich auch recht kritisch. Ansonsten bleibt nur die obligatorische Frage - warum "encrypt"? Den Part mit "According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced SMTP server." hast du ja bestimmt gesehen. Und du schriebst selbst "und wenn doch kann man auch drauf verzichten" - tja, so ist das dann halt, dass diverse Server ihre Mails nicht mehr bei dir loswerden. --byte From max.grobecker at ml.grobecker.info Sat Apr 2 11:51:01 2016 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Sat, 2 Apr 2016 11:51:01 +0200 Subject: Problem mit tls_security_level In-Reply-To: <007901d18c49$57a530c0$06ef9240$@ist-immer-online.de> References: <007701d18c46$8d416e90$a7c44bb0$@ist-immer-online.de> <56FEC252.7000202@0xaffe.de> <007901d18c49$57a530c0$06ef9240$@ist-immer-online.de> Message-ID: <56FF9605.4040406@ml.grobecker.info> Ola Daniel, Am 01.04.2016 um 21:04 schrieb Daniel: > Posteo hat der aber auch nicht genommen, da "Untrusted" obwohl Cert vertrauenswürdig ist, und zusätzlich DANE verwende. Verwendest du einen DNS-Resolver der DNSSEC-Verifizierung durchführt? Das ist eine zwingende Vorgabe für DANE, da du ja ohne DNSSEC nicht sicherstellen kannst, dass die DNS-Antworten nicht gefälscht sind. Zum *TESTEN* (!!) kannst du da vorübergehend die Google-DNS nehmen, für den Produktivbetrieb mit DANE solltest du dir auf deinem Mailserver einen kleinen DNSSEC-Resolver installieren und diesen benutzen. 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.grobecker at ml.grobecker.info Sat Apr 2 12:04:37 2016 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Sat, 2 Apr 2016 12:04:37 +0200 Subject: =?UTF-8?Q?Re:_Amavis_und_Mailanh=c3=a4nge?= In-Reply-To: <243016E7989B3045AA79AADDA18308254D985416@srv02029.Admin.local> References: <243016E7989B3045AA79AADDA18308254D985416@srv02029.Admin.local> Message-ID: <56FF9935.3070100@ml.grobecker.info> Moin, werden ausgehende Mails überhaupt durch deinen Amavis geschoben? Was sagt denn das Logfile? 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 daniel at ist-immer-online.de Sat Apr 2 12:17:31 2016 From: daniel at ist-immer-online.de (Daniel) Date: Sat, 2 Apr 2016 12:17:31 +0200 Subject: AW: Problem mit tls_security_level In-Reply-To: <56FF9605.4040406@ml.grobecker.info> References: <007701d18c46$8d416e90$a7c44bb0$@ist-immer-online.de> <56FEC252.7000202@0xaffe.de> <007901d18c49$57a530c0$06ef9240$@ist-immer-online.de> <56FF9605.4040406@ml.grobecker.info> Message-ID: <000a01d18cc8$de0a4d60$9a1ee820$@ist-immer-online.de> Hi Max, wird ganz normal DNS und vom Provider und/oder Google als mix verwendet. Wenn ich Cert nicht mehr anfordere gibt es wohl nichts zu prüfen, und daher nun wieder alles anonym. Problem war, dass Mailprogramme beim senden halt kein Cert liefern und dann Fehler gab. Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Max Grobecker Gesendet: Samstag, 2. April 2016 11:51 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: Problem mit tls_security_level Ola Daniel, Am 01.04.2016 um 21:04 schrieb Daniel: > Posteo hat der aber auch nicht genommen, da "Untrusted" obwohl Cert vertrauenswürdig ist, und zusätzlich DANE verwende. Verwendest du einen DNS-Resolver der DNSSEC-Verifizierung durchführt? Das ist eine zwingende Vorgabe für DANE, da du ja ohne DNSSEC nicht sicherstellen kannst, dass die DNS-Antworten nicht gefälscht sind. Zum *TESTEN* (!!) kannst du da vorübergehend die Google-DNS nehmen, für den Produktivbetrieb mit DANE solltest du dir auf deinem Mailserver einen kleinen DNSSEC-Resolver installieren und diesen benutzen. Viele Grüße aus dem Tal Max From daniel at ist-immer-online.de Sat Apr 2 12:19:59 2016 From: daniel at ist-immer-online.de (Daniel) Date: Sat, 2 Apr 2016 12:19:59 +0200 Subject: =?iso-8859-1?Q?AW:_Amavis_und_Mailanh=E4nge?= In-Reply-To: <56FF9935.3070100@ml.grobecker.info> References: <243016E7989B3045AA79AADDA18308254D985416@srv02029.Admin.local> <56FF9935.3070100@ml.grobecker.info> Message-ID: <000e01d18cc9$364b3a70$a2e1af50$@ist-immer-online.de> Hi, log ist da nur sehr kurz postfix/smtpd[8630]: Anonymous TLS connection established from unknown[IP]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) postfix/smtpd[8630]: NOQUEUE: abort: TLS from unknown[IP]: No client certificate presented postfix/smtpd[8630]: disconnect from unknown[IP] ehlo=1 starttls=1 commands=2 Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Max Grobecker Gesendet: Samstag, 2. April 2016 12:05 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: Amavis und Mailanhänge Moin, werden ausgehende Mails überhaupt durch deinen Amavis geschoben? Was sagt denn das Logfile? Viele Grüße aus dem Tal Max From w.flamme at web.de Mon Apr 4 09:36:05 2016 From: w.flamme at web.de (Werner Flamme) Date: Mon, 4 Apr 2016 09:36:05 +0200 Subject: Problem mit tls_security_level In-Reply-To: <000701d18c98$d399ba80$7acd2f80$@ist-immer-online.de> References: <007701d18c46$8d416e90$a7c44bb0$@ist-immer-online.de> <56FEC252.7000202@0xaffe.de> <007901d18c49$57a530c0$06ef9240$@ist-immer-online.de> <20160401232856.284215c2.jra@byte.cx> <000701d18c98$d399ba80$7acd2f80$@ist-immer-online.de> Message-ID: <57021965.6020309@web.de> Daniel [02.04.2016 06:33]: > Moin byte, > > smtpd_tls_CApath = /etc/ssl/certs/ habe ich nun noch gesetzt. > > Nun kommt auch Testmail von Posteo durch mit encrypt. In dem Fall sowie bei may steht dort nun "Untrusted" und kein "Anonymous" mehr. Ich lass es sonst nun weiterhin auf may vorerst. > > Jetzt bleibt Frage, wieso alles "Untrusted" ist, besonders beim Versand mit Dane. "Untrusted" wird gemeldet, wenn Du dem Zertifikat der Gegenstelle nicht vertraust. Z. B. deshalb, weil Du dessen Root-CA nicht in der CA-Liste hast. Gruß Werner -- -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 473 bytes Beschreibung: OpenPGP digital signature URL : From postfixer99 at gmail.com Mon Apr 4 14:07:49 2016 From: postfixer99 at gmail.com (Carsten) Date: Mon, 4 Apr 2016 14:07:49 +0200 Subject: =?UTF-8?Q?Unvollst=c3=a4ndige_Absenderadresse_wird_umgeschrieben?= Message-ID: <57025915.8080901@gmail.com> Hallo zusammen, ich habe das Problem, dass mein Mailserver bei leerer Message-ID und unvollständigen Quelladressen die Domain des Mailservers anhängt. Mein Mailserver empfängt Mails von Maschinen, die in mynetworks gelistet sind. Mar 30 15:06:41 maschine postfix-instanz_01/smtpd[28693]: 85C1896145: client=unknown[10.20.1.10] Mar 30 15:06:41 maschine postfix-instanz_01/cleanup[1986]: 85C1896145: message-id=<> Mar 30 15:06:41 maschine postfix-instanz_01/qmgr[4176]: 85C1896145: from=, size=4098, nrcpt=1 (queue active) Komisch ist auch das Dollar-Zeichen, aber das wird eventuell auch durch den einliefernden Client produziert. Postfix 2.9.4 ist im Einsatz. Konfigurationsauszug aus postconf: ---------------------------------- local_header_rewrite_clients = permit_inet_interfaces remote_header_rewrite_domain = rewrite_service_name = rewrite append_at_myorigin = yes append_dot_mydomain = yes Da es sich um ein Produktivsystem handelt, kann ich hier nicht ausprobieren, sondern möchte wissen, wie ich es richtig einstelle. Wenn ich es richtig verstehe, bezieht sich "append_dot_mydomain" doch auf die Zieladresse und nicht um die hier umgeschriebene Quelladresse. Was kann ich tun? Bin für jede Hilfe dankbar. Gruß Carsten From p at sys4.de Mon Apr 4 16:24:03 2016 From: p at sys4.de (Patrick Ben Koetter) Date: Mon, 4 Apr 2016 16:24:03 +0200 Subject: =?utf-8?Q?Unvollst=C3=A4ndig?= =?utf-8?Q?e?= Absenderadresse wird umgeschrieben In-Reply-To: <57025915.8080901@gmail.com> References: <57025915.8080901@gmail.com> Message-ID: <20160404142403.GA23745@sys4.de> * Carsten : > Hallo zusammen, > > ich habe das Problem, dass mein Mailserver bei leerer Message-ID und > unvollständigen Quelladressen die Domain des Mailservers anhängt. > Mein Mailserver empfängt Mails von Maschinen, die in mynetworks > gelistet sind. Setze reject_non_fqdn_sender in Deinen Restrictions. Die folgenden Filter sollte IMO jeder einsetzen. Sie stellen grundlegende Transportfähigkeit sicher: smtpd_recipient_restrictions = # Nur vollstaendige Senderadressen annehmen reject_non_fqdn_sender # Nur vollstaendige Empfaengeradressen annehmen reject_non_fqdn_recipient # Keine Mails von unbekannten (DNS) Domains annehmen, denn wir koennten # nicht bouncen reject_unknown_sender_domain # Keine Mails an unbekannte (DNS) Domains annehmen, denn wir koennen nicht # zustellen und muessen die Mail nur wieder hochwuergen... ;) reject_unknown_recipient_domain Wenn Du das hast, dann sieh Dir an, wer seine Mails nicht mehr loswird. Wenn Du das in Produktion testen willst setze immer "warn_if_reject" vor die Filter. Dann siehst Du den Logeintrag aber der Filter wird nicht ausgeführt. p at rick > > Mar 30 15:06:41 maschine postfix-instanz_01/smtpd[28693]: > 85C1896145: client=unknown[10.20.1.10] > Mar 30 15:06:41 maschine postfix-instanz_01/cleanup[1986]: > 85C1896145: message-id=<> > Mar 30 15:06:41 maschine postfix-instanz_01/qmgr[4176]: 85C1896145: > from=, size=4098, nrcpt=1 (queue > active) > > Komisch ist auch das Dollar-Zeichen, aber das wird eventuell auch > durch den einliefernden Client produziert. > > Postfix 2.9.4 ist im Einsatz. > > Konfigurationsauszug aus postconf: > ---------------------------------- > local_header_rewrite_clients = permit_inet_interfaces > remote_header_rewrite_domain = > rewrite_service_name = rewrite > append_at_myorigin = yes > append_dot_mydomain = yes > > Da es sich um ein Produktivsystem handelt, kann ich hier nicht > ausprobieren, sondern möchte wissen, wie ich es richtig einstelle. > > Wenn ich es richtig verstehe, bezieht sich "append_dot_mydomain" > doch auf die Zieladresse und nicht um die hier umgeschriebene > Quelladresse. > Was kann ich tun? > > Bin für jede Hilfe dankbar. > > Gruß > Carsten -- [*] 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 w.flamme at web.de Tue Apr 5 08:38:21 2016 From: w.flamme at web.de (Werner Flamme) Date: Tue, 5 Apr 2016 08:38:21 +0200 Subject: =?UTF-8?Q?Re:_Unvollst=c3=a4ndige_Absenderadresse_wird_umgeschriebe?= =?UTF-8?Q?n?= In-Reply-To: <57025915.8080901@gmail.com> References: <57025915.8080901@gmail.com> Message-ID: <57035D5D.9090702@web.de> Carsten [04.04.2016 14:07]: > Hallo zusammen, Hallo Carsten, > ich habe das Problem, dass mein Mailserver bei leerer Message-ID und > unvollständigen Quelladressen die Domain des Mailservers anhängt. Den Grund hast Du in Deiner Konfig stehen: append_dot_mydomain = yes siehe z. B. - erster Satz: "With locally submitted mail, append the string ".$mydomain" to addresses that have no ".domain" information.". > Wenn ich es richtig verstehe, bezieht sich "append_dot_mydomain" doch > auf die Zieladresse und nicht um die hier umgeschriebene Quelladresse. > Was kann ich tun? Da steht nichts von Quell- oder Zieladresse... Was Postfix unter "local" versteht, wir in anderen Parametern definiert (local_header_rewrite_clients). Klick Dich mal durch die Seite :) ===schnipp=== local_header_rewrite_clients (default: permit_inet_interfaces) Rewrite message header addresses in mail from these clients and update incomplete addresses with the domain name in $myorigin or $mydomain; [...] ===schnapp=== > Bin für jede Hilfe dankbar. Hoffentlich ist das eine :) Gruß Werner -- -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 473 bytes Beschreibung: OpenPGP digital signature URL : From ralf.hansen2000 at yahoo.de Tue Apr 5 10:14:31 2016 From: ralf.hansen2000 at yahoo.de (Ralf Hansen) Date: Tue, 5 Apr 2016 10:14:31 +0200 Subject: =?UTF-8?Q?Re:_Unvollst=c3=a4ndige_Absenderadresse_wird_umgeschriebe?= =?UTF-8?Q?n?= In-Reply-To: <20160404142403.GA23745@sys4.de> References: <57025915.8080901@gmail.com> <20160404142403.GA23745@sys4.de> Message-ID: <570373E7.8090500@yahoo.de> Am 04.04.2016 um 16:24 schrieb Patrick Ben Koetter: > smtpd_recipient_restrictions = > # Nur vollstaendige Senderadressen annehmen > reject_non_fqdn_sender > # Nur vollstaendige Empfaengeradressen annehmen > reject_non_fqdn_recipient > # Keine Mails von unbekannten (DNS) Domains annehmen, denn wir koennten > # nicht bouncen > reject_unknown_sender_domain > # Keine Mails an unbekannte (DNS) Domains annehmen, denn wir koennen nicht > # zustellen und muessen die Mail nur wieder hochwuergen... ;) > reject_unknown_recipient_domain vielen Dank Patrick. So ist das mit "DenWald vor lauter Bäumen nicht geshen ^^". Was auf einem Border-Filter selbstverständlich ist, habe ich auf einem rein internen Relay einfach ignoriert und mir von meinen eigenen usern "permit_mynetworks" alles unterschieben lassen, was natürlich so nicht sein soll. Restrictions werde ich wieder einbauen ;-) > Wenn Du das hast, dann sieh Dir an, wer seine Mails nicht mehr loswird. Wenn > Du das in Produktion testen willst setze immer "warn_if_reject" vor die > Filter. Dann siehst Du den Logeintrag aber der Filter wird nicht ausgeführt. > Guter Hinweis! Muchas gracias. Carsten From postfixer99 at gmail.com Tue Apr 5 10:23:13 2016 From: postfixer99 at gmail.com (Carsten) Date: Tue, 5 Apr 2016 10:23:13 +0200 Subject: =?UTF-8?Q?Re:_Unvollst=c3=a4ndige_Absenderadresse_wird_umgeschriebe?= =?UTF-8?Q?n?= In-Reply-To: <57035D5D.9090702@web.de> References: <57025915.8080901@gmail.com> <57035D5D.9090702@web.de> Message-ID: <570375F1.90209@gmail.com> Am 05.04.2016 um 08:38 schrieb Werner Flamme: > Den Grund hast Du in Deiner Konfig stehen: append_dot_mydomain = yes Danke Werner. Wir werden den Vorschlag von Patrick aufgreifen, die Restrictions anpassen, und auch gleich (wie Du schreibst) append_not_mydomain = no setzen. Dann sollte unsere Konfig sauber sein. Gruß Carsten From daniel at ist-immer-online.de Sun Apr 3 12:16:54 2016 From: daniel at ist-immer-online.de (Daniel) Date: Sun, 3 Apr 2016 12:16:54 +0200 Subject: AW: Problem mit tls_security_level In-Reply-To: <56FF9605.4040406@ml.grobecker.info> References: <007701d18c46$8d416e90$a7c44bb0$@ist-immer-online.de> <56FEC252.7000202@0xaffe.de> <007901d18c49$57a530c0$06ef9240$@ist-immer-online.de> <56FF9605.4040406@ml.grobecker.info> Message-ID: <000d01d18d91$f24445f0$d6ccd1d0$@ist-immer-online.de> Anscheint wird nicht verifiziert, kommt irgendwie wie schon erwähnt eher trusted oder untrustet aber eher kein verify. Es wird von Postfix auch nicht die Datenbank angelegt für address_verify_map = btree:$data_directory/verify Selbst wenn ich mit einem Trick die verify.db anlegen lassen habe, wird diese nicht von postfix beschrieben. In der master ist verfiy auf Stanadardwert. Im log steht auch nichts von, dass der nicht auf die CA Certs zugreifen kann in /etc/ssl/certs/ bzw. /usr/share/ca-certificates/mozilla Die Werte sind auch gesetzt smtp_tls_CApath = /etc/ssl/certs/ smtpd_tls_CApath = /etc/ssl/certs/ Konfig findet ihr in ersten Mail von Freitag Möchte halt gerne Cert anfragen und auch gegen CA prüfen, optional soll alles verify sein im Log, notfalls untrusted, aber nicht mehr anonym. Gruß Daniel From stickybit at myhm.de Fri Apr 8 13:05:40 2016 From: stickybit at myhm.de (Andre) Date: Fri, 8 Apr 2016 13:05:40 +0200 Subject: authorized_submit_users Message-ID: <57079084.7050405@myhm.de> Servus, wenn ein User per authorized_submit_users gesperrt wurde, haut Postfix "fatal: User user(userid) is not allowed to submit mail" in die Shell raus, wenn man eingeloggt ist. Lässt sich das irgendwie unterbinden? LG Andre From jra at byte.cx Fri Apr 8 13:19:24 2016 From: jra at byte.cx (Jens Adam) Date: Fri, 8 Apr 2016 13:19:24 +0200 Subject: authorized_submit_users In-Reply-To: <57079084.7050405@myhm.de> References: <57079084.7050405@myhm.de> Message-ID: <20160408131924.360c8dcd.jra@byte.cx> Fri, 8 Apr 2016 13:05:40 +0200 Andre : > wenn ein User per authorized_submit_users gesperrt wurde, haut Postfix > > "fatal: User user(userid) is not allowed to submit mail" > > in die Shell raus, wenn man eingeloggt ist. Lässt sich das irgendwie > unterbinden? Probier mal 'dmesg -n 2'. Schrittweise erhöhen bis die Meldung wieder auftaucht und dann den Wert davor behalten; könnte man anschließend in die .bash_profile packen. --byte -------------- 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 stickybit at myhm.de Fri Apr 8 13:49:33 2016 From: stickybit at myhm.de (Andre) Date: Fri, 8 Apr 2016 13:49:33 +0200 Subject: authorized_submit_users In-Reply-To: <20160408131924.360c8dcd.jra@byte.cx> References: <57079084.7050405@myhm.de> <20160408131924.360c8dcd.jra@byte.cx> Message-ID: <57079ACD.9030203@myhm.de> > Probier mal 'dmesg -n 2'. > Schrittweise erhöhen bis die Meldung wieder auftaucht und dann den Wert > davor behalten; könnte man anschließend in die .bash_profile packen. Danke, Jens! From pkoch at bgc-jena.mpg.de Mon Apr 18 13:44:19 2016 From: pkoch at bgc-jena.mpg.de (Dr.Peer-Joachim Koch) Date: Mon, 18 Apr 2016 13:44:19 +0200 Subject: OT: cyrus + mutt + web gui + user = problem Message-ID: <5714C893.2060006@bgc-jena.mpg.de> Hallo, bin gerade über ein "interessantes" Problem gestolpert das ich noch nicht lösen konnte. Vielleicht hat jemand so etwas schon gesehen ... Also alle Mails liegen bei uns zentral auf einen Mailserver (cyrus). Ein Nutzer greift per mutt darauf zu und legt eine lokale Kopie auf dem eigenen Rechner an. Bearbeitet werden die Mail vorrangig über unser WEB-GUI (open xchange per IMAP angebunden). Der USER macht jetzt folgendes: Um Platz zu sparen werden alle Anhänge mittels MUTT gelöscht und anschließend die lokale Mail wieder mit dem Mailserver gesynct. Der Open-Xchange zeigt jetzt ein andere Uhrzeit (unsystematisch) für eine so veränderte Mail an. Im Mailheader (bzw. in der ganzen Mail) sind aber noch alle Zeitstempel wie vorher. Kopiere ich die Mail in einen anderen Ordner (reconstruct ..) ist wieder alles OK. Ich konnte dem USER zwar klar machen, dass das WEB-GUI mit "unbearbeiteten" Mails fehlerfrei funktioniert, aber "...das haben wir schon immer so gemacht ...." Auch habe ich darauf hingewiesen, das man die Clients auch nach eigen Wünschen konfigurieren kann (was und wieviel) heruntergeladen wird, oder das es keine gute Idee ist die Mails so zu verstümmeln, aber .... - ist ja auch ganz Interessant zu verstehen was da passiert ;) -- Danke und ciao, Peer ________________________________________________________ Max-Planck-Institut für Biogeochemie Dr. Peer-Joachim Koch Hans-Knöll Str.10 Telefon: ++49 3641 57-6705 D-07745 Jena Telefax: ++49 3641 57-7705 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 4661 bytes Beschreibung: S/MIME Cryptographic Signature URL : From max.grobecker at ml.grobecker.info Wed Apr 20 01:19:57 2016 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Wed, 20 Apr 2016 01:19:57 +0200 Subject: =?UTF-8?Q?Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_da_wa?= =?UTF-8?Q?s_Neues=3f?= Message-ID: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> Hallo zusammen, Bei mir prüft Postfix mittels reject_sender_login_mismatch ob Absender und Account zusammenpassen. Das funktioniert an sich ganz prima, kann aber relativ leicht ausgehebelt werden. Dazu muss nur ein gültiger Absender während der SMTP-Transaktion als MAIL FROM angegeben werden, was dann später im From-Header steht ist Postfix dann vollkommen egal. Das ist ja im weitesten Sinne ein dokumentiertes Verhalten, allerdings hilft das natürlich nur bedingt weiter.* Gibt es eine Möglichkeit - außer den From-Header zu verwerfen und von Postfix neu schreiben zu lassen - eben jenen Header zu prüfen und ggf. die Mail abzulehnen? In der aktuellen Postfix-Doku habe ich keine fortgeschrittenere Technologie gefunden, aber vielleicht suche ich auch falsch ;-) Viele Grüße aus dem Tal Max * Insbesondere, seitdem Thunderbird spätestens ab Version 45 mit dem Feature kommt, dass man vor dem Versenden der Mail mal eben die Absenderadresse vollkommen frei austauschen kann. -------------- 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 zahlenmaler at t-online.de Wed Apr 20 08:29:59 2016 From: zahlenmaler at t-online.de (robert) Date: Wed, 20 Apr 2016 08:29:59 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> Message-ID: <571721E7.40409@t-online.de> Hallo Max, ich habe mich eines Kunstgriffs bedient: smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch, check_sender_access mysql:/etc/postfix/sql/sender_access, reject wobei der select ein OK zurück geben muss wenn der Match erfolgt und wenn nicht dann halt der reject den Du wohl suchst. Da ich vor dem gleichem Problem stand, für mein Verständnis von Postfix war das die Lösung, ich bin allerdings kein virtuose, wie manch andere hier. also alle Angaben ohne "Gewä(e)hr". Gruß Robert Am 20.04.2016 um 01:19 schrieb Max Grobecker: > Hallo zusammen, > > Bei mir prüft Postfix mittels reject_sender_login_mismatch ob Absender und Account zusammenpassen. > Das funktioniert an sich ganz prima, kann aber relativ leicht ausgehebelt werden. > Dazu muss nur ein gültiger Absender während der SMTP-Transaktion als MAIL FROM angegeben werden, was dann später im > From-Header steht ist Postfix dann vollkommen egal. > > Das ist ja im weitesten Sinne ein dokumentiertes Verhalten, allerdings hilft das natürlich nur bedingt weiter.* > Gibt es eine Möglichkeit - außer den From-Header zu verwerfen und von Postfix neu schreiben zu lassen - eben jenen Header > zu prüfen und ggf. die Mail abzulehnen? > In der aktuellen Postfix-Doku habe ich keine fortgeschrittenere Technologie gefunden, aber vielleicht suche ich auch falsch ;-) > > > Viele Grüße aus dem Tal > Max > > > > * Insbesondere, seitdem Thunderbird spätestens ab Version 45 mit dem Feature kommt, dass man vor dem Versenden der Mail > mal eben die Absenderadresse vollkommen frei austauschen kann. > From news at amaltea.de Wed Apr 20 12:19:32 2016 From: news at amaltea.de (Paul) Date: Wed, 20 Apr 2016 12:19:32 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <571721E7.40409@t-online.de> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> Message-ID: <03199407-0c5d-6b22-4101-8c2847bc4ddb@amaltea.de> Hi Robert, Am 20.04.2016 um 08:29 schrieb robert: > Hallo Max, > > ich habe mich eines Kunstgriffs bedient: > > smtpd_sender_restrictions = > reject_authenticated_sender_login_mismatch, > check_sender_access mysql:/etc/postfix/sql/sender_access, > reject > > wobei der select ein OK zurück geben muss wenn der Match erfolgt und > wenn nicht dann halt der reject den Du wohl suchst. Kannst du bitte noch die SQL-Abfrage nachreichen? Gerade das bereitet mir Kopfzerbrechen. Danke! > > Da ich vor dem gleichem Problem stand, für mein Verständnis von Postfix > war das die Lösung, ich bin allerdings kein virtuose, wie manch andere > hier. also alle Angaben ohne "Gewä(e)hr". > > Gruß > Robert > Gruß, Paul > > Am 20.04.2016 um 01:19 schrieb Max Grobecker: >> Hallo zusammen, >> >> Bei mir prüft Postfix mittels reject_sender_login_mismatch ob Absender >> und Account zusammenpassen. >> Das funktioniert an sich ganz prima, kann aber relativ leicht >> ausgehebelt werden. >> Dazu muss nur ein gültiger Absender während der SMTP-Transaktion als >> MAIL FROM angegeben werden, was dann später im >> From-Header steht ist Postfix dann vollkommen egal. >> >> Das ist ja im weitesten Sinne ein dokumentiertes Verhalten, allerdings >> hilft das natürlich nur bedingt weiter.* >> Gibt es eine Möglichkeit - außer den From-Header zu verwerfen und von >> Postfix neu schreiben zu lassen - eben jenen Header >> zu prüfen und ggf. die Mail abzulehnen? >> In der aktuellen Postfix-Doku habe ich keine fortgeschrittenere >> Technologie gefunden, aber vielleicht suche ich auch falsch ;-) >> >> >> Viele Grüße aus dem Tal >> Max >> >> >> >> * Insbesondere, seitdem Thunderbird spätestens ab Version 45 mit dem >> Feature kommt, dass man vor dem Versenden der Mail >> mal eben die Absenderadresse vollkommen frei austauschen kann. >> > From zahlenmaler at t-online.de Wed Apr 20 13:08:28 2016 From: zahlenmaler at t-online.de (robert) Date: Wed, 20 Apr 2016 13:08:28 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <03199407-0c5d-6b22-4101-8c2847bc4ddb@amaltea.de> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <03199407-0c5d-6b22-4101-8c2847bc4ddb@amaltea.de> Message-ID: <5717632C.6040707@t-online.de> Hallo Paul, smtpd_sender_login_maps nocht vergessen. hier mein select query = select "OK" from Users where Address = '%s' ich möchte nochmal darauf hinweisen das es nicht zwingend richtig sein muss, evtl. gibt es leichtere bessere Lösungen. Am 20.04.2016 um 12:19 schrieb Paul: > Hi Robert, > > Am 20.04.2016 um 08:29 schrieb robert: >> Hallo Max, >> >> ich habe mich eines Kunstgriffs bedient: >> >> smtpd_sender_restrictions = >> reject_authenticated_sender_login_mismatch, >> check_sender_access mysql:/etc/postfix/sql/sender_access, >> reject >> >> wobei der select ein OK zurück geben muss wenn der Match erfolgt und >> wenn nicht dann halt der reject den Du wohl suchst. > > Kannst du bitte noch die SQL-Abfrage nachreichen? > Gerade das bereitet mir Kopfzerbrechen. > > Danke! > >> >> Da ich vor dem gleichem Problem stand, für mein Verständnis von Postfix >> war das die Lösung, ich bin allerdings kein virtuose, wie manch andere >> hier. also alle Angaben ohne "Gewä(e)hr". >> >> Gruß >> Robert >> > > Gruß, > Paul > >> >> Am 20.04.2016 um 01:19 schrieb Max Grobecker: >>> Hallo zusammen, >>> >>> Bei mir prüft Postfix mittels reject_sender_login_mismatch ob Absender >>> und Account zusammenpassen. >>> Das funktioniert an sich ganz prima, kann aber relativ leicht >>> ausgehebelt werden. >>> Dazu muss nur ein gültiger Absender während der SMTP-Transaktion als >>> MAIL FROM angegeben werden, was dann später im >>> From-Header steht ist Postfix dann vollkommen egal. >>> >>> Das ist ja im weitesten Sinne ein dokumentiertes Verhalten, allerdings >>> hilft das natürlich nur bedingt weiter.* >>> Gibt es eine Möglichkeit - außer den From-Header zu verwerfen und von >>> Postfix neu schreiben zu lassen - eben jenen Header >>> zu prüfen und ggf. die Mail abzulehnen? >>> In der aktuellen Postfix-Doku habe ich keine fortgeschrittenere >>> Technologie gefunden, aber vielleicht suche ich auch falsch ;-) >>> >>> >>> Viele Grüße aus dem Tal >>> Max >>> >>> >>> >>> * Insbesondere, seitdem Thunderbird spätestens ab Version 45 mit dem >>> Feature kommt, dass man vor dem Versenden der Mail >>> mal eben die Absenderadresse vollkommen frei austauschen kann. >>> >> > From max.grobecker at ml.grobecker.info Wed Apr 20 13:53:42 2016 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Wed, 20 Apr 2016 13:53:42 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <571721E7.40409@t-online.de> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> Message-ID: <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> Hallo Robert, Am 20.04.2016 um 08:29 schrieb robert: > smtpd_sender_restrictions = > reject_authenticated_sender_login_mismatch, > check_sender_access mysql:/etc/postfix/sql/sender_access, > reject > > wobei der select ein OK zurück geben muss wenn der Match erfolgt und wenn nicht dann halt der reject den Du wohl suchst. Noja, das hab ich ja bei mir schon - die Frage ist halt, wie ich damit eine Übereinstimmung aus der Kombination des Benutzernamens und des Absenders im From-Header prüfen oder erzwingen kann. All diese Mechanismen greifen nämlich nur auf die Adressen, die im MAIL FROM während der SMTP-Transaktion ausgetauscht werden, nicht jedoch auf das, was letztlich im Header steht und von den Mailclients beim Empfänger angezeigt werden. Viele Grüße aus dem Tal Max From zahlenmaler at t-online.de Wed Apr 20 16:36:00 2016 From: zahlenmaler at t-online.de (robert) Date: Wed, 20 Apr 2016 16:36:00 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> Message-ID: <571793D0.4080205@t-online.de> Hallo Max, Sender address rejected: not owned by user ; from= to=... Das ist was ich erhalte wenn ich in der Data From zeile nichts eingebe oder eben humbug also bei Data From: hansdampf oder dann erhalte ich kein OK der db abfrage und dann siehe Fehler oben. Aber wie gesagt ich bin kein virtuose und es muss nicht zwingend richtig sein. Aber ich habe bis jetzt nicht bemerken können das dies ausgehebelt wird und ich bekomme es per telnet ebenfalls nicht ausgehebelt. Ich würde gerne anders testen, sag mir wie und ich probiere es aus. Gruß Robert Am 20.04.2016 um 13:53 schrieb Max Grobecker: > Hallo Robert, > > > Am 20.04.2016 um 08:29 schrieb robert: > >> smtpd_sender_restrictions = >> reject_authenticated_sender_login_mismatch, >> check_sender_access mysql:/etc/postfix/sql/sender_access, >> reject >> >> wobei der select ein OK zurück geben muss wenn der Match erfolgt und wenn nicht dann halt der reject den Du wohl suchst. > > Noja, das hab ich ja bei mir schon - die Frage ist halt, wie ich damit eine Übereinstimmung aus der Kombination des Benutzernamens und des Absenders im From-Header prüfen oder erzwingen kann. > All diese Mechanismen greifen nämlich nur auf die Adressen, die im MAIL FROM während der SMTP-Transaktion ausgetauscht werden, nicht jedoch auf das, was letztlich im Header steht > und von den Mailclients beim Empfänger angezeigt werden. > > > > Viele Grüße aus dem Tal > Max > From max.grobecker at ml.grobecker.info Wed Apr 20 21:19:03 2016 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Wed, 20 Apr 2016 21:19:03 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <571793D0.4080205@t-online.de> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> Message-ID: <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> Hallo Robert, ich habe es gerade nochmal mit Debugging getestet - ich komme um die Verifikation einfach drumherum, solange ich im MAIL TO während der SMTP-Transaktion einen gültigen Absender wähle :-( Auszug aus dem Debug-Log: ----------------------------------------------------------------------------------------------------- --> 220 mx0.301-moved.de - Hello, I'm a little teapot! --> 250-mx0.301-moved.de <-- AUTH PLAIN ...... --> 235 2.7.0 Authentication successful <-- MAIL FROM: RET=FULL ENVID= BODY=8BITMIME SIZE=396 --> 250 2.1.0 Ok <-- RCPT TO: NOTIFY=SUCCESS,FAILURE,DELAY ORCPT=rfc822;empfaenger ** >>> START Sender address RESTRICTIONS <<< ** check_table_result: mysql:/etc/postfix/mysql_virtual_sender_login_mismatch_maps_advanced.cf OK max at grobecker.info ** match_list_match: OK: no match ** generic_checks: name=check_sender_access status=1 ** >>> END Sender address RESTRICTIONS <<< --> 250 2.1.5 Ok <-- DATA --> 354 End data with . -----------------------8<---------------------------------- Return-Path: To: From: info at paypal.com Subject: test Message-ID: Date: Wed, 20 Apr 2016 21:06:45 +0200 [...] ----------------------->8---------------------------------- --> 250 2.0.0 Ok: queued as 3qqrw12S4hzB0Vs ----------------------------------------------------------------------------------------------------- "max at grobecker.info" ist die Mailadresse, die zu dem SASL-Account gehört und demzufolge verwendet werden darf. Die ganzen Prüfungen geben auch grünes Licht, weil Postfix nur mit "max at grobecker.info" prüft - nicht jedoch (nach dem DATA) auf den übermittelten Header. Grundsätzlich funktioniert das aber - setze ich den falschen Absender tatsächlich so in den MAIL FROM ein wird die Mail erwartungsgemäß abgelehnt. Gibt es die Möglichkeit einen Header-Check durchführen zu lassen, welcher dynamisch aus einer SQL-Query zusammengeknuppert wird und optimalerweise auch den SASL-Benutzernamen als Parameter nehmen kann? Oder fahre ich dann besser, wenn ich mir da selbst ein Script baue, welches das prüft? Viele Grüße aus dem Tal Max From Zahlenmaler at t-online.de Wed Apr 20 22:20:00 2016 From: Zahlenmaler at t-online.de (Robert) Date: Wed, 20 Apr 2016 22:20:00 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> Message-ID: <5717E470.30006@t-online.de> Hallo Max, ja hast recht, geht bei mir auch. :-( alles was nach Data kommt wird nicht mehr geprüft. Mist. Jetzt bin ich angefixt und will wissen wie man das auch unterbinden kann das da humbug steht. Wenn Du eine Lösung hast, erleuchte mich. Am 20.04.2016 um 21:19 schrieb Max Grobecker: > Hallo Robert, > > ich habe es gerade nochmal mit Debugging getestet - ich komme um die Verifikation einfach drumherum, solange ich im MAIL TO während der SMTP-Transaktion einen > gültigen Absender wähle :-( > > > Auszug aus dem Debug-Log: > ----------------------------------------------------------------------------------------------------- > --> 220 mx0.301-moved.de - Hello, I'm a little teapot! > --> 250-mx0.301-moved.de > <-- AUTH PLAIN ...... > --> 235 2.7.0 Authentication successful > <-- MAIL FROM: RET=FULL ENVID= BODY=8BITMIME SIZE=396 > --> 250 2.1.0 Ok > <-- RCPT TO: NOTIFY=SUCCESS,FAILURE,DELAY ORCPT=rfc822;empfaenger > > > ** >>> START Sender address RESTRICTIONS <<< > ** check_table_result: mysql:/etc/postfix/mysql_virtual_sender_login_mismatch_maps_advanced.cf OK max at grobecker.info > ** match_list_match: OK: no match > ** generic_checks: name=check_sender_access status=1 > ** >>> END Sender address RESTRICTIONS <<< > > > --> 250 2.1.5 Ok > <-- DATA > --> 354 End data with . > > -----------------------8<---------------------------------- > Return-Path: > To: > From: info at paypal.com > Subject: test > Message-ID: > Date: Wed, 20 Apr 2016 21:06:45 +0200 > [...] > ----------------------->8---------------------------------- > --> 250 2.0.0 Ok: queued as 3qqrw12S4hzB0Vs > ----------------------------------------------------------------------------------------------------- > > "max at grobecker.info" ist die Mailadresse, die zu dem SASL-Account gehört und demzufolge verwendet werden darf. > Die ganzen Prüfungen geben auch grünes Licht, weil Postfix nur mit "max at grobecker.info" prüft - nicht jedoch (nach dem DATA) auf den übermittelten Header. > Grundsätzlich funktioniert das aber - setze ich den falschen Absender tatsächlich so in den MAIL FROM ein wird die Mail erwartungsgemäß abgelehnt. > > Gibt es die Möglichkeit einen Header-Check durchführen zu lassen, welcher dynamisch aus einer SQL-Query zusammengeknuppert wird und optimalerweise auch > den SASL-Benutzernamen als Parameter nehmen kann? Oder fahre ich dann besser, wenn ich mir da selbst ein Script baue, welches das prüft? > > > Viele Grüße aus dem Tal > Max > From kai_postfix at fuerstenberg.ws Thu Apr 21 09:40:03 2016 From: kai_postfix at fuerstenberg.ws (=?UTF-8?Q?Kai_F=c3=bcrstenberg?=) Date: Thu, 21 Apr 2016 09:40:03 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <5717E470.30006@t-online.de> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> <5717E470.30006@t-online.de> Message-ID: <571883D3.8020903@fuerstenberg.ws> Hallo Max, hallo Robert, kann es sein, dass ihr beiden im Moment SMTP-Dialog und E-Mail-Inhalt total verwechselt oder durcheinander wurschtelt? Von vorne: reject_authenticated_sender_login_mismatch prüft nur im SMTP-Dialog und funktioniert hervorragend. Kann man nicht aushebeln durch > Dazu muss nur ein gültiger Absender während der SMTP-Transaktion als > MAIL FROM angegeben werden Wenn AUTH und MAIL FROM nicht zusammen passen, wird die Mail geblockt, sonst geht sie durch. Punkt. Das gilt für authentifizierte und für nicht authentifizierte Mail. Davon ist aber der From-Header der E-Mail überhaupt nicht von berührt. "MAIL FROM" und "From:" können völlig unterschiedlich sein, ist auch OK so. Postfix kann Header überprüfen. Das sind dann aber header-checks und keine smtpd_recipient_restrictions. Am 20.04.2016 um 22:20 schrieb Robert: > Auszug aus dem Debug-Log: > ----------------------------------------------------------------------------------------------------- > --> 220 mx0.301-moved.de - Hello, I'm a little teapot! > --> 250-mx0.301-moved.de > <-- AUTH PLAIN ...... > --> 235 2.7.0 Authentication successful > <-- MAIL FROM: RET=FULL ENVID= BODY=8BITMIME SIZE=396 > --> 250 2.1.0 Ok > <-- RCPT TO: NOTIFY=SUCCESS,FAILURE,DELAY ORCPT=rfc822;empfaenger Bis hier hin haben wir nur SMTP-Dialog. Kein Mail-Inhalt. Der kommt erst nach DATA. smtpd_data_restrictions bringen hier aber auch nichts, es wird immer noch nur der SMTP-Dialog geprüft. Sonst nichts. Um die Header zu prüfen, gibt es von Postfix-Seite die header_checks. header_checks können aber nicht z.B. mit einer Datenbank verbunden werden und haben auch keinen Zugriff auf die Daten aus dem SMTP-Dialog. Zudem werden diese Checks auch bei authentifizierter Mail durchgeführt. Wenn du also im From-Header deine eigene E-Mail-Adresse über header_checks blockst, blockst du ALLE Mails mit deiner E-Mail-Adresse, auch die authentifizierten. -- Kai Fürstenberg PM an: kai at fuerstenberg punkt ws From kai_postfix at fuerstenberg.ws Thu Apr 21 10:13:58 2016 From: kai_postfix at fuerstenberg.ws (=?UTF-8?Q?Kai_F=c3=bcrstenberg?=) Date: Thu, 21 Apr 2016 10:13:58 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <571883D3.8020903@fuerstenberg.ws> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> <5717E470.30006@t-online.de> <571883D3.8020903@fuerstenberg.ws> Message-ID: <57188BC6.1060009@fuerstenberg.ws> Am 21.04.2016 um 09:40 schrieb Kai Fürstenberg: > Von vorne: > reject_authenticated_sender_login_mismatch prüft nur im SMTP-Dialog und > funktioniert hervorragend. Kann man nicht aushebeln durch >> > Dazu muss nur ein gültiger Absender während der SMTP-Transaktion als >> > MAIL FROM angegeben werden > Wenn AUTH und MAIL FROM nicht zusammen passen, wird die Mail geblockt, > sonst geht sie durch. Punkt. Das gilt für authentifizierte und für nicht > authentifizierte Mail. da muss ich mich ja selbst korrigieren: reject_authenticated_sender_login_mismatch betrifft natürlich nur authentifizierte Mail. Nicht authentifizierte Mail mit eigenen MAIL FROM wird nicht beachtet. Dafür gibt es reject_unauthenticated_sender_login_mismatch oder gleich reject_sender_login_mismatch -- Kai Fürstenberg PM an: kai at fuerstenberg punkt ws From zahlenmaler at t-online.de Thu Apr 21 11:00:43 2016 From: zahlenmaler at t-online.de (robert) Date: Thu, 21 Apr 2016 11:00:43 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <571883D3.8020903@fuerstenberg.ws> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> <5717E470.30006@t-online.de> <571883D3.8020903@fuerstenberg.ws> Message-ID: <571896BB.2020004@t-online.de> Hallo Kai, ja etwas, aber die Wortwahl ist hier doch eher der unser Fehler. Im Endefekt wollen wir erreichen das man in dem Email Inhalt in die From: Zeile nicht reinschreiben kann was man will. > Postfix kann Header überprüfen. Das sind dann aber Header-checks und > keine smtpd_recipient_restrictions. Diese header_checks, lassen sich aber nicht in smtpd_sender_restrictions integrieren, jedenfalls habe ich noch keine Möglichkeit dazu gefunden. Gruß Robert Am 21.04.2016 um 09:40 schrieb Kai Fürstenberg: > Hallo Max, hallo Robert, > > kann es sein, dass ihr beiden im Moment SMTP-Dialog und E-Mail-Inhalt > total verwechselt oder durcheinander wurschtelt? > > Von vorne: > reject_authenticated_sender_login_mismatch prüft nur im SMTP-Dialog und > funktioniert hervorragend. Kann man nicht aushebeln durch > >> Dazu muss nur ein gültiger Absender während der SMTP-Transaktion als >> MAIL FROM angegeben werden > > Wenn AUTH und MAIL FROM nicht zusammen passen, wird die Mail geblockt, > sonst geht sie durch. Punkt. Das gilt für authentifizierte und für nicht > authentifizierte Mail. > > Davon ist aber der From-Header der E-Mail überhaupt nicht von berührt. > "MAIL FROM" und "From:" können völlig unterschiedlich sein, ist auch OK so. > > Postfix kann Header überprüfen. Das sind dann aber Header-checks und > keine smtpd_recipient_restrictions. > > Am 20.04.2016 um 22:20 schrieb Robert: >> Auszug aus dem Debug-Log: >> ----------------------------------------------------------------------------------------------------- >> --> 220 mx0.301-moved.de - Hello, I'm a little teapot! >> --> 250-mx0.301-moved.de >> <-- AUTH PLAIN ...... >> --> 235 2.7.0 Authentication successful >> <-- MAIL FROM: RET=FULL ENVID= BODY=8BITMIME SIZE=396 >> --> 250 2.1.0 Ok >> <-- RCPT TO: NOTIFY=SUCCESS,FAILURE,DELAY ORCPT=rfc822;empfaenger > > Bis hier hin haben wir nur SMTP-Dialog. Kein Mail-Inhalt. Der kommt erst > nach DATA. smtpd_data_restrictions bringen hier aber auch nichts, es > wird immer noch nur der SMTP-Dialog geprüft. Sonst nichts. > > Um die Header zu prüfen, gibt es von Postfix-Seite die header_checks. > > header_checks können aber nicht z.B. mit einer Datenbank verbunden > werden und haben auch keinen Zugriff auf die Daten aus dem SMTP-Dialog. > Zudem werden diese Checks auch bei authentifizierter Mail durchgeführt. > Wenn du also im From-Header deine eigene E-Mail-Adresse über > header_checks blockst, blockst du ALLE Mails mit deiner E-Mail-Adresse, > auch die authentifizierten. > From wn at neessen.net Thu Apr 21 11:08:19 2016 From: wn at neessen.net (Winfried Neessen) Date: Thu, 21 Apr 2016 11:08:19 +0200 Subject: =?UTF-8?Q?Re=3A_Absenderverifikation_f=C3=BCr_From-Header_-_gibt?= =?UTF-8?Q?_es_da_was_Neues=3F?= In-Reply-To: <571896BB.2020004@t-online.de> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> <5717E470.30006@t-online.de> <571883D3.8020903@fuerstenberg.ws> <571896BB.2020004@t-online.de> Message-ID: Hi, Am 2016-04-21 11:00, schrieb robert: > Im Endefekt wollen wir erreichen das man in dem Email Inhalt in die > From: Zeile > nicht reinschreiben kann was man will. > Wozu? Solang das Envolpe-From nicht veraendert werden kann, ist das was im Mailheader steht voellig irrelevant. Nicht nur das, es ist teilweise sogar gewuenscht, dass dort nicht zwingend die Mail-From Adresse steht. Ich versteh den ganzen Aufwand den Du da versuchst nicht. Winni From tech at kdmails.de Thu Apr 21 11:13:28 2016 From: tech at kdmails.de (Daniel Gompf) Date: Thu, 21 Apr 2016 11:13:28 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <571896BB.2020004@t-online.de> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> <5717E470.30006@t-online.de> <571883D3.8020903@fuerstenberg.ws> <571896BB.2020004@t-online.de> Message-ID: <571899B8.5060104@kdmails.de> Hallo Robert, Am 21.04.2016 um 11:00 schrieb robert: > Hallo Kai, > > ja etwas, aber die Wortwahl ist hier doch eher der unser Fehler. > > Im Endefekt wollen wir erreichen das man in dem Email Inhalt in die > From: Zeile nicht reinschreiben kann was man will. > Das klingt jetzt zwar nach Briefkastenfirma, aber es gibt durchaus gute Gründe dort etwas anderes stehen zu haben als die Adresse, die für den Auth genutzt wird. From zahlenmaler at t-online.de Thu Apr 21 11:35:11 2016 From: zahlenmaler at t-online.de (robert) Date: Thu, 21 Apr 2016 11:35:11 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> <5717E470.30006@t-online.de> <571883D3.8020903@fuerstenberg.ws> <571896BB.2020004@t-online.de> Message-ID: <57189ECF.702@t-online.de> Hallo Winni, der kann doch verändert werden, ich schreibe da rein From: Paypal und ich bin sicher das ich keine Mails für Paypal verschicke und verschicken möchte. Sicher kann ich im header_check per regex die Domain unterbinden, einfach fände ich wenn ich alles was ich nicht Adresse aus einer Datenbank fische einfach nicht gestatte. Ich sehe keine Grund das meine Postfachbenutzer eine fremde Mail Adresse in die From zeile eintragen. Es Muss ja nicht der Account Name sein. Schauen wir mal zu 1&1 : (kopiert von zy0.de) Return-Path: X-Original-To: geza-hensel at SPAMTRAP.INVALID Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by spam.over.port25.me (Spamtrap) with ESMTP for ; Thu, 21 Apr 2016 11:29:41 +0200 (CEST) Received: from WIN-8GFQESRM0L5 ([5.196.148.69]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0Lj4n8-1bSHb52Wfm-00dBXH for ; Wed, 20 Apr 2016 02:02:10 +0200 From: "PayPal" Sowas würde es nicht geben, wenn man das unterbindet. Ja durch DKIM beist sowas sowieso auf Granit, dennoch muss es doch schon vorab eine Möglichkeit geben sowas generell zu unterbinden. Am 21.04.2016 um 11:08 schrieb Winfried Neessen: > Hi, > > Am 2016-04-21 11:00, schrieb robert: > >> Im Endefekt wollen wir erreichen das man in dem Email Inhalt in die >> From: Zeile >> nicht reinschreiben kann was man will. >> > Wozu? Solang das Envolpe-From nicht veraendert werden kann, ist das was > im Mailheader > steht voellig irrelevant. Nicht nur das, es ist teilweise sogar > gewuenscht, dass dort > nicht zwingend die Mail-From Adresse steht. Ich versteh den ganzen > Aufwand den Du da > versuchst nicht. > > > Winni From zahlenmaler at t-online.de Thu Apr 21 11:36:41 2016 From: zahlenmaler at t-online.de (robert) Date: Thu, 21 Apr 2016 11:36:41 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <571899B8.5060104@kdmails.de> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> <5717E470.30006@t-online.de> <571883D3.8020903@fuerstenberg.ws> <571896BB.2020004@t-online.de> <571899B8.5060104@kdmails.de> Message-ID: <57189F29.50202@t-online.de> Hallo Daniel, es muss nicht zwingend die Adresse des Auths sein, aber eine x-belibige, soll es auch nicht sein. Gruß Robert Am 21.04.2016 um 11:13 schrieb Daniel Gompf: > Hallo Robert, > > Am 21.04.2016 um 11:00 schrieb robert: >> Hallo Kai, >> >> ja etwas, aber die Wortwahl ist hier doch eher der unser Fehler. >> >> Im Endefekt wollen wir erreichen das man in dem Email Inhalt in die >> From: Zeile nicht reinschreiben kann was man will. >> > > Das klingt jetzt zwar nach Briefkastenfirma, aber es gibt durchaus gute > Gründe dort etwas anderes stehen zu haben als die Adresse, die für den > Auth genutzt wird. > From wn at neessen.net Thu Apr 21 11:44:18 2016 From: wn at neessen.net (Winfried Neessen) Date: Thu, 21 Apr 2016 11:44:18 +0200 Subject: =?UTF-8?Q?Re=3A_Absenderverifikation_f=C3=BCr_From-Header_-_gibt?= =?UTF-8?Q?_es_da_was_Neues=3F?= In-Reply-To: <57189ECF.702@t-online.de> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> <5717E470.30006@t-online.de> <571883D3.8020903@fuerstenberg.ws> <571896BB.2020004@t-online.de> <57189ECF.702@t-online.de> Message-ID: <9473ff709605acf233ede311fd481eff@neessen.net> Hi Robert, Am 2016-04-21 11:35, schrieb robert: > der kann doch verändert werden, ich schreibe da rein From: Paypal > und ich bin > sicher das ich keine Mails für Paypal verschicke und verschicken > möchte. > Das ist aber voellig unerheblich was im Mailheader steht. Wichtig ist, dass ein authentifizierter User keine anderes MAIL FROM setzen kann, als das unter dem er sich am Mailserver angemeldet hat. > Ich sehe keine Grund das meine Postfachbenutzer eine fremde Mail > Adresse in die From > zeile eintragen. > Dann sprich mal mit Kunden die Newsletter verschicken ;) > Es Muss ja nicht der Account Name sein. > Schauen wir mal zu 1&1 : > > (kopiert von zy0.de) > Return-Path: > X-Original-To: geza-hensel at SPAMTRAP.INVALID > Received: from mout.kundenserver.de (mout.kundenserver.de > [212.227.17.24]) > by spam.over.port25.me (Spamtrap) with ESMTP > for ; Thu, 21 Apr 2016 11:29:41 +0200 > (CEST) > Received: from WIN-8GFQESRM0L5 ([5.196.148.69]) by > mrelayeu.kundenserver.de > (mreue103) with ESMTPSA (Nemesis) id 0Lj4n8-1bSHb52Wfm-00dBXH for > ; Wed, 20 Apr 2016 02:02:10 +0200 > From: "PayPal" > Das einzige was hier relevant ist, ist der Return-Path (der aus dem MAIL FROM gewonnen wird). Der duerfte hier nicht @paypal sein, sondern muesste die Adresse des Absenders behinhalten. Das kannst Du via smtpd_sender_login_maps erreichen. Was im "From:"-Header steht ist irrelevant. Sich auf das "From:" aus dem Mailheader zu verlassen, waere als wenn Du bei einem HTTP Request irgendeinem (vom Client/Browser setzbaren) X-Header trauen wuerdest. Winni From zahlenmaler at t-online.de Thu Apr 21 12:41:02 2016 From: zahlenmaler at t-online.de (robert) Date: Thu, 21 Apr 2016 12:41:02 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <9473ff709605acf233ede311fd481eff@neessen.net> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> <5717E470.30006@t-online.de> <571883D3.8020903@fuerstenberg.ws> <571896BB.2020004@t-online.de> <57189ECF.702@t-online.de> <9473ff709605acf233ede311fd481eff@neessen.net> Message-ID: <5718AE3E.4070701@t-online.de> Hallo Winni, Am 21.04.2016 um 11:44 schrieb Winfried Neessen: > Hi Robert, > > Am 2016-04-21 11:35, schrieb robert: > >> der kann doch verändert werden, ich schreibe da rein From: Paypal >> und ich bin >> sicher das ich keine Mails für Paypal verschicke und verschicken möchte. >> > > Das ist aber voellig unerheblich was im Mailheader steht. Wichtig ist, > dass ein authentifizierter > User keine anderes MAIL FROM setzen kann, als das unter dem er sich am > Mailserver angemeldet hat. Dies habe ich bereits mit bekannten mitteln erreicht,auch mit maps das dies nicht der "Auth"name sein muss. > >> Ich sehe keine Grund das meine Postfachbenutzer eine fremde Mail >> Adresse in die From >> zeile eintragen. >> > Dann sprich mal mit Kunden die Newsletter verschicken ;) > >> Es Muss ja nicht der Account Name sein. >> Schauen wir mal zu 1&1 : >> >> (kopiert von zy0.de) >> Return-Path: >> X-Original-To: geza-hensel at SPAMTRAP.INVALID >> Received: from mout.kundenserver.de (mout.kundenserver.de >> [212.227.17.24]) >> by spam.over.port25.me (Spamtrap) with ESMTP >> for ; Thu, 21 Apr 2016 11:29:41 +0200 >> (CEST) >> Received: from WIN-8GFQESRM0L5 ([5.196.148.69]) by >> mrelayeu.kundenserver.de >> (mreue103) with ESMTPSA (Nemesis) id 0Lj4n8-1bSHb52Wfm-00dBXH for >> ; Wed, 20 Apr 2016 02:02:10 +0200 >> From: "PayPal" >> > > Das einzige was hier relevant ist, ist der Return-Path (der aus dem MAIL > FROM gewonnen wird). > Der duerfte hier nicht @paypal sein, sondern muesste die Adresse des > Absenders behinhalten. > Das kannst Du via smtpd_sender_login_maps erreichen. Was im > "From:"-Header steht ist > irrelevant. Sich auf das "From:" aus dem Mailheader zu verlassen, waere > als wenn Du bei einem > HTTP Request irgendeinem (vom Client/Browser setzbaren) X-Header trauen > wuerdest. > > > Winni Es geht mir ja nicht darum sich auf das "From" nicht zu verlassen, (wie geschrieben, ich habe bereits Sender_login_maps, nicht wie die "profis von 1&1") Ich möchte einfach nicht das, falls das Postfach von "kleinfritzchen" auch wenn es mal gekapert wurde, eben nicht in der Fromzeile irgendwas stehen kann.(Schnell noch 10000 Mails an alle möglichen Blacklistenspamtraps schicken ..upps) Das doofe ist ja auch noch das dies im Klienten angezeigt wird, also die interessiert es nicht was im Return steht sondern das was im From steht. Da wird jeder normale Benutzer behaupten, wieso das kommt doch von paypal. Das steht doch sogar da. Was passiert wir pflegen eine header_checks in die wir dann per regex reinschreiben: /^From:.* <.*@paypal.de>/ REJECT /^From:.* <.*@paypal.at>/ REJECT /^From:.* <.*@paypal.com>/ REJECT /^From:.* <.*@dhl.de>/ REJECT usw. Das muss doch anders gehen, eigentlich, aber gibt wohl keine Möglichkeit dies zu kontrollieren. Dies war auch Max Hintergrund, an seiner Ursprünglichen Frage, denke ich zumindest. Gruß Robert From kai_postfix at fuerstenberg.ws Thu Apr 21 13:12:16 2016 From: kai_postfix at fuerstenberg.ws (=?UTF-8?Q?Kai_F=c3=bcrstenberg?=) Date: Thu, 21 Apr 2016 13:12:16 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> Message-ID: <5718B590.9050601@fuerstenberg.ws> Hi Max, Am 20.04.2016 um 01:19 schrieb Max Grobecker: > Bei mir prüft Postfix mittels reject_sender_login_mismatch ob > Absender und Account zusammenpassen. Das funktioniert an sich ganz > prima, kann aber relativ leicht ausgehebelt werden. Dazu muss nur ein > gültiger Absender während der SMTP-Transaktion als MAIL FROM > angegeben werden, was dann später im From-Header steht ist Postfix > dann vollkommen egal. > > Das ist ja im weitesten Sinne ein dokumentiertes Verhalten, > allerdings hilft das natürlich nur bedingt weiter.* Gibt es eine > Möglichkeit - außer den From-Header zu verwerfen und von Postfix neu > schreiben zu lassen - eben jenen Header zu prüfen und ggf. die Mail > abzulehnen? In der aktuellen Postfix-Doku habe ich keine > fortgeschrittenere Technologie gefunden, aber vielleicht suche ich > auch falsch ;-) ich komme nochmal auf die ganz ursprüngliche Mail zurück. Das, was du vor hast ist, mit Postfix-Bordmitteln nicht zu erreichen. Abgesehen von Header- und Body-Checks interessiert sich Postfix nicht für den Inhalt und damit auch nicht für die Header einer E-Mail. Da die Peer'sche Standardkonfiguration aber auch Amavis und Spamassassin beinhaltet, könntest du einfach diese beiden für deine Zwecke in Anspruch nehmen. Der Verwaltungsaufwand lohnt sich aber nur, wenn du nur ne Handvoll Domänen verwaltest, bzw. die Domain-Fluktuation sich in Grenzen hält. Du prüfst über den Spamassassin, ob der From:-Header eine eigene Domain aufweist und verpasst dieser Regel ein entsprechend hohes Scoring. Die Mails, die über AUTH hereinkommen, nimmst du von der Prüfung über eine Policy-Bank aus. Hab ich nicht geprüft, erscheint mir aber logisch. Du müsstest nur prüfen, ob das mit deinem Setup realisierbar ist. -- Kai Fürstenberg PM an: kai at fuerstenberg punkt ws From Rainer_Wiesenfarth at Trimble.com Thu Apr 21 13:21:09 2016 From: Rainer_Wiesenfarth at Trimble.com (Rainer Wiesenfarth) Date: Thu, 21 Apr 2016 11:21:09 +0000 Subject: =?iso-8859-1?Q?Re:_Absenderverifikation_f=FCr_From-Header_-_gibt_es_da_wa?= =?iso-8859-1?Q?s_Neues=3F?= In-Reply-To: <571896BB.2020004@t-online.de> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <571721E7.40409@t-online.de> <803d44e3-003c-e59e-2afb-9b01ff890d58@grobecker.info> <571793D0.4080205@t-online.de> <016e3461-d417-4828-ac5f-4a2ba1e97081@grobecker.info> <5717E470.30006@t-online.de> <571883D3.8020903@fuerstenberg.ws> <571896BB.2020004@t-online.de> Message-ID: <4AE00D781A09064297022337CA5D27F9E4B39ACC@sed-mbx-03.trimblecorp.net> From: robert > [...] > Diese header_checks, lassen sich aber nicht in smtpd_sender_restrictions > integrieren, jedenfalls habe ich noch keine Möglichkeit dazu gefunden. Das kann auch nicht funktionieren. smtpd_sender_restrictions werden bereits im Kontext des "MAIL From:" Kommandos abgearbeitet, die Header-Zeilen kommen aber erst im "DATA" Block. Best Regards / Mit freundlichen Grüßen Rainer Wiesenfarth -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Hans-Jürgen Gebauer From mailinglisten at wbock.de Thu Apr 21 23:34:14 2016 From: mailinglisten at wbock.de (mailinglisten) Date: Thu, 21 Apr 2016 23:34:14 +0200 Subject: Relay access denied - reject code Message-ID: <007901d19c15$8d9bf6b0$a8d3e410$@wbock.de> Hallo, ich habe ein Problem: Im postfix-log findet sich folgender Eintrag (gekürzt) Apr 21 23:19:07 xx postfix/smtpd[2990]: NOQUEUE: reject: RCPT from .... : 454 4.7.1 ... : Relay access denied; Die Mail geht an eine Mail-Adresse, die nicht mehr vorhanden ist. Die Domäne ist aber vorhanden und wird von meinem Server verwaltet. Ständig wird nun versucht, diese Mail wieder anzuliefern. Das ist vermutlich darauf zurückzuführen das der reject-code 454 und nicht 550 ist. An welcher Stelle muss ich Veränderungen vornehmen, um die Mail auf Dauer abzulehnen und nicht nur temporär. Für Hinweise bin ich sehr dankbar! Gruss Wolfgang **************************************** > wolfgang bock > wolfgang.bock at wbock.de *************************** ;-) ******** From daniel at ist-immer-online.de Fri Apr 22 01:16:07 2016 From: daniel at ist-immer-online.de (Daniel) Date: Fri, 22 Apr 2016 01:16:07 +0200 Subject: AW: Relay access denied - reject code In-Reply-To: <007901d19c15$8d9bf6b0$a8d3e410$@wbock.de> References: <007901d19c15$8d9bf6b0$a8d3e410$@wbock.de> Message-ID: <000001d19c23$c8ec68e0$5ac53aa0$@ist-immer-online.de> Hi Wolfgang, ich seh im Log öfters eher Abweisung wegen "Host not found" oder " Client host rejected: cannot find your hostname" oder Blockierung durch DNSBL bevor überhaupt die Prüfung des Nutzers kommt. Sollte alles ok sein, sollte sowas kommen postfix/smtpd[4814]: NOQUEUE: reject: RCPT from ns1.winserver2.net[174.123.108.227]: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table; from= to= proto=ESMTP helo= Wenn Server nicht zuständig ist dann postfix/smtpd[19322]: NOQUEUE: reject: RCPT from unknown[157.122.148.241]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= Bei mir steht in der main.cf # The unknown_local_recipient_reject_code specifies the SMTP server # response code when a recipient domain matches $mydestination or # ${proxy,inet}_interfaces, while $local_recipient_maps is non-empty # and the recipient address or address local-part is not found. # # The default setting is 550 (reject mail) but it is safer to start # with 450 (try again later) until you are certain that your # local_recipient_maps settings are OK. # unknown_local_recipient_reject_code = 550 Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von mailinglisten Gesendet: Donnerstag, 21. April 2016 23:34 An: 'Diskussionen und Support rund um Postfix' Betreff: Relay access denied - reject code Hallo, ich habe ein Problem: Im postfix-log findet sich folgender Eintrag (gekürzt) Apr 21 23:19:07 xx postfix/smtpd[2990]: NOQUEUE: reject: RCPT from .... : 454 4.7.1 ... : Relay access denied; Die Mail geht an eine Mail-Adresse, die nicht mehr vorhanden ist. Die Domäne ist aber vorhanden und wird von meinem Server verwaltet. Ständig wird nun versucht, diese Mail wieder anzuliefern. Das ist vermutlich darauf zurückzuführen das der reject-code 454 und nicht 550 ist. An welcher Stelle muss ich Veränderungen vornehmen, um die Mail auf Dauer abzulehnen und nicht nur temporär. Für Hinweise bin ich sehr dankbar! Gruss Wolfgang **************************************** > wolfgang bock > wolfgang.bock at wbock.de *************************** ;-) ******** From Ralf.Hildebrandt at charite.de Fri Apr 22 10:26:50 2016 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Fri, 22 Apr 2016 10:26:50 +0200 Subject: Relay access denied - reject code In-Reply-To: <007901d19c15$8d9bf6b0$a8d3e410$@wbock.de> References: <007901d19c15$8d9bf6b0$a8d3e410$@wbock.de> Message-ID: <20160422082650.GC30696@charite.de> * mailinglisten : > > > Hallo, > > ich habe ein Problem: > > Im postfix-log findet sich folgender Eintrag (gekürzt) > > Apr 21 23:19:07 xx postfix/smtpd[2990]: NOQUEUE: reject: RCPT from .... : 454 4.7.1 ... : Relay access denied; > > Die Mail geht an eine Mail-Adresse, die nicht mehr vorhanden ist. Die Domäne ist aber vorhanden und wird von meinem Server verwaltet. Dann sollte da aber nicht "Relay access denied" stehen! Zeig mal postconf -n -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt at charite.de | http://www.charite.de From max.grobecker at ml.grobecker.info Fri Apr 22 12:08:29 2016 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Fri, 22 Apr 2016 12:08:29 +0200 Subject: =?UTF-8?Q?Re:_Absenderverifikation_f=c3=bcr_From-Header_-_gibt_es_d?= =?UTF-8?Q?a_was_Neues=3f?= In-Reply-To: <5718B590.9050601@fuerstenberg.ws> References: <3e67172a-d42e-016f-daa1-17fd2a92537f@ml.grobecker.info> <5718B590.9050601@fuerstenberg.ws> Message-ID: <1ba77ba7-4bd5-c4d7-b6ce-474b2907dda6@grobecker.info> Hallo Kai, ich glaube, dann muss ich mir doch mal ansehen wie man Milter für Postfix baut ;-) Der könnte das ja dann theoretisch gegen die Datenbanken (SQL) prüfen und den Absender wegschicken. Oder ich muss die Holzhammermethode nehmen, auf den Submission-Ports den "From"-Header wegschmeißen und durch Postfix danach neu basierend auf dem MAIL FROM schreiben lassen... Lieber wäre es mir aber, die E-Mail in dem Fall abzulehnen bevor sie mit einem unerwarteten Absender zugestellt wird. Am 21.04.2016 um 13:12 schrieb Kai Fürstenberg: > Der Verwaltungsaufwand lohnt sich aber nur, wenn du nur ne Handvoll > Domänen verwaltest, bzw. die Domain-Fluktuation sich in Grenzen hält. > > Du prüfst über den Spamassassin, ob der From:-Header eine eigene Domain > aufweist und verpasst dieser Regel ein entsprechend hohes Scoring. Die > Mails, die über AUTH hereinkommen, nimmst du von der Prüfung über eine > Policy-Bank aus. Da habe ich sowieso schon Aufwand, weil ich über Amavis die DKIM-Signierung vornehme. Entsprechend gibt es dort Scripte, welche die Domainliste aus der Datenbank holen und DKIM-Configs erzeugen und in Amavis zu includen. Ich schaue mal was mir besser gefällt. Damit hätte ich zumindest mal einen Grund, mich näher mit Milter zu beschäftigen ;-) Viele Grüße aus dem Tal Max From mailinglisten at wbock.de Fri Apr 22 17:41:31 2016 From: mailinglisten at wbock.de (Wolfgang Bock) Date: Fri, 22 Apr 2016 17:41:31 +0200 Subject: AW: Relay access denied - reject code In-Reply-To: <20160422082650.GC30696@charite.de> References: <007901d19c15$8d9bf6b0$a8d3e410$@wbock.de> <20160422082650.GC30696@charite.de> Message-ID: <003301d19cad$71bcd110$55367330$@wbock.de> Hallo, vielen Dank für die Info! Das stimmt! Ich habe nach meiner Mail nochmal recherchiert und bin auf die mögliche Fehlerursache gestossen: die betreffende Domain gar nicht aktiviert, damit war sie für postfix nicht existet. Folge davon ist die 454 Meldung. Danach habe ich domain aktiviert und siehe da, es gab die erwartetet 550 Meldung und die Mail verschwand aus dem log. Gruss Wolfgang **************************************** > wolfgang bock > wolfgang.bock at wbock.de *************************** ;-) ******** -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Ralf Hildebrandt Gesendet: Freitag, 22. April 2016 10:27 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: Relay access denied - reject code * mailinglisten : > > > Hallo, > > ich habe ein Problem: > > Im postfix-log findet sich folgender Eintrag (gekürzt) > > Apr 21 23:19:07 xx postfix/smtpd[2990]: NOQUEUE: reject: RCPT from .... : 454 4.7.1 ... : Relay access denied; > > Die Mail geht an eine Mail-Adresse, die nicht mehr vorhanden ist. Die Domäne ist aber vorhanden und wird von meinem Server verwaltet. Dann sollte da aber nicht "Relay access denied" stehen! Zeig mal postconf -n -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt at charite.de | http://www.charite.de From stickybit at myhm.de Wed Apr 27 10:54:24 2016 From: stickybit at myhm.de (Andre) Date: Wed, 27 Apr 2016 10:54:24 +0200 Subject: =?UTF-8?Q?TLS_1.2_f=c3=bcr_Postfix_und_Dovecot?= Message-ID: <57207E40.9050306@myhm.de> Servus, wie bringe ich Postfix und Dovecot die TLS Version 1.2 bei? LG Andre From wn at neessen.net Wed Apr 27 11:51:45 2016 From: wn at neessen.net (Winfried Neessen) Date: Wed, 27 Apr 2016 11:51:45 +0200 Subject: =?UTF-8?Q?Re=3A_TLS_1=2E2_f=C3=BCr_Postfix_und_Dovecot?= In-Reply-To: <57207E40.9050306@myhm.de> References: <57207E40.9050306@myhm.de> Message-ID: Hi Andre, Am 2016-04-27 10:54, schrieb Andre: > wie bringe ich Postfix und Dovecot die TLS Version 1.2 bei? Du musst lediglich min. OpenSSL 1.0.1 auf dem System installiert haben und sowohl Postfix als auch Dovecot dagegen kompiliert/gelinkt haben. Winni -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: