From risse at citkomm.de  Mon Jul 10 13:04:02 2017
From: risse at citkomm.de (Marc Risse)
Date: Mon, 10 Jul 2017 13:04:02 +0200
Subject: SPF - "It is impossible for us to say why it was rejected."
Message-ID: <b9eba530-93fa-d7d4-4691-458ec6f6735e@citkomm.de>

Hallo zusammen,

ich habe ein Phänomen:
Mein Server akzeptiert die Mails der Ruhr-Uni Bochum nicht und gibt mir 
auch keinerlei Infos warum der SPF-Check negativ ausfällt.

Der Link zu openspf sagt folgendes:

mail at empfänger rejected a message that claimed an envelope sender 
address of sender at ruhr-uni-bochum.de.
mail at empfänger received a message from out1.mail.ruhr-uni-bochum.de 
(2a05:3e00:8:1001::8693:3595) that claimed an envelope sender address of 
sender at ruhr-uni-bochum.de.
The domain ruhr-uni-bochum.de has authorized 
out1.mail.ruhr-uni-bochum.de (2a05:3e00:8:1001::8693:3595) to send mail 
on its behalf, so the message should have been accepted. It is 
impossible for us to say why it was rejected.
What should I do?
If the problem persists, contact the ruhr-uni-bochum.de postmaster.


Log:
Jul  9 23:33:49 relay postfix/smtpd[4750]: Anonymous TLS connection 
established from 
out1.mail.ruhr-uni-bochum.de[2a05:3e00:8:1001::8693:3595]: TLSv1.2 with 
cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jul  9 23:33:52 relay postgrey[721]: action=pass, reason=triplet found, 
client_name=out1.mail.ruhr-uni-bochum.de, 
client_address=2a05:3e00:8:1001::8693:3595, 
sender=sender at ruhr-uni-bochum.de, recipient=mail at empfänger
Jul  9 23:33:52 relay postfix/smtpd[4750]: NOQUEUE: reject: RCPT from 
out1.mail.ruhr-uni-bochum.de[2a05:3e00:8:1001::8693:3595]: 550 5.7.1 
<mail at empfänger>: Recipient address rejected: Message rejected due to: 
SPF fail - not authorized. Please see 
http://www.openspf.net/Why?s=mfromblabla; 
from=<sender at ruhr-uni-bochum.de> to=<mail at empfänger> proto=ESMTP 
helo=<out1.mail.ruhr-uni-bochum.de>
Jul  9 23:33:52 relay postfix/smtpd[4750]: disconnect from 
out1.mail.ruhr-uni-bochum.de[2a05:3e00:8:1001::8693:3595] ehlo=2 
starttls=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8


Hattet Ihr so etwas schon mal? Was kann ich tun? Der Postmaster der 
Ruhr-Uni reagiert nicht auf meine Anfrage.
Hier der SPF-Record:
ruhr-uni-bochum.de.    74421    IN    TXT    "v=spf1 
exists:%{ir}.%{v}._spfx.ruhr-uni-bochum.de 
exists:%{ir}._ip.%{l}._spfx.ruhr-uni-bochum.de -all"

DNS, SPF und IPv6 funktionieren problemlos, habe echt keine Idee... :(




-- 

Mit freundlichen Grüßen

Marc Risse
RZ-Projekte



Telefon: +49 2372 5520-385
Fax: +49 2372 5520-61-385
E-Mail: risse at citkomm.de
Internet: http://www.citkomm.de

=====================================
KDVZ Citkomm (Kommunaler Zweckverband)
Citkomm services GmbH*
Sonnenblumenallee 3, 58675 Hemer
Telefon: +49 2372 5520-0
Fax: +49 2372 5520-279
E-Mail: post at citkomm.de


*Tochtergesellschaft:
Citkomm services GmbH
Sitz der Gesellschaft: Hemer
Handelsregister: AG Iserlohn, HRB 26 86
Geschäftsführer: Dr. Michael Neubauer, Kerstin Pliquett


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 3429 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20170710/e3feab62/attachment.p7s>

From news at amaltea.de  Mon Jul 10 17:49:25 2017
From: news at amaltea.de (Paul)
Date: Mon, 10 Jul 2017 17:49:25 +0200
Subject: SPF - "It is impossible for us to say why it was rejected."
In-Reply-To: <b9eba530-93fa-d7d4-4691-458ec6f6735e@citkomm.de>
References: <b9eba530-93fa-d7d4-4691-458ec6f6735e@citkomm.de>
Message-ID: <fc26fa1c-6d7b-4c8a-55fb-a3f92ad0e555@amaltea.de>

Am 10.07.2017 um 13:04 schrieb Marc Risse:
> Hallo zusammen,
> 
> ich habe ein Phänomen:
> Mein Server akzeptiert die Mails der Ruhr-Uni Bochum nicht und gibt mir
> auch keinerlei Infos warum der SPF-Check negativ ausfällt.
[...]
> Log:
[...]
> Jul  9 23:33:52 relay postfix/smtpd[4750]: NOQUEUE: reject: RCPT from
> out1.mail.ruhr-uni-bochum.de[2a05:3e00:8:1001::8693:3595]: 550 5.7.1
> <mail at empfänger>: Recipient address rejected: Message rejected due to:
> SPF fail - not authorized. Please see
> http://www.openspf.net/Why?s=mfromblabla;
> from=<sender at ruhr-uni-bochum.de> to=<mail at empfänger> proto=ESMTP
> helo=<out1.mail.ruhr-uni-bochum.de>
[...]
> Hattet Ihr so etwas schon mal? Was kann ich tun? Der Postmaster der
> Ruhr-Uni reagiert nicht auf meine Anfrage.

Nein, noch nie ein deartiges Problem gesehen.
Ich gehe mal davon aus, dass du deinen SPF-Prüfer nicht verbogen hast, oder?

Damit die Mail angenomme wird, kannst du komplett oder selektiv auf
SPF-Prüfung verzichten.
Also bspw mit restriction classes, wenn Mail von
out1.mail.ruhr-uni-bochum.de, dann keine SPF Prüfung.

> Hier der SPF-Record:
> ruhr-uni-bochum.de.    74421    IN    TXT    "v=spf1
> exists:%{ir}.%{v}._spfx.ruhr-uni-bochum.de
> exists:%{ir}._ip.%{l}._spfx.ruhr-uni-bochum.de -all"

So einen SPF Record seh ich auch nicht alle Tage.
Würde mich freuen, wenn mir hier jemand diesen Record bzw den Sinn und
Zweck dieses Records erklären kann.
Ich versuche mich in der Zwischenzeit hier einzulesen...
http://www.openspf.org/RFC_4408#macros

Gruß,
Paul


From gnitzsche at netcologne.de  Mon Jul 10 18:01:40 2017
From: gnitzsche at netcologne.de (Gunther Nitzsche)
Date: Mon, 10 Jul 2017 18:01:40 +0200
Subject: SPF - "It is impossible for us to say why it was rejected."
In-Reply-To: <b9eba530-93fa-d7d4-4691-458ec6f6735e@citkomm.de>
References: <b9eba530-93fa-d7d4-4691-458ec6f6735e@citkomm.de>
Message-ID: <8433cbb4-1ed7-e6aa-95ef-cf0b510c4aaa@netcologne.de>

On 10.07.2017 13:04, Marc Risse wrote:
> Hallo zusammen,
>
> ich habe ein Phänomen:
> Mein Server akzeptiert die Mails der Ruhr-Uni Bochum nicht und gibt
> mir auch keinerlei Infos warum der SPF-Check negativ ausfällt.
>
> Der Link zu openspf sagt folgendes:
>
> mail at empfänger rejected a message that claimed an envelope sender
> address of sender at ruhr-uni-bochum.de.
> mail at empfänger received a message from out1.mail.ruhr-uni-bochum.de
> (2a05:3e00:8:1001::8693:3595) that claimed an envelope sender address
> of sender at ruhr-uni-bochum.de.
> The domain ruhr-uni-bochum.de has authorized
> out1.mail.ruhr-uni-bochum.de (2a05:3e00:8:1001::8693:3595) to send
> mail on its behalf, so the message should have been accepted. It is
> impossible for us to say why it was rejected.
> What should I do?
> If the problem persists, contact the ruhr-uni-bochum.de postmaster.
>
>
> Log:
> Jul  9 23:33:49 relay postfix/smtpd[4750]: Anonymous TLS connection
> established from
> out1.mail.ruhr-uni-bochum.de[2a05:3e00:8:1001::8693:3595]: TLSv1.2
> with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Jul  9 23:33:52 relay postgrey[721]: action=pass, reason=triplet
> found, client_name=out1.mail.ruhr-uni-bochum.de,
> client_address=2a05:3e00:8:1001::8693:3595,
> sender=sender at ruhr-uni-bochum.de, recipient=mail at empfänger
> Jul  9 23:33:52 relay postfix/smtpd[4750]: NOQUEUE: reject: RCPT from
> out1.mail.ruhr-uni-bochum.de[2a05:3e00:8:1001::8693:3595]: 550 5.7.1
> <mail at empfänger>: Recipient address rejected: Message rejected due to:
> SPF fail - not authorized. Please see
> http://www.openspf.net/Why?s=mfromblabla;
> from=<sender at ruhr-uni-bochum.de> to=<mail at empfänger> proto=ESMTP
> helo=<out1.mail.ruhr-uni-bochum.de>
> Jul  9 23:33:52 relay postfix/smtpd[4750]: disconnect from
> out1.mail.ruhr-uni-bochum.de[2a05:3e00:8:1001::8693:3595] ehlo=2
> starttls=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8
>
>
> Hattet Ihr so etwas schon mal? Was kann ich tun? Der Postmaster der
> Ruhr-Uni reagiert nicht auf meine Anfrage.
> Hier der SPF-Record:
> ruhr-uni-bochum.de.    74421    IN    TXT    "v=spf1
> exists:%{ir}.%{v}._spfx.ruhr-uni-bochum.de
> exists:%{ir}._ip.%{l}._spfx.ruhr-uni-bochum.de -all"
>
> DNS, SPF und IPv6 funktionieren problemlos, habe echt keine Idee... :(
>
>
>

python3 -m spf   2a05:3e00:8:1001::8693:3595
oejhvmezerpqnf at ruhr-uni-bochum.de "
('pass', 250, 'sender SPF authorized')
exists:%{ir}.%{v}._spfx.ruhr-uni-bochum.de


http://www.openspf.org/RFC_4408#mech-exists

sagt dazu:

i: IP
r: domain name of host performing the check (also meine domain..??)

v: der String ""in-addr" bzw. "ip6"

Wenn ich das "r" mal ignoriere (was hat meine Domain damit zu tun?),
sagt der String: der "a" record zu
5.9.5.3.3.9.6.8.0.0.0.0.0.0.0.0.1.0.0.1.8.0.0.0.0.0.e.3.5.0.a.2.ip6._spfx.ruhr-uni-bochum.de

muss existieren. (a, nicht aaaa)

Tut er auch - daher pass.

Non-authoritative answer:
Name:   
5.9.5.3.3.9.6.8.0.0.0.0.0.0.0.0.1.0.0.1.8.0.0.0.0.0.e.3.5.0.a.2.ip6._spfx.ruhr-uni-bochum.de
Address: 127.0.0.2

Warum da bei Dir ein Fail kommt, versteh' ich dann auch nicht.

Gruß
Gunther







NetCologne Systemadministration
-- 
NetCologne Gesellschaft für Telekommunikation mbH
Am Coloneum 9 ; 50829 Köln
Geschäftsführer:   
  Timo von Lepel,
  Mario Wilhelm  
Vorsitzender des Aufsichtsrates:
  Dr. Andreas Cerbe
  HRB 25580, AG Köln




From rainer_wiesenfarth at trimble.com  Mon Jul 10 18:45:01 2017
From: rainer_wiesenfarth at trimble.com (Rainer Wiesenfarth)
Date: Mon, 10 Jul 2017 18:45:01 +0200
Subject: SPF - "It is impossible for us to say why it was rejected."
In-Reply-To: <8433cbb4-1ed7-e6aa-95ef-cf0b510c4aaa@netcologne.de>
References: <b9eba530-93fa-d7d4-4691-458ec6f6735e@citkomm.de>
 <8433cbb4-1ed7-e6aa-95ef-cf0b510c4aaa@netcologne.de>
Message-ID: <CAOsVh2UOcvW=3yLQy7iumyzEjeqh44WYRj0uqw0ZUYMhfoXJTw@mail.gmail.com>

Am 10. Juli 2017 um 18:01 schrieb Gunther Nitzsche <gnitzsche at netcologne.de>
:

> ?[...]
>
> http://www.openspf.org/RFC_4408#mech-exists
>
> sagt dazu:
>
> i: IP
> r: domain name of host performing the check (also meine domain..??)
>

?Das 'r' ist ein "transformer", der die IP "umdreht" - sonst passt die
DNS-Abfrage ja nicht... ;-)
?
(weil ich mich auch gewundert habe, was die Empfänger-Domain an der Stelle
soll).

Grüße Rainer

-- 
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, Jürgen Kesper
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20170710/f0ee8f0d/attachment.htm>

From jbehrend at mpifr-bonn.mpg.de  Fri Jul 14 09:08:42 2017
From: jbehrend at mpifr-bonn.mpg.de (Jan Behrend)
Date: Fri, 14 Jul 2017 09:08:42 +0200
Subject: OT: Amavis Notification-Messages mit S/MIME signieren
Message-ID: <1500016122.18737.6.camel@mpifr-bonn.mpg.de>

Hallo Liste,

wir haben eine Reihe automatischer Nachrichten, die wir an unsere
Benutzer verschicken und haben ihnen eingebläut, dass _alle_
Nachrichten, die aus dem Rechnenzentrum verschickt werden, mit S/MIME
signiert sind.  So sind sie leicht von SPAM- Phishing- etc. Emails zu
unterscheiden.

Unrühmliche Ausnahme sind die Notification-Nachrichten von Amavis, die
erwünscht sind, wenn "BANNED-Nachrichten" abgewiesen werden, wie z.B.
Anhänge mit ms-exe, o.Ä.

Meine Frage ist:  Kann man Amavis beibringen, diese Notification-
Nachrichten zu signieren?

Vielen Dank schon im Voraus und Gruß aus Bonn
von Jan Behrend

-- 
MAX-PLANCK-INSTITUT fuer Radioastronomie
Jan Behrend - Rechenzentrum
----------------------------------------
Auf dem Huegel 69, D-53121 Bonn                                  
Tel: +49 (228) 525 359
http://www.mpifr-bonn.mpg.de

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/x-pkcs7-signature
Dateigröße  : 6273 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20170714/0add5b45/attachment.bin>

From p at sys4.de  Fri Jul 14 09:41:55 2017
From: p at sys4.de (Patrick Ben Koetter)
Date: Fri, 14 Jul 2017 09:41:55 +0200
Subject: OT: Amavis Notification-Messages mit S/MIME signieren
In-Reply-To: <1500016122.18737.6.camel@mpifr-bonn.mpg.de>
References: <1500016122.18737.6.camel@mpifr-bonn.mpg.de>
Message-ID: <d571b6d7-5275-8e83-154b-da07042bcde7@sys4.de>

Hallo Jan,

Du kannst mit notification_method in amavis eine Route festlegen, über
die es die Nachricht z.B. an einen dedizierten smtp-Listener sendet.
Dort kann Christians sigh-Milter die Nachricht S/MIME-signieren.

p at rick


Am 14.07.2017 um 09:08 schrieb Jan Behrend:
> Hallo Liste,
>
> wir haben eine Reihe automatischer Nachrichten, die wir an unsere
> Benutzer verschicken und haben ihnen eingebläut, dass _alle_
> Nachrichten, die aus dem Rechnenzentrum verschickt werden, mit S/MIME
> signiert sind.  So sind sie leicht von SPAM- Phishing- etc. Emails zu
> unterscheiden.
>
> Unrühmliche Ausnahme sind die Notification-Nachrichten von Amavis, die
> erwünscht sind, wenn "BANNED-Nachrichten" abgewiesen werden, wie z.B.
> Anhänge mit ms-exe, o.Ä.
>
> Meine Frage ist:  Kann man Amavis beibringen, diese Notification-
> Nachrichten zu signieren?
>
> Vielen Dank schon im Voraus und Gruß aus Bonn
> von Jan Behrend
>

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 4209 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20170714/d3dfbc5c/attachment.p7s>

From jbehrend at mpifr-bonn.mpg.de  Mon Jul 17 14:28:19 2017
From: jbehrend at mpifr-bonn.mpg.de (Jan Behrend)
Date: Mon, 17 Jul 2017 14:28:19 +0200
Subject: OT: Amavis Notification-Messages mit S/MIME signieren
In-Reply-To: <d571b6d7-5275-8e83-154b-da07042bcde7@sys4.de>
References: <1500016122.18737.6.camel@mpifr-bonn.mpg.de>
 <d571b6d7-5275-8e83-154b-da07042bcde7@sys4.de>
Message-ID: <1500294499.11002.6.camel@mpifr-bonn.mpg.de>

Hallo p at rick,

On Fri, 2017-07-14 at 09:41 +0200, Patrick Ben Koetter wrote:
> Du kannst mit notification_method in amavis eine Route festlegen, über
> die es die Nachricht z.B. an einen dedizierten smtp-Listener sendet.
> Dort kann Christians sigh-Milter die Nachricht S/MIME-signieren.

Top!  Implementiert und funktioniert!

Vielen Dank und LG von Jan

-- 
MAX-PLANCK-INSTITUT fuer Radioastronomie
Jan Behrend - Rechenzentrum
----------------------------------------
Auf dem Huegel 69, D-53121 Bonn                                  
Tel: +49 (228) 525 359
http://www.mpifr-bonn.mpg.de

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/x-pkcs7-signature
Dateigröße  : 6273 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20170717/96b4f244/attachment.bin>

From bbu at mailbox.org  Thu Jul 20 17:24:15 2017
From: bbu at mailbox.org (Bjoern Buerger)
Date: Thu, 20 Jul 2017 17:24:15 +0200
Subject: mail mit 5xx rejecten, aber dennoch speichern / lokal ausliefern
Message-ID: <4b3123d4-e69c-b42c-3f3a-a2508d7806f3@mailbox.org>

Moin Moin,

Vorweg: Ja, das ist eine eher schräge Idee und ich mache das
nur auf einem (mehr oder weniger) Forschungs-Setup¹ ;-)

Ich würde gerne auf einem bestimmten Relay _jegliche_ eingehende
Mail nach end of DATA mit einem 5xx rejecten, die eingelieferte
Mail aber dennoch "silent" ganz normal mit einer zusätzlichen
Header-Zeile angereichert ausliefern. Falls der Ziel-Mailserver
Probleme hat, sollte es idealerweise keinen bounce geben.

Gibt es einen eleganten, simplen, Weg, sowas mit postfix
zu erreichen? Ein explizit dafür geschriebener policy-daemon
erscheint als overkill, always_bcc wird wohl in dem Fall
nicht anwendbar sein.

Für Ideen bin ich dankbar :)

Bjørn

¹) Usecase ist ein IPv6-only System, bei dem ich den
   potentiellen IPv4-only Clients schnell eine
   Fehlermeldung zukommen lassen möchte, daß Ihre Mail
   so nicht ankommen wird. Idealerweise sofort und
   mit einem gut verständlichen Text und in der
   Hoffnung, daß das überhaupt jemand liest.

   Ich habe schon verschiedene Ansätze probiert, z.B.
   einfach gar keinen IPv4-MX zu deinieren. Da dauert
   es ewig, bis die Absender was mitbekommen und ich
   kann die Queue-Haltezeit natürlich nicht selbst
   kontrollieren.  Darüber hinaus versteht fast niemand,
   was das Problem ist, weil aus Sicht des IPv4-only
   Servers das Ziel einfach gar nicht existiert
   und die Fehlermeldung dann einfach irreführend ist.
   Einen "sprechenden" MX Namen zu verwenden, also
   z.B. "this.domain.is.ipv6.only.<sld>.<tld>" macht
   die Sache nicht unbedingt besser. Daher nun der
   Ansatz, vorrübergehend quasi einen IPv4-Bouncer
   einzurichten. Nicht schön, würde im Moment
   aber erstmal für meine Zwecke reichen, denn es
   gibt einen extra Twist: Ich habe mich entschieden,
   das mit einer privaten Domain zu machen, die schon
   lange in Benutzung ist und möchte sichergehen, daß
   ich im Zweifel keine Mails, auch keine von wichtigen
   $IPv4OnlyServices wie meiner Bank, DB, Github, [...]
   verliere. Ich bin zwar wahnsinnig, aber nicht
   komplett irre ;-)



From bbu at mailbox.org  Thu Jul 20 17:32:59 2017
From: bbu at mailbox.org (Bjoern Buerger)
Date: Thu, 20 Jul 2017 17:32:59 +0200
Subject: mail mit 5xx rejecten, aber dennoch speichern / lokal ausliefern
In-Reply-To: <4b3123d4-e69c-b42c-3f3a-a2508d7806f3@mailbox.org>
References: <4b3123d4-e69c-b42c-3f3a-a2508d7806f3@mailbox.org>
Message-ID: <ead12e6b-5ca7-33db-d6e9-a77331aee4c6@mailbox.org>

On 07/20/17 17:24, Bjoern Buerger wrote:
>  Ich bin zwar wahnsinnig, aber nicht komplett irre ;-)

Und ja:
Ich bin gerade im Urlaub und mir ist langweilig ;-)

Grüße vom Strand,
Bjørn



From postfix at jpkessler.info  Thu Jul 20 19:19:17 2017
From: postfix at jpkessler.info (Jan P. Kessler)
Date: Thu, 20 Jul 2017 19:19:17 +0200
Subject: mail mit 5xx rejecten, aber dennoch speichern / lokal ausliefern
In-Reply-To: <4b3123d4-e69c-b42c-3f3a-a2508d7806f3@mailbox.org>
References: <4b3123d4-e69c-b42c-3f3a-a2508d7806f3@mailbox.org>
Message-ID: <ba7aa237-010f-6244-2044-7e794c48aeac@jpkessler.info>


> Moin Moin,
>
> Vorweg: Ja, das ist eine eher schräge Idee und ich mache das
> nur auf einem (mehr oder weniger) Forschungs-Setup¹ ;-)
>
> Ich würde gerne auf einem bestimmten Relay _jegliche_ eingehende
> Mail nach end of DATA mit einem 5xx rejecten, die eingelieferte
> Mail aber dennoch "silent" ganz normal mit einer zusätzlichen
> Header-Zeile angereichert ausliefern. Falls der Ziel-Mailserver
> Probleme hat, sollte es idealerweise keinen bounce geben.
>
> Gibt es einen eleganten, simplen, Weg, sowas mit postfix
> zu erreichen? Ein explizit dafür geschriebener policy-daemon
> erscheint als overkill, always_bcc wird wohl in dem Fall
> nicht anwendbar sein.

Nein und ein Policy Daemon würde hier ebenfalls nicht funktionieren. Der 
sieht nur Envelope Daten und kann dann auch nur postfix veranlassen, 
anzunehmen oder zu verweigern.

Allenfalls mit einem Prequeue Content Filter oder Milter wäre das lösbar 
(ohne zu bouncen jdf). Der bekommt die Mail und kann nach dem 
END_OF_DATA des Client einen 5xx zurückgeben, die Mail aber trotzdem 
weitertransportieren.

> ¹) Usecase ist ein IPv6-only System, bei dem ich den
>     potentiellen IPv4-only Clients schnell eine
>     Fehlermeldung zukommen lassen möchte, daß Ihre Mail
>     so nicht ankommen wird. Idealerweise sofort und
>     mit einem gut verständlichen Text und in der
>     Hoffnung, daß das überhaupt jemand liest.
>
>     Ich habe schon verschiedene Ansätze probiert, z.B.
>     einfach gar keinen IPv4-MX zu deinieren. Da dauert
>     es ewig, bis die Absender was mitbekommen und ich
>     kann die Queue-Haltezeit natürlich nicht selbst
>     kontrollieren.  Darüber hinaus versteht fast niemand,
>     was das Problem ist, weil aus Sicht des IPv4-only
>     Servers das Ziel einfach gar nicht existiert
>     und die Fehlermeldung dann einfach irreführend ist.
>     Einen "sprechenden" MX Namen zu verwenden, also
>     z.B. "this.domain.is.ipv6.only.<sld>.<tld>" macht
>     die Sache nicht unbedingt besser. Daher nun der
>     Ansatz, vorrübergehend quasi einen IPv4-Bouncer
>     einzurichten. Nicht schön, würde im Moment
>     aber erstmal für meine Zwecke reichen, denn es
>     gibt einen extra Twist: Ich habe mich entschieden,
>     das mit einer privaten Domain zu machen, die schon
>     lange in Benutzung ist und möchte sichergehen, daß
>     ich im Zweifel keine Mails, auch keine von wichtigen
>     $IPv4OnlyServices wie meiner Bank, DB, Github, [...]
>     verliere. Ich bin zwar wahnsinnig, aber nicht
>     komplett irre ;-)

Ab hier IMO:

Naja, ich weiß nicht... Du erzeugst vermutlich auch Bounces zu dieser 
Liste. Von "außen" betrachtet und im normalen Mengengewerk von Admins 
großer Installationen wirkt das "unzustellbar" und Deine Subscription 
wird entfernt. Was genau willst Du denn erreichen? Meinst Du, die Github 
Leute oder die Admins der DB lesen Deine Bounces und konfigurieren dann 
nen v6-only Transport für Dich?

Wenn Du nix verlieren willst, nimm 'ne "Labordomain" und gib die Adresse 
nicht überall an. Oder setze MX10 auf v6 und MX20 auf v4.

Wenn Du "hart" sein willst, kill' den v4 MX und steh's durch. Dass Du 
mit dem Entschluss bereits Probleme hattest, könnte aber darauf 
hindeuten, dass ein Teil der Welt noch nicht so weit ist wie Du und auf 
v4 noch nicht verzichten kann/möchte - oder vielleicht bist es ja auch 
Du, der nicht auf die schnöden v4-Mails verzichten möchte ;)

Vg, Jan




From bbu at mailbox.org  Thu Jul 20 21:09:11 2017
From: bbu at mailbox.org (Bjoern Buerger)
Date: Thu, 20 Jul 2017 21:09:11 +0200
Subject: mail mit 5xx rejecten, aber dennoch speichern / lokal ausliefern
In-Reply-To: <ba7aa237-010f-6244-2044-7e794c48aeac@jpkessler.info>
References: <4b3123d4-e69c-b42c-3f3a-a2508d7806f3@mailbox.org>
 <ba7aa237-010f-6244-2044-7e794c48aeac@jpkessler.info>
Message-ID: <41377771-43e2-d3b5-f9db-20e8686698ed@mailbox.org>

On 07/20/17 19:19, Jan P. Kessler wrote:
> Nein und ein Policy Daemon würde hier ebenfalls nicht funktionieren. Der
> sieht nur Envelope Daten und kann dann auch nur postfix veranlassen,
> anzunehmen oder zu verweigern.

Hmm, stimmt.

> Allenfalls mit einem Prequeue Content Filter oder Milter wäre das lösbar
> (ohne zu bouncen jdf). Der bekommt die Mail und kann nach dem
> END_OF_DATA des Client einen 5xx zurückgeben, die Mail aber trotzdem
> weitertransportieren.

ACK. Ich werde mir das Milter Framework mal genauer anschauen.

> Ab hier IMO:

Danke für die Gedanken dazu.

> Naja, ich weiß nicht... Du erzeugst vermutlich auch Bounces zu dieser
> Liste.

Korrekt. Deshalb habe ich alle Listen Subscriptions
vorsichtshalber auf v4-capable Domains verschoben.
Wie gesagt: Ich bin lediglich experimentierfreudig,
nicht total irre ;)

> Was genau willst Du denn erreichen? Meinst Du, die Github
> Leute oder die Admins der DB lesen Deine Bounces
> und konfigurieren dann nen v6-only Transport für Dich?

Ja. BCP 177.
Aber Ich bin diesbezüglich ein hoffnungsloser Optimist.

> Wenn Du nix verlieren willst, nimm 'ne "Labordomain"
> und gib die Adresse nicht überall an.

Been there, done that. Einen v6-only Server habe ich seit
ca. 2007 laufen, insofern ist das jetzt lediglich die nächste
Iteration auf dem Weg zu einem echten v6-only Produktivsetup.

> Oder setze MX10 auf v6 und MX20 auf v4.

Leider sinnlos, weil Dualstack-Systeme eh in der Regel
mit v6 beginnen würden (bei smtp, http ist wegen
Happy Eyeball Implementierungen in den Browsern unter
Umständen ein anderer Schnack)

Ich weiss schon diverse Dinge, die für mich kaputt gehen werden.

Aber die spannenden Fragen spielen sich z.B. bei den Spamfiltern
ab. Was macht ein System, wenn es weder A, noch A-MX record
sieht? Oder wenn ein System zwar Dualstack kann, aber den
VRFY nur per v4 macht? Das will ich alles mal in RL sehen.

Letztlich ist es mir lieber, wenn der Absender einen klaren und
sofortigen Reject bekommt, als daß Mails an mich tagelang in
fremden Queues herumgammeln und am Ende ein irreführender Bounce
a'la "host not found" dabei rauskommt. Beim sofortigen Reject
kommt der Versender erfahrungsgemäß auf die Idee, anzurufen.

> Wenn Du "hart" sein willst, kill' den v4 MX und steh's durch. Dass Du
> mit dem Entschluss bereits Probleme hattest, könnte aber darauf
> hindeuten, dass ein Teil der Welt noch nicht so weit ist wie Du und auf
> v4 noch nicht verzichten kann/möchte - oder vielleicht bist es ja auch
> Du, der nicht auf die schnöden v4-Mails verzichten möchte ;)

Da ich es schon ausprobiert habe, weiss ich ungefähr, was passieren
wird. Ich bin aber recht konservativ und würde wegen der zu Erwartenden
Probleme für eine Übergangszeit gerne noch ein Sicherheitsnetz
einziehen. Wenn nix relevantes mehr in der Backup-Box landet,
schalte ich den v4 MX einfach komplett ab. Das ist dann aber
wieder eine weitere Testrunde.

Ich vermute, daß dieser Teil der Diskussion für die Liste
eher zu sehr OffTopic ist. Follow-Up gerne per PM.


LG,
Bjørn




From martin at lichtvoll.de  Sat Jul 22 08:43:10 2017
From: martin at lichtvoll.de (Martin Steigerwald)
Date: Sat, 22 Jul 2017 08:43:10 +0200
Subject: Spam-Newsletter via smartmailer.com
Message-ID: <37520238.3Qo3KWYt9q@merkaba>

Hallo.

Sowas:

From: BitcoinNEWS <john ___  @  ### nowakexpress ddd com>
[?]
Subject: (Brand New) World's First Done For You Crypto Currency Trading

Abuse Report URL mit Webformular, das Cookies braucht und ein 255 Zeichen-
Limit hat:

X-Report-Abuse: Please report abuse for this campaign here: http://
mala-742.us.list-connect.com/abuse.php?c=eq54[?]&l=ce[?]

Also nach Abuse Contact gesucht:

http://www.smartmailer.com/abuse.php

=> support at smartmailer.com


Also Spam Report mit angehängtem Spam-Newsletter oder auch nur den kopierten 
Kopfzeilen an diese Adresse. Antwort:

<support at smartmailer.com>: host aspmx.l.google.com[2a00:1450:400c:c07::1a]
    said: 550-5.7.1 [2001:67c:14c:12f::11:1      12] Our system has detected
    that this 550-5.7.1 message is likely unsolicited mail. To reduce the
    amount of spam sent 550-5.7.1 to Gmail, this message has been blocked.
    Please visit 550-5.7.1
    https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1  for
    more information. f14si9289655wrf.68 - gsmtp (in reply to end of DATA
    command)

Geht`s noch?


Daher Client-Checks:

# Spam-Newsletter via smartmailer.com
199.43.200.0/24         reject C2017.07: Repeated source of spam. Network 
permanently blocked as you do not accept spam abuse reports through 
support at smartmailer.com, due to gmail spam filtering.

199.43.201.0/24         reject C2017.07: Repeated source of spam. Network 
permanently blocked as you do not accept spam abuse reports through 
support at smartmailer.com, due to gmail spam filtering.

199.43.202.0/24         reject C2017.07: Repeated source of spam. Network 
permanently blocked as you do not accept spam abuse reports through 
support at smartmailer.com, due to gmail spam filtering.

199.43.203.0/24         reject C2017.07: Repeated source of spam. Network 
permanently blocked as you do not accept spam abuse reports through 
support at smartmailer.com, due to gmail spam filtering.

Ich hoffe ich habe alle MTA-Netze von denen erwischt.

*grrrrrr*

Ich möchte alle kommerziellen Newsletter-Provider, die keine funktionierendes 
Abuse-Reporting via Mail haben restlos vom Netz nehmen. Da bräuchte es mal 
eine entsprechende Gesetzgebung, die vorschreibt, dass jemand der im Kunden-
Auftrag Newsletter versendet, eine ganz einfache Möglichkeit hat, via 
Forwarding der Spam-Mails an eine bestimmte Adresse einen Spam Report zu 
erstellen.

Am Ende habe ich support at smartmailer.com dann nur noch über diesen Netzwerk-
Block informiert.

Danke.
-- 
Martin
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: This is a digitally signed message part.
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20170722/e40e1b86/attachment.asc>

From driessen at fblan.de  Sat Jul 22 11:24:30 2017
From: driessen at fblan.de (=?UTF-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Sat, 22 Jul 2017 11:24:30 +0200
Subject: AW: Spam-Newsletter via smartmailer.com
In-Reply-To: <37520238.3Qo3KWYt9q@merkaba>
References: <37520238.3Qo3KWYt9q@merkaba>
Message-ID: <016501d302cc$53122b80$f9368280$@fblan.de>

Im Auftrag von Martin Steigerwald
> 
> Daher Client-Checks:
> 
> # Spam-Newsletter via smartmailer.com
> 199.43.200.0/24         reject C2017.07: Repeated source of spam. Network
> permanently blocked as you do not accept spam abuse reports through
> support at smartmailer.com, due to gmail spam filtering.
> 
> 199.43.201.0/24         reject C2017.07: Repeated source of spam. Network
> permanently blocked as you do not accept spam abuse reports through
> support at smartmailer.com, due to gmail spam filtering.
> 
> 199.43.202.0/24         reject C2017.07: Repeated source of spam. Network
> permanently blocked as you do not accept spam abuse reports through
> support at smartmailer.com, due to gmail spam filtering.
> 
> 199.43.203.0/24         reject C2017.07: Repeated source of spam. Network
> permanently blocked as you do not accept spam abuse reports through
> support at smartmailer.com, due to gmail spam filtering.
> 


Ein  199.43.200.0/22 reicht :-) 

Network:   199.43.200.0/22      11000111.00101011.110010 00.00000000
HostMin:   199.43.200.1         11000111.00101011.110010 00.00000001
HostMax:   199.43.203.254       11000111.00101011.110010 11.11111110
Broadcast: 199.43.203.255       11000111.00101011.110010 11.11111111
Hosts/Net: 1022                  Class C

Ich hab allerdings noch nie irgendeine Mail aus dem Netz oder von smartmailer bekommen  


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 martin at lichtvoll.de  Sat Jul 22 11:41:47 2017
From: martin at lichtvoll.de (Martin Steigerwald)
Date: Sat, 22 Jul 2017 11:41:47 +0200
Subject: Spam-Newsletter via smartmailer.com
In-Reply-To: <016501d302cc$53122b80$f9368280$@fblan.de>
References: <37520238.3Qo3KWYt9q@merkaba>
 <016501d302cc$53122b80$f9368280$@fblan.de>
Message-ID: <9684635.eMVrFfJXBS@merkaba>

Uwe Drießen - 22.07.17, 11:24:
> > Daher Client-Checks:
> > 
> > # Spam-Newsletter via smartmailer.com
> > 199.43.200.0/24         reject C2017.07: Repeated source of spam. Network
> > permanently blocked as you do not accept spam abuse reports through
> > support at smartmailer.com, due to gmail spam filtering.
> > 
> > 199.43.201.0/24         reject C2017.07: Repeated source of spam. Network
[?]
> > 199.43.202.0/24         reject C2017.07: Repeated source of spam. Network
[?]
> > 199.43.203.0/24         reject C2017.07: Repeated source of spam. Network
[?]
> Ein  199.43.200.0/22 reicht :-)

Lol, daran habe ich im Eifer des Gefechts nicht gedacht. Danke.

> Ich hab allerdings noch nie irgendeine Mail aus dem Netz oder von
> smartmailer bekommen  

Ich denke, ich hatte mich schon irgendwann mal über deren miserable Spam-
Reporting-Möglichkeiten aufgeregt. Das ist aber schon lange her.

Ciao,
-- 
Martin


From driessen at fblan.de  Sat Jul 22 11:56:45 2017
From: driessen at fblan.de (=?UTF-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Sat, 22 Jul 2017 11:56:45 +0200
Subject: AW: Spam-Newsletter via smartmailer.com
In-Reply-To: <9684635.eMVrFfJXBS@merkaba>
References: <37520238.3Qo3KWYt9q@merkaba>
 <016501d302cc$53122b80$f9368280$@fblan.de> <9684635.eMVrFfJXBS@merkaba>
Message-ID: <016601d302d0$d44f8270$7cee8750$@fblan.de>

Im Auftrag von Martin Steigerwald
> Uwe Drießen - 22.07.17, 11:24:
> > Ein  199.43.200.0/22 reicht :-)
> 
> Lol, daran habe ich im Eifer des Gefechts nicht gedacht. Danke.
> 
> > Ich hab allerdings noch nie irgendeine Mail aus dem Netz oder von
> > smartmailer bekommen
> 
> Ich denke, ich hatte mich schon irgendwann mal über deren miserable Spam-
> Reporting-Möglichkeiten aufgeregt. Das ist aber schon lange her.

Ein whois 199.43.200

Fördert  noch 2 Netze hervor 

NetRange:       199.43.199.0 - 199.43.205.255
CIDR:           199.43.204.0/23, 199.43.200.0/22, 199.43.199.0/24

Und  ein Abuse für die IP's
 




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 martin at lichtvoll.de  Sat Jul 22 12:05:33 2017
From: martin at lichtvoll.de (Martin Steigerwald)
Date: Sat, 22 Jul 2017 12:05:33 +0200
Subject: Spam-Newsletter via smartmailer.com
In-Reply-To: <016601d302d0$d44f8270$7cee8750$@fblan.de>
References: <37520238.3Qo3KWYt9q@merkaba> <9684635.eMVrFfJXBS@merkaba>
 <016601d302d0$d44f8270$7cee8750$@fblan.de>
Message-ID: <2014280.VRbtkeb44P@merkaba>

Uwe Drießen - 22.07.17, 11:56:
> > Uwe Drießen - 22.07.17, 11:24:
> > > Ein  199.43.200.0/22 reicht :-)
> > 
> > Lol, daran habe ich im Eifer des Gefechts nicht gedacht. Danke.
> > 
> > > Ich hab allerdings noch nie irgendeine Mail aus dem Netz oder von
> > > smartmailer bekommen
> > 
> > Ich denke, ich hatte mich schon irgendwann mal über deren miserable Spam-
> > Reporting-Möglichkeiten aufgeregt. Das ist aber schon lange her.
> 
> Ein whois 199.43.200
> 
> Fördert  noch 2 Netze hervor
> 
> NetRange:       199.43.199.0 - 199.43.205.255
> CIDR:           199.43.204.0/23, 199.43.200.0/22, 199.43.199.0/24
> 
> Und  ein Abuse für die IP's

Hmmm, spannend, mein whois macht das nicht:

martin at merkaba:~> whois 199.43.200
Für diese Art von Objekten ist kein Whois-Server bekannt.

Wohl aber mit 199.43.200.0.  whois aus dem Debian-Paket whois 5.2.16 (Debian 
Unstable).

So oder so: abuse at dacentec.com hat dasselbe Problem. Und ich weiß auch nicht, 
ob all diese Netze für smartmailer.com sind.

Bei den von mir genannten Netzen bin ich ziemlich sicher:

martin at merkaba:~> host 199.43.200.0
1.200.43.199.in-addr.arpa domain name pointer mta-1.us5.smartmtp.com.
martin at merkaba:~> host 199.43.201.0
1.201.43.199.in-addr.arpa domain name pointer mta-1.us6.smartmtp.com.
martin at merkaba:~> host 199.43.202.0
1.202.43.199.in-addr.arpa domain name pointer mta-1.us7.smartmtp.com.
martin at merkaba:~> host 199.43.203.0
1.203.43.199.in-addr.arpa domain name pointer mta-1.us8.smartmtp.com.

Für die anderen Netze sieht es eher nicht so aus:

martin at merkaba:~> host 199.43.204.0
Host 1.204.43.199.in-addr.arpa. not found: 3(NXDOMAIN)
martin at merkaba:~#1> host 199.43.205.0
Host 1.205.43.199.in-addr.arpa. not found: 3(NXDOMAIN)
martin at merkaba:~#1> host 199.43.199.0
Host 1.199.43.199.in-addr.arpa. not found: 3(NXDOMAIN)

Ist natürlich ne spannende Frage, ob es auch:

us1-4.smartmtp.com.

gibt. Das wäre nochmal was, sieht aber auch eher nicht so aus:

martin at merkaba:~> host mta-1.us2.smartmtp.com.
martin at merkaba:~> host mta-1.us3.smartmtp.com.
martin at merkaba:~> host mta-1.us4.smartmtp.com.
martin at merkaba:~> host mta-1.us9.smartmtp.com.
martin at merkaba:~> host us1.smartmtp.com. 
martin at merkaba:~> host us2.smartmtp.com.
martin at merkaba:~> host us3.smartmtp.com.
martin at merkaba:~> host us4.smartmtp.com.
martin at merkaba:~> host us9.smartmtp.com.

Danke,
-- 
Martin


From martin at lichtvoll.de  Sat Jul 22 18:20:04 2017
From: martin at lichtvoll.de (Martin Steigerwald)
Date: Sat, 22 Jul 2017 18:20:04 +0200
Subject: Spam-Newsletter via smartmailer.com (und Netzwerk von 1&1)
In-Reply-To: <016501d302cc$53122b80$f9368280$@fblan.de>
References: <37520238.3Qo3KWYt9q@merkaba>
 <016501d302cc$53122b80$f9368280$@fblan.de>
Message-ID: <1599126.EDGjHNXALV@merkaba>

Uwe Drießen - 22.07.17, 11:24:
> Im Auftrag von Martin Steigerwald
> 
> > Daher Client-Checks:
> > 
> > # Spam-Newsletter via smartmailer.com
> > 199.43.200.0/24         reject C2017.07: Repeated source of spam. Network
> > permanently blocked as you do not accept spam abuse reports through
> > support at smartmailer.com, due to gmail spam filtering.
[?]
> Ein  199.43.200.0/22 reicht :-)

Das scheint gerade umzugehen. Ich hab gerade noch mehr geblockt:

Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.lichtvoll.de (Postfix) with ESMTPS id 350FC10552C
	for <martin at lichtvoll.de>; Sat, 22 Jul 2017 17:48:47 +0200 (CEST)

Verschiedene IP-Adressen, daher jetzt versuchsweise mal:

74.208.4.0/24           reject C2017.07: Repeated source of spam. Network 
permanently blocked.

Spam-Bericht an 1&1 gesendet. Die reagieren da in der Regel drauf.

Ciao,
-- 
Martin


From martin at lichtvoll.de  Mon Jul 24 17:09:04 2017
From: martin at lichtvoll.de (Martin Steigerwald)
Date: Mon, 24 Jul 2017 17:09:04 +0200
Subject: Liste mit dubiosen Newsletter-Providern ohne (Double) Opt In?
Message-ID: <23094941.pUk4uxMdk5@merkaba>

Hallo.

irgendwelche Bots oder Menschen scheinen meine Mail-Adresse in dubiose 
Newsletter einzutragen, die ohne Double (Opt-In) arbeiten.

Am Sonntag des Wochenendes mit dem bislang höchsten neuen Spam-Aufkommen, das 
ich erlebte, hab ich die Konfiguration meines Mail-Servers hochgerüstet:

- After-Queue SpamAssasin mit spamd => Before-Queue SpamAssassin mit spampd, 
SpamAssassin auch mit Remote-Checks, das scheint auf meinem Mailserver schnell 
genug zu gehen

- Postscreen mit einem Haufen an DNS-Blacklists

- policyd-weight, jedoch jetzt ohne DNS-Blacklists.


Außerdem hab ich das hier angesammelt:

mondschein:/etc/postfix> cat postscreen_access.cidr 
# Spam-Newsletter via smartmailer.com
199.43.200.0/22         reject 2017.07: Repeated source of spam. Network 
permanently blocked as you do not accept spam abuse reports through 
support at smartmailer.com, due to gmail spam filtering.

# Werbefirma Beep Media
173.213.227.208/29      REJECT 2017.07: Repeated source of spam. Network 
permanently blocked.

# Newsletter Firma ymlp.com
185.83.48.0/22          REJECT 2017.07: Repeated source of spam. Network 
permanently blocked.


Gibts da irgendwo eine Liste mit Newsletter-Providern ohne (Double) Opt In?

Ich will das alles blocken. Wer solche grundlegenden Dinge nicht beachtet, 
bekommt bei mir Hausverbot. Ich schrecke mittlerweile auch nicht mehr davor 
zurück komplette Netzwerke zu blocken. Mir reicht es.

Danke,
-- 
Martin


From sebastian at debianfan.de  Tue Jul 25 09:22:33 2017
From: sebastian at debianfan.de (sebastian at debianfan.de)
Date: Tue, 25 Jul 2017 09:22:33 +0200
Subject: Freischaltung einer IP
Message-ID: <2E66AC3B-CE16-4ACD-82D2-B70E89A4A5C7@debianfan.de>

Hallo,

ein Mailserver steht als Relay im internen Netz. Dort ist für eine Anmeldung per SMTP-Auth vonnöten, um Mails abzuliefern - Sicherheitsgründe.
Es soll aber nur die IP 192.168.X.X auf dem Mails zum Versand einliefern können. (Dieser Mailserver dient nur als Relay und gibt die Mails dann beim Serviceprodvider ab).

Der Hintergrund ist, dass diese Maschine technische Mails verschickt (Statusmeldungen) und leider kein SMTP-Auth kann - SAP machts möglich ;-)

Wo trage ich diese Freischaltung für eine einzelne  IP ein?

Gruß & Danke

Sebastian



From kai_postfix at fuerstenberg.ws  Tue Jul 25 09:53:01 2017
From: kai_postfix at fuerstenberg.ws (=?UTF-8?Q?Kai_F=c3=bcrstenberg?=)
Date: Tue, 25 Jul 2017 09:53:01 +0200
Subject: Freischaltung einer IP
In-Reply-To: <2E66AC3B-CE16-4ACD-82D2-B70E89A4A5C7@debianfan.de>
References: <2E66AC3B-CE16-4ACD-82D2-B70E89A4A5C7@debianfan.de>
Message-ID: <8d24dfa8-030d-dece-fab6-6e080c580533@fuerstenberg.ws>

Hi Sebastian,

Am 25.07.2017 um 09:22 schrieb sebastian at debianfan.de:
> Hallo,
> 
> ein Mailserver steht als Relay im internen Netz. Dort ist für eine Anmeldung per SMTP-Auth vonnöten, um Mails abzuliefern - Sicherheitsgründe.
> Es soll aber nur die IP 192.168.X.X auf dem Mails zum Versand einliefern können. (Dieser Mailserver dient nur als Relay und gibt die Mails dann beim Serviceprodvider ab).
> 
> Der Hintergrund ist, dass diese Maschine technische Mails verschickt (Statusmeldungen) und leider kein SMTP-Auth kann - SAP machts möglich ;-)
> 
> Wo trage ich diese Freischaltung für eine einzelne  IP ein?

mit einem

  check_client_access -> IP -> permit_auth_destination

dürfte das funktionieren.

-- 
Kai Fürstenberg

PM an: kai at fuerstenberg punkt ws




From sebastian at debianfan.de  Tue Jul 25 10:18:43 2017
From: sebastian at debianfan.de (sebastian at debianfan.de)
Date: Tue, 25 Jul 2017 10:18:43 +0200
Subject: Freischaltung einer IP
In-Reply-To: <8d24dfa8-030d-dece-fab6-6e080c580533@fuerstenberg.ws>
References: <2E66AC3B-CE16-4ACD-82D2-B70E89A4A5C7@debianfan.de>
 <8d24dfa8-030d-dece-fab6-6e080c580533@fuerstenberg.ws>
Message-ID: <f498a0b3486e2e52d742d2053b482881@debianfan.de>

Am 2017-07-25 09:53, schrieb Kai Fürstenberg:
> 
> mit einem
> 
>   check_client_access -> IP -> permit_auth_destination
> 
> dürfte das funktionieren.

Danke - aber irgendwas geht noch nicht - ich habe bislang eher weniger 
Erfahrungen mit der Schaffung eines "offenen" Relays ;-)


smtpd_client_restrictions =     permit_mynetworks
                                 check_client_access 
hash:/etc/postfix/check_client_access


und in der Datei

192.178.5.7 OK

dann Postmap & Postfix restarten - aber nix geht - Relay-Access Denied


From kai_postfix at fuerstenberg.ws  Tue Jul 25 10:23:41 2017
From: kai_postfix at fuerstenberg.ws (=?UTF-8?Q?Kai_F=c3=bcrstenberg?=)
Date: Tue, 25 Jul 2017 10:23:41 +0200
Subject: Freischaltung einer IP
In-Reply-To: <f498a0b3486e2e52d742d2053b482881@debianfan.de>
References: <2E66AC3B-CE16-4ACD-82D2-B70E89A4A5C7@debianfan.de>
 <8d24dfa8-030d-dece-fab6-6e080c580533@fuerstenberg.ws>
 <f498a0b3486e2e52d742d2053b482881@debianfan.de>
Message-ID: <8e9dbb11-893b-748f-0936-0b3334f69975@fuerstenberg.ws>

Am 25.07.2017 um 10:18 schrieb sebastian at debianfan.de:
> Am 2017-07-25 09:53, schrieb Kai Fürstenberg:
>>
>> mit einem
>>
>>   check_client_access -> IP -> permit_auth_destination
>>
>> dürfte das funktionieren.
> 
> Danke - aber irgendwas geht noch nicht - ich habe bislang eher weniger 
> Erfahrungen mit der Schaffung eines "offenen" Relays ;-)
> 
> 
> smtpd_client_restrictions =     permit_mynetworks
>                                  check_client_access 
> hash:/etc/postfix/check_client_access
> 
> 
> und in der Datei
> 
> 192.178.5.7 OK
> 
> dann Postmap & Postfix restarten - aber nix geht - Relay-Access Denied
> 

192.178... ist eine öffentliche Adresse. Dann solltest du eher nicht
"OK", sondern "permit_auth_destination" verwenden.

Weiterhin muss der Check vor dem permit_sasl_authenticated stehen.

Für alles weitere bitte postconf -n und Logs.

-- 
Kai Fürstenberg

PM an: kai at fuerstenberg punkt ws



From ms at ddnetservice.de  Tue Jul 25 10:36:53 2017
From: ms at ddnetservice.de (Michael Seevogel)
Date: Tue, 25 Jul 2017 10:36:53 +0200
Subject: Freischaltung einer IP
In-Reply-To: <f498a0b3486e2e52d742d2053b482881@debianfan.de>
References: <2E66AC3B-CE16-4ACD-82D2-B70E89A4A5C7@debianfan.de>
 <8d24dfa8-030d-dece-fab6-6e080c580533@fuerstenberg.ws>
 <f498a0b3486e2e52d742d2053b482881@debianfan.de>
Message-ID: <bf75f474-0274-1bd8-dbe3-559035f39086@ddnetservice.de>

Am 25.07.2017 um 10:18 schrieb sebastian at debianfan.de:
> Am 2017-07-25 09:53, schrieb Kai Fürstenberg:
>>
>> mit einem
>>
>>   check_client_access -> IP -> permit_auth_destination
>>
>> dürfte das funktionieren.
> 
> Danke - aber irgendwas geht noch nicht - ich habe bislang eher weniger 
> Erfahrungen mit der Schaffung eines "offenen" Relays ;-)
> 
> 
> smtpd_client_restrictions =     permit_mynetworks
>                                  check_client_access 
> hash:/etc/postfix/check_client_access
> 
> 
> und in der Datei
> 
> 192.178.5.7 OK
> 
> dann Postmap & Postfix restarten - aber nix geht - Relay-Access Denied




Alternativ könntest Du die IP in mynetworks eintragen. Dann gehört die 
IP zu den trusted networks.
Dann kann Dein Client definitiv das Relay "offen" ohne auth benutzen.

Ob das allerdings der "best-practice" Weg ist, oder ob es eine bessere 
Lösung gibt, kann ich Dir aber gerade nicht garantieren.


Gruß
Michael


From news at amaltea.de  Tue Jul 25 10:50:46 2017
From: news at amaltea.de (Paul)
Date: Tue, 25 Jul 2017 10:50:46 +0200
Subject: Freischaltung einer IP
In-Reply-To: <f498a0b3486e2e52d742d2053b482881@debianfan.de>
References: <2E66AC3B-CE16-4ACD-82D2-B70E89A4A5C7@debianfan.de>
 <8d24dfa8-030d-dece-fab6-6e080c580533@fuerstenberg.ws>
 <f498a0b3486e2e52d742d2053b482881@debianfan.de>
Message-ID: <5b2fc798-60e5-ed05-8ec8-fd48877fa8dc@amaltea.de>

Am 25.07.2017 um 10:18 schrieb sebastian at debianfan.de:
> Am 2017-07-25 09:53, schrieb Kai Fürstenberg:
>>
>> mit einem
>>
>>   check_client_access -> IP -> permit_auth_destination
>>
>> dürfte das funktionieren.
> 
> Danke - aber irgendwas geht noch nicht - ich habe bislang eher weniger
> Erfahrungen mit der Schaffung eines "offenen" Relays ;-)
> 
> 
> smtpd_client_restrictions =     permit_mynetworks
>                                 check_client_access
> hash:/etc/postfix/check_client_access
> 
> 
> und in der Datei
> 
> 192.178.5.7 OK
> 
> dann Postmap & Postfix restarten - aber nix geht - Relay-Access Denied

cidr statt hash. Damit sollte es klappen.
http://www.postfix.org/cidr_table.5.html




From martin at lichtvoll.de  Tue Jul 25 15:24:32 2017
From: martin at lichtvoll.de (Martin Steigerwald)
Date: Tue, 25 Jul 2017 15:24:32 +0200
Subject: Postscreen-Konfiguration
Message-ID: <4664635.6eCRBb36FK@merkaba>

Hallo.

Integration in master.cf ist für mich klar. Das Teil funktioniert auch 
bereits.

Habt ihr noch irgendwelche sinnvollen Ideen, das Teil noch strikter vorgehen 
zu lassen, ohne dass es gravierende Auswirkungen hat? Was habt ihr für 
Blacklisten. Ich hab mir dazu einige von http://www.dnsbl.info/dnsbl-list.php 
zusammengesucht, aber letztlich ist es immer so eine Frage, woran ich 
entscheide, inwiefern ich einer Liste vertraue.


Hier mal meine Konfiguration in main.cf:

# Postscreen
postscreen_access_list = permit_mynetworks,
        cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_threshold = 4
# http://www.dnsbl.info/dnsbl-list.php
postscreen_dnsbl_sites = zen.spamhaus.org*2
        bl.spamcop.net   
        dnsbl.sorbs.net  
        psbl.surriel.com 
        drone.abuse.ch   
        spam.abuse.ch
        dnsbl.anticaptcha.net
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce
#postscreen_bare_newline_action = enforce
#postscreen_bare_newline_enable = yes
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = drop
#postscreen_pipelining_enable = yes
#postscreen_pipelining_enable = enforce
postscreen_cache_map = lmdb:$data_directory/postscreen_cache


Teilweise in Anlehnung an:

Aus Linux-Magazin 08/2011
Christoph Wickert
Tests und Aktionen für eingehende E-Mails
http://www.linux-magazin.de/Ausgaben/2011/08/Spamabwehr/(offset)/6


Deswegen hab ich bare_newline und pipelining_enable nicht aktiviert. Kann ich 
aber auch wieder an machen.

Ich werd mir die Detail-Erklärungen im Postscreen-Howto auch nochmal genauer 
durchlesen, aber vielleicht habt ihr noch irgendwelche Tipps.

Ciao,
-- 
Martin


From jost+lists at dimejo.at  Tue Jul 25 15:32:12 2017
From: jost+lists at dimejo.at (Alex JOST)
Date: Tue, 25 Jul 2017 15:32:12 +0200
Subject: Postscreen-Konfiguration
In-Reply-To: <4664635.6eCRBb36FK@merkaba>
References: <4664635.6eCRBb36FK@merkaba>
Message-ID: <0750f489-1200-2c33-244e-06b19be3701f@dimejo.at>

Am 25.07.2017 um 15:24 schrieb Martin Steigerwald:
> Hallo.
> 
> Integration in master.cf ist für mich klar. Das Teil funktioniert auch
> bereits.
> 
> Habt ihr noch irgendwelche sinnvollen Ideen, das Teil noch strikter vorgehen
> zu lassen, ohne dass es gravierende Auswirkungen hat? Was habt ihr für
> Blacklisten. Ich hab mir dazu einige von http://www.dnsbl.info/dnsbl-list.php
> zusammengesucht, aber letztlich ist es immer so eine Frage, woran ich
> entscheide, inwiefern ich einer Liste vertraue.
> 
> 
> Hier mal meine Konfiguration in main.cf:
> 
> # Postscreen
> postscreen_access_list = permit_mynetworks,
>          cidr:/etc/postfix/postscreen_access.cidr
> postscreen_blacklist_action = drop
> postscreen_dnsbl_threshold = 4
> # http://www.dnsbl.info/dnsbl-list.php
> postscreen_dnsbl_sites = zen.spamhaus.org*2
>          bl.spamcop.net
>          dnsbl.sorbs.net
>          psbl.surriel.com
>          drone.abuse.ch
>          spam.abuse.ch
>          dnsbl.anticaptcha.net
> postscreen_dnsbl_action = enforce
> postscreen_greet_action = enforce
> #postscreen_bare_newline_action = enforce
> #postscreen_bare_newline_enable = yes
> postscreen_non_smtp_command_enable = yes
> postscreen_non_smtp_command_action = drop
> #postscreen_pipelining_enable = yes
> #postscreen_pipelining_enable = enforce
> postscreen_cache_map = lmdb:$data_directory/postscreen_cache
> 
> 
> Teilweise in Anlehnung an:
> 
> Aus Linux-Magazin 08/2011
> Christoph Wickert
> Tests und Aktionen für eingehende E-Mails
> http://www.linux-magazin.de/Ausgaben/2011/08/Spamabwehr/(offset)/6
> 
> 
> Deswegen hab ich bare_newline und pipelining_enable nicht aktiviert. Kann ich
> aber auch wieder an machen.
> 
> Ich werd mir die Detail-Erklärungen im Postscreen-Howto auch nochmal genauer
> durchlesen, aber vielleicht habt ihr noch irgendwelche Tipps.

Soweit ich das sagen kann hat zen.spamhaus.org bei uns bis jetzt keine 
falschen Treffer enthalten. Entsprechend könntest Du den Wert auf 3 oder 
sogar 4 hoch drehen.

In jedem Fall solltest Du Dir überlegen eine Whitelist wie dnswl.org zu 
benutzen. Das reduziert die Wahrscheinlichkeit von falschen Treffern 
deutlich.

-- 
Alex JOST


From martin at lichtvoll.de  Tue Jul 25 15:34:51 2017
From: martin at lichtvoll.de (Martin Steigerwald)
Date: Tue, 25 Jul 2017 15:34:51 +0200
Subject: Postscreen-Konfiguration
In-Reply-To: <4664635.6eCRBb36FK@merkaba>
References: <4664635.6eCRBb36FK@merkaba>
Message-ID: <1942442.8z1BhqsZUb@merkaba>

Martin Steigerwald - 25.07.17, 15:24:
> #postscreen_bare_newline_action = enforce
> #postscreen_bare_newline_enable = yes
> postscreen_non_smtp_command_enable = yes
> postscreen_non_smtp_command_action = drop
> #postscreen_pipelining_enable = yes
> #postscreen_pipelining_enable = enforce

Naja, der der non_smtp_command schon lange dauert, kann ich die anderen beiden 
ja auch noch einschalten. Das dürfte dann auch nix mehr ausmachen.

non_smtp_command_enable hat mindestens einmal bereits getriggert, das habe ich 
im Log gesehen.

-- 
Martin


From jra at byte.cx  Tue Jul 25 15:47:10 2017
From: jra at byte.cx (Jens Adam)
Date: Tue, 25 Jul 2017 15:47:10 +0200
Subject: Postscreen-Konfiguration
In-Reply-To: <4664635.6eCRBb36FK@merkaba>
References: <4664635.6eCRBb36FK@merkaba>
Message-ID: <39F93A70-EE36-4548-A81D-B677FAE1C72F@byte.cx>


> Habt ihr noch irgendwelche sinnvollen Ideen, das Teil noch strikter vorgehen
> zu lassen, ohne dass es gravierende Auswirkungen hat? Was habt ihr für
> Blacklisten.

https://listi.jpberlin.de/pipermail/postfixbuch-users/2017-May/065150.html
... immer noch nicht wieder reevaluiert. :/

Ansonsten halt rein IP-basiert, keine "after greeting" Tests.

--byte


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 455 bytes
Beschreibung: Message signed with OpenPGP
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20170725/75339b3c/attachment.asc>

From mike_ebenbeck at yahoo.de  Thu Jul 27 09:39:16 2017
From: mike_ebenbeck at yahoo.de (Waschl)
Date: Thu, 27 Jul 2017 00:39:16 -0700 (MST)
Subject: check_recipient_access seltsame Verhaltensweise
Message-ID: <1501141156546-91548.post@n5.nabble.com>

Hallo zusammen,

vielleicht kann mir hier jemand helfen. Nach Umstieg auf einen neuen Mailser
(Debian Stretch - vorher Jessie)
mit gleicher Konfiguration, verhält sich check_recipient_access in den
smtpd_recipient_restrictions komisch.

smtpd_recipient_restrictions =
        reject_unknown_recipient_domain
        reject_non_fqdn_recipient
        reject_unlisted_recipient
        check_policy_service inet:127.0.0.1:10023
        check_recipient_access hash:/etc/postfix/verify_domains_recipient
        check_policy_service inet:127.0.0.1:7777
        permit_mynetworks
        permit_sasl_authenticated
        reject_unauth_destination

verify_domains_receipient:
bspa.de reject_unverified_recipient
bs2pa.de reject_unverified_recipient
bsvpa.de reject_unverified_recipient
itbspa.de reject_unverified_recipient

Wenn eine Mail von der itbspa.de Domäne zu einer Adresse in der bspa.de
Domäne geschickt wird, was ja dann alles auf dem gleichen Server passiert,
habe ich folgende seltsame Verhaltensweise:

1. Postfix macht die address verification und der Empfänger wird als
deliverable eingestuft
2. Postfix gibt den Fehler "Recipient address rejected: unverified address"
zurück

Hier noch das Log:

Jul 27 08:37:30 mail postfix/postscreen[24195]: CONNECT from
[192.168.116.200]:29698 to [192.168.118.14]:25
Jul 27 08:37:30 mail postfix/postscreen[24195]: WHITELISTED
[192.168.116.200]:29698
Jul 27 08:37:30 mail postfix/smtpd[24206]: connect from
itexchange16.itbspa.local[192.168.116.200]
Jul 27 08:37:30 mail postfix/smtpd[24206]: Anonymous TLS connection
established from itexchange16.itbspa.local[192.168.116.200]: TLSv1.2 with
cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Jul 27 08:37:30 mail postgrey[3585]: action=pass, reason=client whitelist,
client_name=itexchange16.itbspa.local, client_address=192.168.116.200,
sender=xxx at itbspa.de, recipient=xxx at bspa.de
Jul 27 08:37:30 mail postfix/cleanup[24211]: 3xJ2Mt5PVgz10vD:
message-id=<3xJ2Mt5PVgz10vD at mail.itbspa.de>
Jul 27 08:37:30 mail postfix/qmgr[24190]: 3xJ2Mt5PVgz10vD:
from=<double-bounce at itbspa.de>, size=223, nrcpt=1 (queue active)
Jul 27 08:37:30 mail postfix/smtp[24212]: Untrusted TLS connection
established to 172.18.1.11[172.18.1.11]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-SHA384 (256/256 bits)
Jul 27 08:37:35 mail postfix/smtp[24212]: 3xJ2Mt5PVgz10vD: to=<xxx at bspa.de>,
relay=172.18.1.11[172.18.1.11]:25, delay=5.1, delays=0/0/0.09/5, dsn=2.1.5,
status=deliverable (250 2.1.5 Recipient OK)
Jul 27 08:37:35 mail postfix/qmgr[24190]: 3xJ2Mt5PVgz10vD: removed
Jul 27 08:37:36 mail postfix/smtpd[24206]: NOQUEUE: reject: RCPT from
itexchange16.itbspa.local[192.168.116.200]: 450 4.1.1 <xxx at bspa.de>:
Recipient address rejected: unverified address: User unknown;
from=<xxx at itbspa.de> to=<xxx at bspa.de> proto=ESMTP helo=<webmail.itbspa.de>
Jul 27 08:37:36 mail postfix/smtpd[24206]: disconnect from
itexchange16.itbspa.local[192.168.116.200] ehlo=2 starttls=1 mail=1 rcpt=0/1
quit=1 commands=5/6



--
View this message in context: http://postfix.1071664.n5.nabble.com/check-recipient-access-seltsame-Verhaltensweise-tp91548.html
Sent from the Germany Postfixbuch mailing list archive at Nabble.com.


From mike_ebenbeck at yahoo.de  Thu Jul 27 09:44:14 2017
From: mike_ebenbeck at yahoo.de (Waschl)
Date: Thu, 27 Jul 2017 00:44:14 -0700 (MST)
Subject: Postscreen-Konfiguration
In-Reply-To: <4664635.6eCRBb36FK@merkaba>
References: <4664635.6eCRBb36FK@merkaba>
Message-ID: <1501141454563-91549.post@n5.nabble.com>

Hallo,

mit der Konfiguration fahre ich eigentlich recht gut:

postscreen_greet_action = enforce
postscreen_greet_banner = $myhostname - Please wait to be seated
postscreen_greet_ttl = 1d
postscreen_greet_wait = ${stress?2}${stress:4}s

postscreen_pipelining_enable = no
postscreen_non_smtp_command_enable = no
postscreen_bare_newline_enable = no

postscreen_dnsbl_action = enforce
postscreen_blacklist_action = enforce

postscreen_dnsbl_whitelist_threshold = -2
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_sites =
        zen.spamhaus.org*3
        hostkarma.junkemailfilter.com=127.0.0.2*2
        rep.mailspike.net=127.0.0.[10;11]*2
        b.barracudacentral.org*2
        rep.mailspike.net=127.0.0.[12;13]
        dnsbl.sorbs.net=127.0.0.[6;10]
        db.wpbl.info=127.0.0.2
        bl.spamcop.net
        ix.dnsbl.manitu.net
        psbl.surriel.com
        dnsbl.inps.de
        ubl.unsubscore.com
        hostkarma.junkemailfilter.com=127.0.0.1*-2
        list.dnswl.org=127.0.[0..255].2*-1
        list.dnswl.org=127.0.[0..255].3*-2
        rep.mailspike.net=127.0.0.[18;19]*-1
        rep.mailspike.net=127.0.0.20*-2



--
View this message in context: http://postfix.1071664.n5.nabble.com/Postscreen-Konfiguration-tp91499p91549.html
Sent from the Germany Postfixbuch mailing list archive at Nabble.com.


From mike_ebenbeck at yahoo.de  Thu Jul 27 11:13:41 2017
From: mike_ebenbeck at yahoo.de (Waschl)
Date: Thu, 27 Jul 2017 02:13:41 -0700 (MST)
Subject: check_recipient_access seltsame Verhaltensweise
In-Reply-To: <1501141156546-91548.post@n5.nabble.com>
References: <1501141156546-91548.post@n5.nabble.com>
Message-ID: <1501146821096-91551.post@n5.nabble.com>

Habe herausgefunden, das es an der Groß- und Kleinschreibung liegt. Die
address probe wird komplett kleingeschrieben durchgeführt, während die
Mailadresse egentlich zwei Großbuchstaben enthält.



--
View this message in context: http://postfix.1071664.n5.nabble.com/check-recipient-access-seltsame-Verhaltensweise-tp91548p91551.html
Sent from the Germany Postfixbuch mailing list archive at Nabble.com.


From Ralf.Hildebrandt at charite.de  Thu Jul 27 11:17:36 2017
From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt)
Date: Thu, 27 Jul 2017 11:17:36 +0200
Subject: check_recipient_access seltsame Verhaltensweise
In-Reply-To: <1501146821096-91551.post@n5.nabble.com>
References: <1501141156546-91548.post@n5.nabble.com>
 <1501146821096-91551.post@n5.nabble.com>
Message-ID: <20170727091735.yr6bv65f35rwiysz@charite.de>

* Waschl <mike_ebenbeck at yahoo.de>:
> Habe herausgefunden, das es an der Groß- und Kleinschreibung liegt. Die
> address probe wird komplett kleingeschrieben durchgeführt, während die
> Mailadresse egentlich zwei Großbuchstaben enthält.

Das habe ich gerade beim Ansehen übersehen...
-- 
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 | https://www.charite.de
	    


From mike_ebenbeck at yahoo.de  Thu Jul 27 11:21:21 2017
From: mike_ebenbeck at yahoo.de (Waschl)
Date: Thu, 27 Jul 2017 02:21:21 -0700 (MST)
Subject: check_recipient_access seltsame Verhaltensweise
In-Reply-To: <20170727091735.yr6bv65f35rwiysz@charite.de>
References: <1501141156546-91548.post@n5.nabble.com>
 <1501146821096-91551.post@n5.nabble.com>
 <20170727091735.yr6bv65f35rwiysz@charite.de>
Message-ID: <1501147281731-91554.post@n5.nabble.com>

Habe das ganze gegengeprüft und an den Empfänger eine Mail geschickt, wobei
ich die Adresse komplett klein geschrieben habe. Ging eindwandfrei durch.
Postfix 2.11 hatte das noch nicht. Hier hatte ich nie Probleme.



--
View this message in context: http://postfix.1071664.n5.nabble.com/check-recipient-access-seltsame-Verhaltensweise-tp91548p91554.html
Sent from the Germany Postfixbuch mailing list archive at Nabble.com.


From Ralf.Hildebrandt at charite.de  Thu Jul 27 11:57:48 2017
From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt)
Date: Thu, 27 Jul 2017 11:57:48 +0200
Subject: check_recipient_access seltsame Verhaltensweise
In-Reply-To: <1501147281731-91554.post@n5.nabble.com>
References: <1501141156546-91548.post@n5.nabble.com>
 <1501146821096-91551.post@n5.nabble.com>
 <20170727091735.yr6bv65f35rwiysz@charite.de>
 <1501147281731-91554.post@n5.nabble.com>
Message-ID: <20170727095748.pgypl6yaidun4wtt@charite.de>

* Waschl <mike_ebenbeck at yahoo.de>:
> Habe das ganze gegengeprüft und an den Empfänger eine Mail geschickt, wobei
> ich die Adresse komplett klein geschrieben habe. Ging eindwandfrei durch.
> Postfix 2.11 hatte das noch nicht. Hier hatte ich nie Probleme.

Mit sowas würde ich mal die postfix-users Liste fragen.

-- 
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 | https://www.charite.de
	    


From daniel at oc.yados.de  Fri Jul 28 12:00:32 2017
From: daniel at oc.yados.de (daniel)
Date: Fri, 28 Jul 2017 12:00:32 +0200
Subject: bounce-Mails
Message-ID: <c2529e53245b9fa87fccffad9b6740eb@oc.yados.de>

Hallo,

ich bekomme keine bounce-Mails. Die Mail nimmt folgenden Weg:

1. server1 verschickt Mail an nicht existierenden Empfänger direkt, mit 
dem Absender "service at example.org" wobei example.org auf server3 liegt
2. smtp-Server des Empfängers antwortet "gibts hier nicht", schickt 
Antwort an "service at example.org"
3. Server3 verantwortlich für example.org, ist ein Exchange, leitet alle 
Mails an "service at postfach-auf-server1" weiter
4. Server1 schickt die Mail wieder an Server3 weil er nicht 
verantwortlich dafür ist ....

Normales Verhalten, die Log davon ist weiter unten angehängt.

Ich hatte es kurz so gelöst, dass ich example.org in mydestinations auf 
server1 aufgenommen habe. Leider ist es so, dass Benutzer von server1 
auch Mails an Benutzer von Server3 schicken, diese kommen dann alle 
zurück als nicht zustellbar, da es diese Benutzer auf server1 nicht 
gibt.

Gibt es dafür eine Lösung?

OS von server1 ist ein Debian 9 mit Postfix 3.1.4.

Jetzt die Logs:

root at server1 /var/log # grep 8D18B200413 mail*
mail.info:Jul 25 11:20:33 server postfix/pickup[13038]: 8D18B200413: 
uid=33 from=<service at example.org>
mail.info:Jul 25 11:20:33 server postfix/cleanup[2779]: 8D18B200413: 
message-id=<edd2640369be12f2bcbfa463eb6db8da at example.org>
mail.info:Jul 25 11:20:33 server postfix/qmgr[4088]: 8D18B200413: 
from=<service at example.org>, size=612, nrcpt=1 (queue active)
mail.info:Jul 25 11:20:37 server postfix/smtp[2781]: 8D18B200413: 
to=<dasisteintestsorrypeer at mailbox.org>, 
relay=mx1.mailbox.org[80.241.60.212]:25, delay=3.8, 
delays=0.26/0/0.36/3.2, dsn=5.1.1, status=bounced (host 
mx1.mailbox.org[80.241.60.212] said: 577 5.1.1 
<dasisteintestsorrypeer at mailbox.org>: Recipient address rejected: 
undeliverable address: host imap.mailbox.org[80.241.60.199] said: 550 
5.1.1 <dasisteintestsorrypeer at mailbox.org> User doesn't exist: 
dasisteintestsorrypeer at mailbox.org (in reply to RCPT TO command) (in 
reply to RCPT TO command))
mail.info:Jul 25 11:20:37 server postfix/bounce[3098]: 8D18B200413: 
sender non-delivery notification: 4D667200417
mail.info:Jul 25 11:20:37 server postfix/qmgr[4088]: 8D18B200413: 
removed
mail.log:Jul 25 11:20:33 server postfix/pickup[13038]: 8D18B200413: 
uid=33 from=<service at example.org>
mail.log:Jul 25 11:20:33 server postfix/cleanup[2779]: 8D18B200413: 
message-id=<edd2640369be12f2bcbfa463eb6db8da at example.org>
mail.log:Jul 25 11:20:33 server postfix/qmgr[4088]: 8D18B200413: 
from=<service at example.org>, size=612, nrcpt=1 (queue active)
mail.log:Jul 25 11:20:37 server postfix/smtp[2781]: 8D18B200413: 
to=<dasisteintestsorrypeer at mailbox.org>, 
relay=mx1.mailbox.org[80.241.60.212]:25, delay=3.8, 
delays=0.26/0/0.36/3.2, dsn=5.1.1, status=bounced (host 
mx1.mailbox.org[80.241.60.212] said: 577 5.1.1 
<dasisteintestsorrypeer at mailbox.org>: Recipient address rejected: 
undeliverable address: host imap.mailbox.org[80.241.60.199] said: 550 
5.1.1 <dasisteintestsorrypeer at mailbox.org> User doesn't exist: 
dasisteintestsorrypeer at mailbox.org (in reply to RCPT TO command) (in 
reply to RCPT TO command))
mail.log:Jul 25 11:20:37 server postfix/bounce[3098]: 8D18B200413: 
sender non-delivery notification: 4D667200417
mail.log:Jul 25 11:20:37 server postfix/qmgr[4088]: 8D18B200413: removed
root at server1 /var/log #
root at rigel-1 /var/log # grep 4D667200417 mail.l*
mail.log:Jul 25 11:20:37 rigel-1 postfix/cleanup[2779]: 4D667200417: 
message-id=<20170725092037.4D667200417 at oc.example.org>
mail.log:Jul 25 11:20:37 rigel-1 postfix/bounce[3098]: 8D18B200413: 
sender non-delivery notification: 4D667200417
mail.log:Jul 25 11:20:37 rigel-1 postfix/qmgr[4088]: 4D667200417: 
from=<>, size=3190, nrcpt=1 (queue active)
mail.log:Jul 25 11:20:38 rigel-1 postfix/smtp[2785]: 4D667200417: 
to=<service at example.org>, relay=server3.example.org[80.00.00.00]:25, 
delay=0.95, delays=0.08/0/0.69/0.18, dsn=2.0.0, status=sent (250 2.0.0 
Ok: queued as DDCBCA004F)
mail.log:Jul 25 11:20:38 rigel-1 postfix/qmgr[4088]: 4D667200417: 
removed
root at rigel-1 /var/log #

root at server1 /var/log # postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
compatibility_level = 2
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = all
mailbox_size_limit = 0
message_size_limit = 400480000
mydestination = $myhostname, server1.example.org, server1, 
localhost.localdomain, localhost
myhostname = oc.example.org
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_hostname
smtpd_recipient_restrictions = permit_sasl_authenticated, 
permit_mynetworks, reject_unauth_destination
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, 
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = reject_unknown_address
smtpd_tls_cert_file = /etc/ssl/private/linux_cert_und_ca.pem
smtpd_tls_key_file = /etc/ssl/private/oc.example.org.key
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
root at server1 /var/log #


Daniel


From ckubu at so36.net  Sat Jul 29 12:21:46 2017
From: ckubu at so36.net (ckubu)
Date: Sat, 29 Jul 2017 12:21:46 +0200
Subject: Liste sicherer Mailserver
Message-ID: <6a4396af-7ab6-1363-cae0-0796ae943d0d@so36.net>

Hallo,

Ich bin ein kleines Unternehmen, betreibe u.a. auch Mailserver mit ein
paar wenigen k Postfächern.

Zumindest einige der Speedport Telekom Router haben voreingestellt eine
Option "Liste der sicheren E-Mail-Server verwenden".

In der Voreinstellung können meine Kunden keine E-Mails versenden. Sie
müssen also den Haken vor dieser Option wegmachen, was suggeriert, dass
sie nun "unsicher" seien. Beides ist für mich als (Klein-)Unternehmen
schlecht.

Ich würde dagegen gerne vorgehen und frage mich, ob es nicht vielleicht
schon andere in einer ähnlichen Situation gibt, die dahingehend bereits
tätig sind. Eine (zugegebenermaßen kurze) Internetrecherche erbrachte
keine Ergebnisse.

Grüße
Christoph


From sd at schnied.net  Sat Jul 29 15:27:50 2017
From: sd at schnied.net (Stefan Dorn)
Date: Sat, 29 Jul 2017 15:27:50 +0200
Subject: Liste sicherer Mailserver
In-Reply-To: <6a4396af-7ab6-1363-cae0-0796ae943d0d@so36.net>
References: <6a4396af-7ab6-1363-cae0-0796ae943d0d@so36.net>
Message-ID: <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>

Hallo Christoph,

On 07/29/2017 12:21 PM, ckubu wrote:
> Zumindest einige der Speedport Telekom Router haben voreingestellt eine
> Option "Liste der sicheren E-Mail-Server verwenden".
> 
> In der Voreinstellung können meine Kunden keine E-Mails versenden. Sie
> müssen also den Haken vor dieser Option wegmachen, was suggeriert, dass
> sie nun "unsicher" seien. Beides ist für mich als (Klein-)Unternehmen
> schlecht.
> 
> Ich würde dagegen gerne vorgehen und frage mich, ob es nicht vielleicht
> schon andere in einer ähnlichen Situation gibt, die dahingehend bereits
> tätig sind. Eine (zugegebenermaßen kurze) Internetrecherche erbrachte
> keine Ergebnisse.

das Problem kenne ich. (Und viele andere bestimmt auch.)
Spätestens seit die Telekom die Zwangsumstellung auf IP basierte 
Anschlüsse macht, häufen sich bei uns die Anfragen. Wenn sich ein Kunde 
meldet und sagt, dass er keine Mails mehr verschicken kann, ist 
mittlerweile die erste Frage "'nen neuen Speedport von der Telekom 
bekommen?"
Hier sind schon einige Stunden an Support dafür verbrannt worden. 
(Support, den eigentlich die Telekom hätte erbringen müssen. Aber wer 
verweist seine zufriedenen Kunden freiwillig an den Telekom Support?)

Ich habe mich auch schon mit der Telekom "behängt" und nachgefragt, wie 
man denn auf diese Liste kommen kann. Allerdings konnte ich nicht sehr 
weit in die Tiefen des Konzerns vordringen. Unzählige, lange Emails und 
Telefonate sind schon an der "1st Level Wall" abgeprallt. Spätestens 
wenn ich gesagt habe, dass es nicht um meinen Anschluss o.ä. geht, 
sondern es sich um ein Problem vieler anderer handelt.

Ein etwas versierterer Mitarbeiter hat mir am Telefon erzählt, dass 
diese Liste angeblich fest in der Firmware verdrahtet ist und ein Update 
sowieso nur mit einem Firmware Update möglich wäre. Ob diese Info stimmt 
oder noch aktuell ist, kann ich nicht beurteilen.

Posteo hat es wohl irgendwie geschafft, auf diese Liste zu kommen. Eine 
Anfrage meinerseits per Email, ob sie mir einen Ansprechpartner bei der 
Telekom nennen können, blieb leider unbeantwortet.

Vom Prinzip her finde ich die Idee erstmal nicht sooo schlecht. So 
werden sicher ein paar Spam Trojaner und ioT Geräte vom Versenden von 
Spam etc. abgehalten. Die Umsetzung ist halt "so naja" und geht bestimmt 
besser.

Gruß
Stefan




From ml at andreas-ziegler.de  Sat Jul 29 17:32:28 2017
From: ml at andreas-ziegler.de (Andreas Ziegler)
Date: Sat, 29 Jul 2017 17:32:28 +0200
Subject: Liste sicherer Mailserver
In-Reply-To: <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>
References: <6a4396af-7ab6-1363-cae0-0796ae943d0d@so36.net>
 <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>
Message-ID: <ee2b5191-3aab-ded9-0d80-9e901df6a41b@andreas-ziegler.de>

Hallo zusammen,

auch wir haben dieses Problem natürlich.
Das schlimmste ist meiner Meinung nach, dass auch Port 587/submission
betroffen ist.
Weshalb? Technisch sehe ich keinen Grund dafür.

Ich sehe hier daher insgesamt betrachtet eher absichtliche Behinderung
des Wettbewerbs als hehre Ziele bei der Telekom...

Grüße

Andreas


Stefan Dorn schrieb am 29.07.2017 um 15:27:
> Hallo Christoph,
> 
> On 07/29/2017 12:21 PM, ckubu wrote:
>> Zumindest einige der Speedport Telekom Router haben voreingestellt eine
>> Option "Liste der sicheren E-Mail-Server verwenden".
>>
>> In der Voreinstellung können meine Kunden keine E-Mails versenden. Sie
>> müssen also den Haken vor dieser Option wegmachen, was suggeriert, dass
>> sie nun "unsicher" seien. Beides ist für mich als (Klein-)Unternehmen
>> schlecht.
>>
>> Ich würde dagegen gerne vorgehen und frage mich, ob es nicht vielleicht
>> schon andere in einer ähnlichen Situation gibt, die dahingehend bereits
>> tätig sind. Eine (zugegebenermaßen kurze) Internetrecherche erbrachte
>> keine Ergebnisse.
> 
> das Problem kenne ich. (Und viele andere bestimmt auch.)
> Spätestens seit die Telekom die Zwangsumstellung auf IP basierte
> Anschlüsse macht, häufen sich bei uns die Anfragen. Wenn sich ein Kunde
> meldet und sagt, dass er keine Mails mehr verschicken kann, ist
> mittlerweile die erste Frage "'nen neuen Speedport von der Telekom
> bekommen?"
> Hier sind schon einige Stunden an Support dafür verbrannt worden.
> (Support, den eigentlich die Telekom hätte erbringen müssen. Aber wer
> verweist seine zufriedenen Kunden freiwillig an den Telekom Support?)
> 
> Ich habe mich auch schon mit der Telekom "behängt" und nachgefragt, wie
> man denn auf diese Liste kommen kann. Allerdings konnte ich nicht sehr
> weit in die Tiefen des Konzerns vordringen. Unzählige, lange Emails und
> Telefonate sind schon an der "1st Level Wall" abgeprallt. Spätestens
> wenn ich gesagt habe, dass es nicht um meinen Anschluss o.ä. geht,
> sondern es sich um ein Problem vieler anderer handelt.
> 
> Ein etwas versierterer Mitarbeiter hat mir am Telefon erzählt, dass
> diese Liste angeblich fest in der Firmware verdrahtet ist und ein Update
> sowieso nur mit einem Firmware Update möglich wäre. Ob diese Info stimmt
> oder noch aktuell ist, kann ich nicht beurteilen.
> 
> Posteo hat es wohl irgendwie geschafft, auf diese Liste zu kommen. Eine
> Anfrage meinerseits per Email, ob sie mir einen Ansprechpartner bei der
> Telekom nennen können, blieb leider unbeantwortet.
> 
> Vom Prinzip her finde ich die Idee erstmal nicht sooo schlecht. So
> werden sicher ein paar Spam Trojaner und ioT Geräte vom Versenden von
> Spam etc. abgehalten. Die Umsetzung ist halt "so naja" und geht bestimmt
> besser.
> 
> Gruß
> Stefan



From driessen at fblan.de  Sat Jul 29 17:54:29 2017
From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=)
Date: Sat, 29 Jul 2017 17:54:29 +0200
Subject: AW: Liste sicherer Mailserver
In-Reply-To: <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>
References: <6a4396af-7ab6-1363-cae0-0796ae943d0d@so36.net>
 <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>
Message-ID: <001901d30882$f6f2e300$e4d8a900$@fblan.de>

Im Auftrag von Stefan Dorn
> 
> Vom Prinzip her finde ich die Idee erstmal nicht sooo schlecht. So
> werden sicher ein paar Spam Trojaner und ioT Geräte vom Versenden von
> Spam etc. abgehalten. Die Umsetzung ist halt "so naja" und geht bestimmt
> besser.
> 
> Gruß
> Stefan

Grundsätzlich ist das eigentlich ein Verstoß gegen den Diskriminierungsfreien Internetzugang 
Für Botnetze usw. reicht es schon mal den Port 25 an den Dialinanschlüssen zu  schließen. 
die Telekom suggeriert da eine falsche Sicherheit zumal man auf den Telekom /T-Onliene servern keine aktive Spamfilter erwarten darf. 
Zumindest kommt bei meinen Kunden gerade über die T-Online und Telekom Mailadressen jede Menge phishing, spam  und auch alles andere Getier.

das mit den Speedportroutern trägt lediglich zur Verunsicherung der Kunden bei 
ähnlich wie DE-MAIL da ist es irgendwie ruhig drum geworden weil so mancher wurde sich der rechtlichen Tragweite bewusst die er mit der Nutzung eines solchen Kontos gegenüber den Behörden eingeht.  

   


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 hm0 at gmx.net  Sat Jul 29 17:55:33 2017
From: hm0 at gmx.net (Heiner Mueller)
Date: Sat, 29 Jul 2017 17:55:33 +0200
Subject: Aw: Re: Liste sicherer Mailserver
In-Reply-To: <ee2b5191-3aab-ded9-0d80-9e901df6a41b@andreas-ziegler.de>
References: <6a4396af-7ab6-1363-cae0-0796ae943d0d@so36.net>
 <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>
 <ee2b5191-3aab-ded9-0d80-9e901df6a41b@andreas-ziegler.de>
Message-ID: <trinity-b77004db-334d-4702-8b0c-2726446a209c-1501343733298@3capp-gmx-bs19>

Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20170729/ed3c9cf1/attachment.htm>

From buettnerp at web.de  Sat Jul 29 19:16:11 2017
From: buettnerp at web.de (Peter Buettner)
Date: Sat, 29 Jul 2017 19:16:11 +0200
Subject: Liste sicherer Mailserver
In-Reply-To: <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>
References: <6a4396af-7ab6-1363-cae0-0796ae943d0d@so36.net>
 <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>
Message-ID: <597CC2DB.5070402@web.de>

..... das ist nicht nur ein hiesiges Problem. Es taucht bei allen
Routern von regierungsgesteuerten Providern in Europa auf.

Meine Meinung dazu:
Ziel ist es, den unbedarften Endanwender dazu zu bewegen, seine
Kommunikation über die aufgeführten Provider abzuwickeln, damit die
Regierungen über diese Provider die Kommunikation ihrer Bürger
belauschen können.
Die Provider auf dieser Liste sind also keineswegs die "Guten". Es ist
deshalb auch nicht erstrebenswert auf diese List zu gelangen.
Da hilft nur gnadenlose Aufklärung. Entweder auf "neutrale" Router
umsteigen oder das "Häkchen" entfernen.
Was Posteo betrifft: Es ist weiterhin meine Meinung, das sie  mit den
Wölfen heulen, um im Geschäft zu bleiben. Sie rühmen sich auch, als
Erste das Zertifikat des BSI erhalten zu haben. Ich bin  der
Überzeugung, daß Posteo einen Deal mit den Vertretern der dunklen Seite
der Macht im Innenministerium eingegangen ist, um auf die Routerliste zu
kommen. Damit haben sie sich selbst ein Bein gestellt.

Gruß
Peter Büttner


Am 29.07.2017 um 15:27 schrieb Stefan Dorn:
> Hallo Christoph,
> 
> On 07/29/2017 12:21 PM, ckubu wrote:
>> Zumindest einige der Speedport Telekom Router haben voreingestellt eine
>> Option "Liste der sicheren E-Mail-Server verwenden".
>>
>> In der Voreinstellung können meine Kunden keine E-Mails versenden. Sie
>> müssen also den Haken vor dieser Option wegmachen, was suggeriert, dass
>> sie nun "unsicher" seien. Beides ist für mich als (Klein-)Unternehmen
>> schlecht.
>>
>> Ich würde dagegen gerne vorgehen und frage mich, ob es nicht vielleicht
>> schon andere in einer ähnlichen Situation gibt, die dahingehend bereits
>> tätig sind. Eine (zugegebenermaßen kurze) Internetrecherche erbrachte
>> keine Ergebnisse.
> 
> das Problem kenne ich. (Und viele andere bestimmt auch.)
> Spätestens seit die Telekom die Zwangsumstellung auf IP basierte
> Anschlüsse macht, häufen sich bei uns die Anfragen. Wenn sich ein Kunde
> meldet und sagt, dass er keine Mails mehr verschicken kann, ist
> mittlerweile die erste Frage "'nen neuen Speedport von der Telekom
> bekommen?"
> Hier sind schon einige Stunden an Support dafür verbrannt worden.
> (Support, den eigentlich die Telekom hätte erbringen müssen. Aber wer
> verweist seine zufriedenen Kunden freiwillig an den Telekom Support?)
> 
> Ich habe mich auch schon mit der Telekom "behängt" und nachgefragt, wie
> man denn auf diese Liste kommen kann. Allerdings konnte ich nicht sehr
> weit in die Tiefen des Konzerns vordringen. Unzählige, lange Emails und
> Telefonate sind schon an der "1st Level Wall" abgeprallt. Spätestens
> wenn ich gesagt habe, dass es nicht um meinen Anschluss o.ä. geht,
> sondern es sich um ein Problem vieler anderer handelt.
> 
> Ein etwas versierterer Mitarbeiter hat mir am Telefon erzählt, dass
> diese Liste angeblich fest in der Firmware verdrahtet ist und ein Update
> sowieso nur mit einem Firmware Update möglich wäre. Ob diese Info stimmt
> oder noch aktuell ist, kann ich nicht beurteilen.
> 
> Posteo hat es wohl irgendwie geschafft, auf diese Liste zu kommen. Eine
> Anfrage meinerseits per Email, ob sie mir einen Ansprechpartner bei der
> Telekom nennen können, blieb leider unbeantwortet.
> 
> Vom Prinzip her finde ich die Idee erstmal nicht sooo schlecht. So
> werden sicher ein paar Spam Trojaner und ioT Geräte vom Versenden von
> Spam etc. abgehalten. Die Umsetzung ist halt "so naja" und geht bestimmt
> besser.
> 
> Gruß
> Stefan
> 
> 



From p.heinlein at heinlein-support.de  Sat Jul 29 21:23:25 2017
From: p.heinlein at heinlein-support.de (Peer Heinlein)
Date: Sat, 29 Jul 2017 21:23:25 +0200
Subject: Liste sicherer Mailserver
In-Reply-To: <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>
References: <6a4396af-7ab6-1363-cae0-0796ae943d0d@so36.net>
 <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>
Message-ID: <053c4096-3482-3885-a242-bea82a3d6b72@heinlein-support.de>

Am 29.07.2017 um 15:27 schrieb Stefan Dorn:


> Ein etwas versierterer Mitarbeiter hat mir am Telefon erzählt, dass
> diese Liste angeblich fest in der Firmware verdrahtet ist und ein Update
> sowieso nur mit einem Firmware Update möglich wäre. Ob diese Info stimmt
> oder noch aktuell ist, kann ich nicht beurteilen.

Stimmt nicht.

> Posteo hat es wohl irgendwie geschafft, auf diese Liste zu kommen. Eine
> Anfrage meinerseits per Email, ob sie mir einen Ansprechpartner bei der
> Telekom nennen können, blieb leider unbeantwortet.

Ich schicke die nächsten Tage den Ansprechpartner dafür auf die Liste,
den habe ich und mit dem kann man normal reden.

Aus bestimmten Gründen will ich das dieses Wochenende noch nicht machen.
Bitte kurz Geduld.

Peer


From ml at andreas-ziegler.de  Sat Jul 29 23:42:28 2017
From: ml at andreas-ziegler.de (Andreas Ziegler)
Date: Sat, 29 Jul 2017 23:42:28 +0200
Subject: Liste sicherer Mailserver
In-Reply-To: <053c4096-3482-3885-a242-bea82a3d6b72@heinlein-support.de>
References: <6a4396af-7ab6-1363-cae0-0796ae943d0d@so36.net>
 <9ecd6786-1e8f-db4f-1b9d-520543df92ca@schnied.net>
 <053c4096-3482-3885-a242-bea82a3d6b72@heinlein-support.de>
Message-ID: <f13b96e5-5fb4-dd6b-d5ad-c7e44d5d2b04@andreas-ziegler.de>


> Ich schicke die nächsten Tage den Ansprechpartner dafür auf die Liste,
> den habe ich und mit dem kann man normal reden.

der nützt aber wohl auch nur denen, die zumindest mittelgroß sind - die
Telekom wird vermutlich kaum jede Werbeagentur mit 200 Postfächern auf
diese Liste setzen...

Siehst du das Problem nicht auch, dass hier sogar 587 gesperrt wird?

Gruß

Andreas


From r.wagner at licoho.de  Sun Jul 30 23:13:14 2017
From: r.wagner at licoho.de (Ronny Wagner)
Date: Sun, 30 Jul 2017 21:13:14 +0000
Subject: AW: OT: Amavis Notification-Messages mit S/MIME signieren
In-Reply-To: <1500294499.11002.6.camel@mpifr-bonn.mpg.de>
References: <1500016122.18737.6.camel@mpifr-bonn.mpg.de>
 <d571b6d7-5275-8e83-154b-da07042bcde7@sys4.de>
 <1500294499.11002.6.camel@mpifr-bonn.mpg.de>
Message-ID: <8f2b7ce95b164aa087290c3befe5d494@licoho.de>

Hallo Jan,

darf ich mal nachfragen, wie du das "Problem" mit der signingtable.cdb gelöst hast?

Beschäfte mich aktuell auch damit und hänge hier gerade fest, beim ersten ausführen wird nichts erstellt und somit meckert das Programm verständlicherweise die fehlende Datei an.

Wäre top wenn du mir hier einen Rat hättest.

Vielen Dank
Ronny

-----Ursprüngliche Nachricht-----
Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Jan Behrend
Gesendet: Montag, 17. Juli 2017 14:28
An: postfixbuch-users at listen.jpberlin.de
Betreff: Re: OT: Amavis Notification-Messages mit S/MIME signieren

Hallo p at rick,

On Fri, 2017-07-14 at 09:41 +0200, Patrick Ben Koetter wrote:
> Du kannst mit notification_method in amavis eine Route festlegen, über
> die es die Nachricht z.B. an einen dedizierten smtp-Listener sendet.
> Dort kann Christians sigh-Milter die Nachricht S/MIME-signieren.

Top!  Implementiert und funktioniert!

Vielen Dank und LG von Jan

--
MAX-PLANCK-INSTITUT fuer Radioastronomie
Jan Behrend - Rechenzentrum
----------------------------------------
Auf dem Huegel 69, D-53121 Bonn
Tel: +49 (228) 525 359
http://www.mpifr-bonn.mpg.de

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : F64B72EDA591C786_r.wagner at licoho.de.asc
Dateityp    : application/octet-stream
Dateigröße  : 3961 bytes
Beschreibung: F64B72EDA591C786_r.wagner at licoho.de.asc
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20170730/47eeb65a/attachment.obj>