catchall, bounce messages, ...

[Walter H.]

Hallo,

habe eine etwas kompliziertere Umgebung zu Hause;
3 virtuelle Maschinen als Mailserver

server1: Postfix mit Cyrus als Mail-Store (Zugriff über IMAP)
server2: Postfix als ausgehender Mail-Server
server3: Postfix mit Fetchmail als eingehender Mail-Server

---[ server1 ]---
server1 ist auf den Clients als SMTP und als IMAP Server konfiguriert;

/etc/postfix/transport beinhaltet das

server1.domain.local lmtp:unix:/var/lib/imap/socket/lmtp
domain.local   smtp:server1.domain.local
*   smtp:server2.domain.local

entsprechend im main.cf:
transport_maps = hash:/etc/postfix/transport
bzw.
smtp_generic_maps = hash:/etc/postfix/generic (hier werden interne 
adressen wie z.B. root@server1.domain.local in gültige von der weiten 
Welt erreichbare Mail-adressen umgewandelt)

virtual_alias_maps = hash:/etc/postfix/virtual
(hier werden interne adressen wie z.B.  root@server1.domain.local einem 
ordner wie z.B.  name+sub zugeordnet und auch ein catchall derart
@domain.local bzw. @server1.domain.local einem ordner wie z.B. 
name+sub.catchall zugeordnet bzw. realisiert)


relayhost ist nicht gesetzt;

die anderen beiden haben im main.cf
den relayhost mit [server1.domain.local]:25 gesetzt

---[ server2 ]---
server2 ist der ausgehende Mail-Server

/etc/postfix/dependent_relayhost

@maildomain   smtpserver:port
(web-hoster, gmx, isp, ...)

entsprechend im main.cf
sender_dependent_relayhost_maps = hash:/etc/postfix/dependent_relayhost
bzw.
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
(ordnet den einzelnen smtp-servern jeweils userid+password zu)

mein isp macht es kompliziert, daher auch das
smtp_sender_dependent_authentication = yes
(sasl_passwd entsprechend umfangreicher)

---[ server3 ]---
und jetzt der eigentliche Teil: server3 als eingehender Mail-Server

hier im main.cf

local_recipient_maps =
luser_relay = catchall@domain.local

notify_classes = bounce, 2bounce, delay, protocol, resource, software
bounce_notice_recipient = catchall@domain.local
2bounce_notice_recipient = catchall@domain.local
delay_notice_recipient = catchall@domain.local

und weiters

smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_unknown_hostname, 
reject_non_fqdn_helo_hostname

smtpd_client_restrictions = permit_mynetworks, reject
smtpd_etrn_restrictions = permit_mynetworks, reject
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_recipient_restrictions = permit_mynetworks, 
permit_sasl_authenticated, reject_unauth_destination, permit

smtpd_end_of_data_restrictions =
smtpd_restriction_classes =
smtpd_reject_unlisted_sender = yes
smtpd_reject_unlisted_recipient = yes
unknown_address_reject_code = 550
body_checks = pcre:/etc/postfix/body_chks.pcre
body_checks_size_limit = 1048576
header_checks = regexp:/etc/postfix/hdr_chks.regex, 
pcre:/etc/postfix/hdr_chks.pcre

header_checks_size_limit = 131072

und in fetchmailrc z.B.

set daemon 224
set postmaster "r...@waldinet.home"
set properties ""
set bouncemail
set no spambounce
set softbounce

defaults
   smtphost server3.domain.local

poll pop.gmx.net with proto POP3
 user ## there with password "password" is name+GMX


hier hätte ich gerne dass egal welche bouncemail auch immer generiert 
wird, diese an direkt an z.B. catchall@domain.local geht und
nicht retour via server2 wo es entweder versandet oder mit folgender 
Zeile in /etc/postfix/dependent_relayhost

<>   server1.domain.local:25
eine Mailloop generiert und diese bouncemail beim postmaster landet ...

alle 3 server sind ein centos 6.x und haben postfix 2.6.6

bitte um Hinweise ob ich es richtig gemacht habe, und wenn nein, wie es 
geht ...


Danke,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: SRS mit Postfix

[Walter H.]

On 15.06.2015 13:51, Marco Dickert wrote:

Moin,

ich möchte gern Sender-Rewriting mit Postfix realisieren, weil ich für einige 
Domains keine Postfächer, sondern nur Weiterleitungen (meist zu Freemailern) 
eingerichtet habe. Wenn der ursprüngliche Sender einen SPF-Record hat, landen 
diese weitergeleiteten Mails oftmals im Spam-Ordner der Empfänger. Bekannte 
Lösung ist ja das Umschreiben der Envelope-Adresse. Ich habe dazu diesen 
Artikel gefunden:
   
http://christophfischer.com/linux/15-mailserver/56-sender-rewriting-scheme-srs-fuer-postfix-unter-debian

Wird das von euch zur Nachahmung empfohlen, oder gibt es mittlerweile "bessere" 
Lösungen (oder sogar ein Debian-Paket)?

Viele Grüße,
---
Marco Dickert
ma...@misterunknown.de
http://misterunknown.de

Hallo,

könntest Du das eventuell genauer spezifizieren, wo Du dies einsetzen 
wolltest?


zum Thema SPF: vermeide irgendwelche Weiterleitungen, wo das einen 
Einfluß hat ...


eventuell genügt Dir ja einfach das 'generic'
(smtp_generic_maps = hash:/etc/postfix/generic)
hat z.B. folgenden Inhalt

email1.oldemail1.new
email2.oldemail2.new
...
hier sollte email#.new eine Mailadresse sein, wo der Server lt. SPF auch 
dazu befugt ist für dessen Domain zu senden;


Grüße,
Walter





smime.p7s
Description: S/MIME Cryptographic Signature

Re: SRS mit Postfix

[Walter H.]

Hallo,

On Tue, June 16, 2015 09:55, Marco Dickert wrote:
> Guten Morgen,
>
> 15. Juni 2015 22:25 Uhr, "Walter H."  schrieb:
>> könntest Du das eventuell genauer spezifizieren, wo Du dies einsetzen
>> wolltest?
>
> Auf meinem Server gibt es beispielsweise die Domain "bierpalme.de", aber
> kein Postfach dafür. Mails, die an m...@bierpalme.de gesendet werden,
> leite ich an einen bestehenden GMail-Account weiter. Blöderweise landen
> dort einige Mails im Spam-Filter, und zwar dann, wenn der ursprüngliche
> Sender einen SPF-Record hat. Deshalb will ich SRS-Adressen verwenden.

was haltest Du von der Variante, da die Mail ja schon mal angenommen wurde
(von Deinem Mailserver) einfach eine neue Mail zu genieren - mit Absender
m...@bierpalme.de (um bei Deinem unorthodoxen Beispiel zu bleiben) und die
ursprüngliche Mail unverändert als Anhang bei dieser Mail anzuhängen?

>> zum Thema SPF: vermeide irgendwelche Weiterleitungen, wo das einen
>> Einfluß hat ...
>
> Das ist eine Frage des Aufwands. Entweder ich richte jetzt echte
> Postfächer ein, oder ich versuche das per SRS sauber zu bekommen. Ich
> wollte mich für letzteres entscheiden.

auch das hat einen Pferdefuß;

Beispiel: mist...@nix.at schickt eine Mail an m...@bierpalme.de, dann ist
im Normalfall sowohl im To (Mail-Header) als auch im RCPT TO
(Mail-Envelope)
bzw. im From (Mail-Header) als auch im MAIL FROM (Mail-Envelope) jeweils
die selbe Mail-Adresse; würdest Du jetzt auf Deinem Mailserver beim
weiterleiten, den Mail-Header unberührt lassen, und nur dafür sorgen, daß
beim Empfang durch GMail im Mail-Envelope m...@bierpalme.de steht um es
nicht im SPAM-Ordner zu bringen, riskierst Du erst recht, daß es im
SPAM-Ordner dort landet, weil ein Nichtzusammenpassen von Mail-Envelope
und Mail-Header grundsätzlich verdächtig ist;
passt Du hingegen auch das From im Mail-Header an, solltest den Originalwert
in einem anderen Feld z.B. X-Old-From ablegen, weil Du sonst am
GMail-Konto nicht siehst, von wem die Mail jetzt wirklich ist; und weiters
zerstörst Du eine eiwaig vorhandene DKIM; sprich die kommt garantiert
ungültig an, und schickt dieses Mail erst recht in den SPAM-Ordner;

>> eventuell genügt Dir ja einfach das 'generic'
>> (smtp_generic_maps = hash:/etc/postfix/generic)
>
> Im Normalfall sollte das zwar funktionieren, allerdings hätte ich dann das
> Problem, dass Bounce-Mails wieder bei mir ankommen und nicht beim
> ursprünglichen Sender. Das würde ich gern vermeiden, da das nicht
> RFC-konform ist.

da wirst Du nicht herum kommen ..., daß Du die Bounce-Mails und nicht der
ursprüngliche Sender empfängt, genau deswegen: "Dabei wird ein Hash und
ein Zeitstempel ergänzt, um SPF-gültigen SPAM zu vermeiden und
gleichzeitig eventuelle Fehlermeldungen an den ursprünglichen Absender
weiterleiten zu können."

> Ich habe jetzt einen Blog-Eintrag gefunden, der mir sehr gut gefällt, ich
> denke so werde auch ich es umsetzen:
> http://blog.vom.tc/2013/08/debian-wheezy-postfix-und-srs/

Mit DKIM solltest Dich hier eventuell ebenfalls auseinandersetzen;

Grüße,
Walter

Erzwingen von Fehler 550 an Stelle von Warnung 450

[Walter H.]

Hallo,

kann mir jemand bitte verraten wie ich bei Postfix erzwinge, daß er an 
Stelle eines 450 einen 550 liefert?

hier meine main.cf:  http://pastebin.com/3Fvb6WXy

und mit telnet localhost 25 passiert das:

[root@filter ~]# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 filter.local ESMTP Postfix (2.6.6)
ehlo filter.local
250-filter.local
250-PIPELINING
250-SIZE 20972032
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250 8BITMIME
mail from: 
250 2.1.0 Ok
rcpt to: 
450 4.1.8 : Sender address 
rejected: Domain not found


und genau hier benötige ich an Stelle des 450-Fehlers einen 550 Fehler, 
nur wie?
mein main.cf (http://pastebin.com/3Fvb6WXy) hat so ziemlich alle 
reject-codes auf 550 gesetzt, nur woher kommt dieser 450?


Danke im voraus.

--
Mit freundlichen Grüßen,
Ing. Walter Höhlhubmer

[e-Mail: walte...@mathemainzel.info]





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [SPAM] Re: Erzwingen von Fehler 550 an Stelle von Warnung 450

[Walter H.]

On 08.07.2015 17:07, Robert Schetterer wrote:

Am 08.07.2015 um 16:12 schrieb Walter H.:

Hallo,

kann mir jemand bitte verraten wie ich bei Postfix erzwinge, daß er an
Stelle eines 450 einen 550 liefert?
hier meine main.cf:  http://pastebin.com/3Fvb6WXy

und mit telnet localhost 25 passiert das:

[root@filter ~]# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 filter.local ESMTP Postfix (2.6.6)
ehlo filter.local
250-filter.local
250-PIPELINING
250-SIZE 20972032
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250 8BITMIME
mail from:
250 2.1.0 Ok
rcpt to:
450 4.1.8: Sender address
rejected: Domain not found

und genau hier benötige ich an Stelle des 450-Fehlers einen 550 Fehler,
nur wie?
mein main.cf (http://pastebin.com/3Fvb6WXy) hat so ziemlich alle
reject-codes auf 550 gesetzt, nur woher kommt dieser 450?

Danke im voraus.


sollte sein

http://www.postfix.org/postconf.5.html

reject_unknown_sender_domain
 Reject the request when Postfix is not final destination for the
sender address, and the MAIL FROM domain has 1) no DNS MX and no DNS A
record, or 2) a malformed MX record such as a record with a zero-length
MX hostname (Postfix version 2.3 and later).
 The reply is specified with the unknown_address_reject_code
parameter (default: 450), unknown_address_tempfail_action (default:
defer_if_permit), or 550 (nullmx, Postfix 3.0 and later). See the
respective parameter descriptions for details.


also

unknown_address_reject_code = 550

in main.cf



Hallo wie Du richtig sagst - solllte sein;

ich hab das ja so im main.cf

smtpd_sender_restrictions = reject_non_fqdn_sender, 
reject_unknown_sender_domain

und
unknown_address_reject_code = 550

nebenbei erwähnt postfix 2.6.6 (CentOS 6.x rpm package, CentOS 7.x 
liefert auch nur 2.10.1 mit);


ich dache auch an das:

check_sender_mx_access type:table
Search the specified access(5) database for the MX hosts for the 
MAIL FROM domain, and execute the corresponding action. Note: a result 
of "OK" is not allowed for safety reasons. Instead, use DUNNO in order 
to exclude specific hosts from blacklists. This feature is available in 
Postfix 2.1 and later.


nur wie müsste diese Tabelle aussehen, ich kenne ja die Domainnamen 
nicht, ich weiß nur, es gibt weder A noch MX Rekord dazu;

so in etwa

check_sender_mx_access pcre:/etc/postfix/sender_mx_access.pcre

und da nur dieser Eintrag?
/^$/REJECT

Danke,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [SPAM] Re: Erzwingen von Fehler 550 an Stelle von Warnung 450

[Walter H.]

On 09.07.2015 16:44, Ralf Hildebrandt wrote:

http://www.postfix.org/postconf.5.html

reject_unknown_sender_domain
 Reject the request when Postfix is not final destination for the
sender address, and the MAIL FROM domain has 1) no DNS MX and no DNS A
record, or 2) a malformed MX record such as a record with a zero-length
MX hostname (Postfix version 2.3 and later).
 The reply is specified with the unknown_address_reject_code
parameter (default: 450), unknown_address_tempfail_action (default:
defer_if_permit), or 550 (nullmx, Postfix 3.0 and later). See the
respective parameter descriptions for details.

Ja, aber wenn der DNS einen temp. Fehler liefert, gibt auch Postfix
einen temp. Fehler zurück...
temporärer Fehler etwa alle 4 Minuten, und das schon über mehr als 3 
Tage ist gut ...

Steht aber alles im Log.
genau das ist das Problem, das füllt den Log, langsam, aber stetig und 
ohne Ende;


Grüße,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Re: Erzwingen von Fehler 550 an Stelle von Warnung 450

[Walter H.]

On 09.07.2015 16:43, Ralf Hildebrandt wrote:

* Walter H.:


450 4.1.8: Sender address rejected: 
Domain not found

Was steht im Log?

Jul  5 08:17:25 filter postfix/smtpd[21563]: NOQUEUE: reject: RCPT from 
filter.local[192.168.1.1]: 450 4.1.8 
: Sender address rejected: 
Domain not found; from= 
to= proto=ESMTP helo=
Jul  5 08:21:09 filter postfix/smtpd[21671]: NOQUEUE: reject: RCPT from 
filter.local[192.168.1.1]: 450 4.1.8 
: Sender address rejected: 
Domain not found; from= 
to= proto=ESMTP helo=
Jul  5 08:25:01 filter postfix/smtpd[21794]: NOQUEUE: reject: RCPT from 
filter.local[192.168.1.1]: 450 4.1.8 
: Sender address rejected: 
Domain not found; from= 
to= proto=ESMTP helo=

...
Jul  9 17:33:25 filter postfix/smtpd[17691]: NOQUEUE: reject: RCPT from 
filter.local[192.168.1.1]: 450 4.1.8 
: Sender address rejected: 
Domain not found; from= 
to= proto=ESMTP helo=


knapp alle 4 Minuten ein Eintrag ...

angemerkt sei, daß die Mails via fetchmail abgeholt und an postfix 
übergeben werden; nimmt dieser die Mail mit einem 4xx Fehler aber nicht an,
dann wird diese auch am Postfach beim ISP/Mailhoster/... nicht gelöscht 
und etwa 4 Minuten später wieder versucht ...
verweigert hingegen Postfix mit einem 5xx Fehler, dann wird eine 
Fehlernachricht generiert, und die Mail am Postfach beim 
ISP/Mailhoster/... entfernt;
die hier generierte Fehlernachricht fange ich mittels header_checks am 
'smarthost' ab, und leite sie in den root Ordner;


habe ich z.B. im header_check folgendes

/^from:[[:space:]].*(mainziboy\@yahoo\.com).*$/
REJECT Sender blocked.

dann ergibt das mit telnet folgendes:

[root@filter ~]# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 filter.local ESMTP Postfix (2.6.6)
ehlo filter.local
250-filter.local
250-PIPELINING
250-SIZE 20972032
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250 8BITMIME
mail from: 
250 2.1.0 Ok
rcpt to: 
250 2.1.5 Ok
data
354 End data with .
To: 
From: 
Subject: Automated Test-Mail ...

sent directly from the console via 'telnet'.
.
550 5.7.1 Sender (mainzi...@yahoo.com) blocked.

dann findet man im log folgendes

Jul  9 10:35:09 filter postfix/cleanup[4410]: E852D48F3: reject: header 
From:  from filter.local[192.168.1.1]; 
from= to= proto=ESMTP 
helo=: 5.7.1 Sender blocked


Danke für Hilfe
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Re: Erzwingen von Fehler 550 an Stelle von Warnung 450

[Walter H.]

On 09.07.2015 20:00, Robert Schetterer wrote:

Am 09.07.2015 um 19:08 schrieb Walter H.:

On 09.07.2015 16:43, Ralf Hildebrandt wrote:

* Walter H.:


450 4.1.8: Sender address
rejected: Domain not found

Was steht im Log?


Jul  5 08:17:25 filter postfix/smtpd[21563]: NOQUEUE: reject: RCPT from
filter.local[192.168.1.1]: 450 4.1.8
: Sender address rejected:
Domain not found; from=
to=  proto=ESMTP helo=
Jul  5 08:21:09 filter postfix/smtpd[21671]: NOQUEUE: reject: RCPT from
filter.local[192.168.1.1]: 450 4.1.8
: Sender address rejected:
Domain not found; from=
to=  proto=ESMTP helo=
Jul  5 08:25:01 filter postfix/smtpd[21794]: NOQUEUE: reject: RCPT from
filter.local[192.168.1.1]: 450 4.1.8
: Sender address rejected:
Domain not found; from=
to=  proto=ESMTP helo=
...
Jul  9 17:33:25 filter postfix/smtpd[17691]: NOQUEUE: reject: RCPT from
filter.local[192.168.1.1]: 450 4.1.8
: Sender address rejected:
Domain not found; from=
to=  proto=ESMTP helo=

knapp alle 4 Minuten ein Eintrag ...

angemerkt sei, daß die Mails via fetchmail abgeholt und an postfix
übergeben werden; nimmt dieser die Mail mit einem 4xx Fehler aber nicht an,
dann wird diese auch am Postfach beim ISP/Mailhoster/... nicht gelöscht
und etwa 4 Minuten später wieder versucht ...
verweigert hingegen Postfix mit einem 5xx Fehler, dann wird eine
Fehlernachricht generiert, und die Mail am Postfach beim
ISP/Mailhoster/... entfernt;
die hier generierte Fehlernachricht fange ich mittels header_checks am
'smarthost' ab, und leite sie in den root Ordner;

habe ich z.B. im header_check folgendes

/^from:[[:space:]].*(mainziboy\@yahoo\.com).*$/
 REJECT Sender blocked.

dann ergibt das mit telnet folgendes:

[root@filter ~]# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 filter.local ESMTP Postfix (2.6.6)
ehlo filter.local
250-filter.local
250-PIPELINING
250-SIZE 20972032
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250 8BITMIME
mail from:
250 2.1.0 Ok
rcpt to:
250 2.1.5 Ok
data
354 End data with.
To:
From:
Subject: Automated Test-Mail ...

sent directly from the console via 'telnet'.
.
550 5.7.1 Sender (mainzi...@yahoo.com) blocked.

dann findet man im log folgendes

Jul  9 10:35:09 filter postfix/cleanup[4410]: E852D48F3: reject: header
From:  from filter.local[192.168.1.1];
from=  to=  proto=ESMTP
helo=: 5.7.1 Sender blocked

Danke für Hilfe
Walter


Ich befuerchte das ist der falsche Ansatz, dein ISP/Mailhoster sollte
per se keine Mails von nicht existierenden Domains annehmen, tut er es
doch und du holst die Mails ab wuerde ich empfehlen diese Mails mit
einer Spamassassin Regel als SPAM zu taggen und dann weiterzuleiten

hier ist ein Beispiel

https://sys4.de/de/blog/2013/04/12/abholdienst-fur-mail/

Best Regards
MfG Robert Schetterer


im master.cf von Postfix hab ich das konfiguriert

smtp  inet  n   -   n   -   -   smtpd
   -o content_filter=spamassassin

wenn ich mir diese Liste hier
https://spamassassin.apache.org/tests_3_2_x.html
so ansehe, welche Einträge wären hier relevant,
sodaß ich beim anschließenden header_check darauf abfragen kann;

/home/spamfilter/.spamassassin/user_prefs  sieht so aus:

bayes_min_ham_num 1000
bayes_min_spam_num 250
required_score 4.0
score FREEMAIL_FORGED_REPLYTO   10.0
score HTML_OBFUSCATE_30_40  2.0
score HTML_OBFUSCATE_50_60  3.0
score HTML_OBFUSCATE_70_80  4.0
score HTML_OBFUSCATE_90_100 5.0
score HTML_TAG_EXIST_BGSOUND10.0
score HTML_BADTAG_40_50 2.0
score HTML_BADTAG_50_60 3.0
score HTML_BADTAG_60_70 4.0
score HTML_BADTAG_90_10010.0
score MICROSOFT_EXECUTABLE  10.0
score URIBL_PH_SURBL10.0
score LOCALPART_IN_SUBJECT  10.0

ich könnt auch - ist mir nur nebenbei so aufgefallen - alle mails, welche
von einer Zeitzone, mit der ich nichts zu tun habe  +0300 bis +1000 
grundsätzlich über header_checks blockieren;


über das Webmail Interface von meinem ISP/Webhoster sehe ich momentan 1 
so ein Mail, welches dort schon mehr als 3 Tage liegt,

hier das komplette Mail im Quelltext: http://pastebin.com/qvXif9Eg
(daß das Mail bereits als SPAM von Seiten des ISP/Mailhosters 
gekennzeichnet ist, muss nicht sein)
mit anderen Worten, die Mails durchlaufen 2mal einen SPAMassassin, 
einmal beim ISP/Mailhoster und einmal bei mir;


Danke,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Re: Re: Erzwingen von Fehler 550 an Stelle von Warnung 450

[Walter H.]

On 10.07.2015 10:10, Ralf Hildebrandt wrote:

Jul  5 08:17:25 filter postfix/smtpd[21563]: NOQUEUE: reject: RCPT
from filter.local[192.168.1.1]: 450 4.1.8
: Sender address rejected:
Domain not found; from=

Ja aber die resolved doch!

warum dann diese Meldung - Domain not found?

http://www.tcpiputils.com/browse/domain/fitdomesticcompany.com
sagt etwas anderes ...
weder bei IPv4 noch bei IPv6 eine Info

ein Bug im Postfix?

Grüße
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Frage zur Spamabwehr ....

[Walter H.]

On 12.07.2015 10:04, Stefan Weber wrote:

Hallo,

seit in der main.cf unter smtpd_recipient_restrictions die

check_sender_access hash:/etc/postfix/sender_access,
check_client_access cidr:/etc/postfix/client_access,

werkeln, wird schon einiges abgefangen. Der durchgelassene Spam wird 
trotzdem nicht weniger, weil immer neue IP's auftauchen. Die Anzahl 
der SpamMails die durchkommen, bleiben ungefähr gleich, so um die 50 
über 1-2 Tage.


Aufbau und Inhalt lassen die Vermutung aufkommen, dass da der/die 
gleichen Versender zu Werke sein könnten, was der weiteren Idee 
Nahrung gibt, dass die IP's der vermeintlich absendenden Server gefakt 
(gespooft) sein könnten.


Kannst Du prüfen, ob die IP-Adressen der Server, welche zum postfix 
connecten überhaupt an Hand des SPF (Sender-Policy-Framework)

für die Absenderadressen versenden dürfen?
damit hättest einen Ansatz ...

Grüße,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Frage zur Spamabwehr .... (Nachtrag)

[Walter H.]

On 12.07.2015 11:21, Walter H. wrote:

On 12.07.2015 10:04, Stefan Weber wrote:

Hallo,

seit in der main.cf unter smtpd_recipient_restrictions die

check_sender_access hash:/etc/postfix/sender_access,
check_client_access cidr:/etc/postfix/client_access,

werkeln, wird schon einiges abgefangen. Der durchgelassene Spam wird 
trotzdem nicht weniger, weil immer neue IP's auftauchen. Die Anzahl 
der SpamMails die durchkommen, bleiben ungefähr gleich, so um die 50 
über 1-2 Tage.


Aufbau und Inhalt lassen die Vermutung aufkommen, dass da der/die 
gleichen Versender zu Werke sein könnten, was der weiteren Idee 
Nahrung gibt, dass die IP's der vermeintlich absendenden Server 
gefakt (gespooft) sein könnten.


Kannst Du prüfen, ob die IP-Adressen der Server, welche zum postfix 
connecten überhaupt an Hand des SPF (Sender-Policy-Framework)

für die Absenderadressen versenden dürfen?
damit hättest einen Ansatz ...

Grüße,
Walter



Hallo,

habe hier ein interessantes Dokument entdeckt ...
http://www.arschkrebs.de/slides/antispam-handout.pdf
(die Domain horcht sich etwas seltsam an, aber das Dokument ist gut)

Grüße,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: smtp_tls_policy_maps und backup MX

[Walter H.]

On Mon, July 13, 2015 15:52, dja...@nausch.org wrote:
> HI Patrick, HI all!
>
> Test3:
> Unser eigener Server (Client) soll laut Definition mit den Zielservern
> von example.com und example.net nur über eine verschlüsselte
> Verbindung kommunizieren und versucht nun eine eMail an
> c...@example.com zu senden. Laut MX-Record im DNS weiss mein Server,
> dass er als erstes sein Glück beim Server mx01.example.com versuchen
> soll. Leider klappt die TLS-Verbindung nicht, also wir mein Serveres
> wo versuchen? Genau beim Backup-MX. Leider klappt dort der
> TLS-Handshake auch nicht.
>
>Tja was erwarten wir? Die Nachricht wird zurückbehalten und an
> einem
>der beiden zuständigen MXe zugestellt, sobald der TLS-Kanal zu
> stande
>kommt- dauerts zu lange wird gebounced.
>Was passiert?  die Nachricht wird von meinem MX beim
>backup-MX mx01.example.net *ohne* TLS-Verbindung zugestellt! *möp*
>
> Also passiert genau das, was wir nicht wollten, die Nachricht wird
> unverschlüsselt übertragen, genau das, was wir mit der Konfiguration
> von smtp_tls_policy_maps eigentlich verhindern wollten. :/

liegt es vielleicht daran:

"(mx01.example.net hat als Standard smtpd_tls_security_level = may
gesetzt)"

probier hier mal 'must' an Stelle von 'may'

Grüße,
Walter

Re: DNS & MX

[Walter H.]

On 29.07.2015 13:54, Lars Täuber wrote:

Hallo zusammen,

leider bin ich kein DNS Experte, deshalb hier eine kurze Frage:
Muss der MX host für eine Domäne im gleichen Namensraum wie die Domäne selbst 
sein?

Namensraum?

Oder geht auch soetwas:

# host globalyoungacademy.net
globalyoungacademy.net has address 185.21.102.180
globalyoungacademy.net mail is handled by 20 mx2.bbaw.de.
globalyoungacademy.net mail is handled by 10 mail.bbaw.de.
solange die Hosts mx2.bbaw.de bzw. mail.bbaw.de einen A-Record im DNS 
haben, kein Problem

web.de und GMX akzeptieren das ohne Probleme. Allerdings gibt es auch solche 
Fehlermeldungen in den Logs:

NOQUEUE: reject: RCPT from smtp.ug.edu.gh[197.255.124.93]: 450: Sender address 
rejected: undeliverable address: host ugmsrv.ug.edu.gh[197.255.124.93] said: 550 Sender 
domain  has no DNS MX entry (in reply to MAIL FROM command); from= 
 to=  proto=ESMTP helo=
handelt es sich hier um einen Logeintrag von einem ausgehenden 
Mail-Server? sieht sehr seltsam aus;

vor allem das hier passt nicht ins Bild ...

550 Sender domain  has no DNS MX entry

Grüße,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: DKIM Erlebnisse

[Walter H.]

On 02.08.2015 10:47, Joachim Fahrner wrote:

Hatte eben ein "nettes" Erlebnis mit DKIM. Meine Domain ist mit DKIM
gesichert. Wollte über ein Online-Formular etwas bestellen. Dort gibt
man u.a. seine Mailadresse an. Das Formular erzeugt dann eine
Bestell-Mail mit dieser Mailadresse als Absender.
eigentlich sollte die Mail mit der Domain des Webshopbetreibers 
abgesendet werden,

nicht mit der des Besteller ...
und mit der DKIM der Domain des Webshops signiert werden, wenn schon;


  Bekomme jetzt in regelmässigen Abständen Backscatter
wegen der Unzustellbarkeit.

Designfehler des Webshops?

host mx.53453048.de.strato-hosting.eu [81.169.145.101]
SMTP error from remote mail server after end of data:
550 5.7.1 Refused by local policy. No Author Domain Signature was found on the 
message, and the published ADSP was 'all' (_adsp._domainkey.fahrner.name))
irgendwie unlogisch; hier sollte doch SPF zuschlagen; und das bereits 
beim MAIL FROM ...
DKIM dient doch nur zur Feststellung, ob der Mail-Header manipuliert 
wurde oder nicht;


--
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: DKIM Erlebnisse

[Walter H.]

On 02.08.2015 11:30, Patrick Ben Koetter wrote:

Wirf mal ADSP raus. Es gilt seit ca. 3 Jahren als deprecated und sollte, u.a.
genau wegen solcher Situationen, nicht verwendet werden. DMARC wird ADSP
ablösen.

p@rick

Hallo,

ich hab mir mal die Freiheit genommen, den DMARC RFC 
(https://tools.ietf.org/html/rfc7489) gesucht

und auch gleich im DNS meiner Domain verankert; und jetzt kommt's:
und schon ist auch was bei mir "gelandet"; dessen Inhalt hier:





Microsoft Corp.
dmarc...@microsoft.com
92e65a62ae3e46ee835b790fc28ad...@hotmail.com

1438437600
1438524000




mathemainzel.info
r
r
quarantine
quarantine
100




141.42.206.35
1

none
pass
fail




mathemainzel.info




de.postfix.org
pass


mathemainzel.info
pass






ich würd meinen, daß Mailing-Listen so sie wie diese hier implementiert 
sind,

problematisch sind, eine Flut solcher Mails zu verursachen;
der .xml ist als .zip-Archiv gepackt als Anhang im Mail versandt worden;

der Filename vom .xml: 
hotmail.com!mathemainzel.info!1438437600!1438524000.xml


im Mail-Header:

From: dmarc...@microsoft.com
To: dmarc-feedb...@mathemainzel.info
und
im Betreff: Report Domain: mathemainzel.info Submitter: hotmail.com 
Report-ID: <92e65a62ae3e46ee835b790fc28ad...@hotmail.com>
(als UTF-8 in Base64-kodiert, sieht dann etwa so aus:   Subject: 
=?utf-8?B?UmVwb3J0IERvLmNvbT4=?=)


Grüße,
Walter

p.s. ich wette es kommt ein weiteres ausgelöst durch dieses Mail;



smime.p7s
Description: S/MIME Cryptographic Signature

Re: DKIM konforme Mailing-Listen (SPF-konform wäre hier auch angeraten)

[Walter H.]

On 04.08.2015 20:46, Patrick Ben Koetter wrote:

* Tobias Hachmer:

Hallo Liste,

habe die beiden Blog-Einträge auf blog.sys4.de gelesen und versuche
grade eine DKIM-konforme Mailing Liste zu konfigurieren.


Mailman Version 2.1.20
Die entsprechenden Direktiven in der mmcfg.py sehen so aus:

---
# The following is a three way setting.  It sets the default for the list's
# from_is_list policy which is applied to all posts except those for which a
# dmarc_moderation_action other than accept applies.
# 0 ->  Do not rewrite the From: or wrap the message.
# 1 ->  Rewrite the From: header of posts replacing the posters address with
#  that of the list.  Also see REMOVE_DKIM_HEADERS above.
# 2 ->  Do not modify the From: of the message, but wrap the message in
an outer
#  message From the list address.
DEFAULT_FROM_IS_LIST = 1
ALLOW_FROM_IS_LIST = Yes

# Do not break existing DKIM signatures
DEFAULT_SUBJECT_PREFIX  = ""
DEFAULT_MSG_HEADER = ""
DEFAULT_MSG_FOOTER = ""
---

Leider meckert mein Mail-Server immernoch, dass die erste DKIM-Signatur
nicht mehr korrekt sei und die Mail verändert wurde.

Wie sieht denn der Transportweg aus? Zu welchem Zeitpunkt ist die SIG noch
intakt? Sind da mehr Komponenten im Transportweg drin, die die Mail
bearbeiten? Versuch mal nur die wirklich erforderlichen Header in die Sig
einzubeziehen und nicht alles, was bis drei nicht auf dem Baum ist. ;)



Da stehe ich aktuell auf dem Schlauch. Des Weiteren ist mir aufgefallen,
dass hier auf der Liste der From-Header nicht mehr "Autor via
Listenname" lautet sondern nur den ursprünglichen Autor enthält. Warum
ist das so und die DKIM-Signaturen sind trotzdem korrekt?

Es war ein Versuch (so hatten wir das damals IIRC auch angekündigt) die Liste
auch DMARC-konform zu betreiben, indem ein neuer Autor ins Spiel kommt und
DMARC so nicht mehr ungültig sein kann.

Wir haben das wieder eingestellt, weil DMARC (glücklicherweise) in eine
Revision ging und wir das Experiment deshalb nicht mehr weiterführen wollten
und weil Alexander Wirt mich wegen des Experiments mit fiesen Flüchen belegt
hatte. Denn dieser Test gefiel ihm gar nicht (mir auch nicht). Seitdem ich das
zurückgestellt habe, ist mein Leben auch wieder viel besser. ;)


Hallo Patrick,

die Geschichte mit Mailinglisten und DMARC kann aber auch ganz böse 
sein, und ist sie zwangsweise auch;

nimm nur folgende Situation her:

jemand hat bei seiner Domain nur folgende 2 DNS-Einträge:

_dmarc.domain.tld TXT "v=DMARC1; p=quarantine; 
rua=mailto:dmarc-feedb...@domain.tld; ruf=mailto:dmarc-fail...@domain.tld";

und
domain.tld TXT "v=spf1 mx -all"

dann wird er bei Versand an einer sehr großen Mailingliste und sobald 
DMARC einen gewissen Grad an Verbreitung überschreitet, eine sehr böse 
Überraschung erleben;


jeder Adressat (respetive dessen Mailserver) wird ihn mit DMARC-Mails im 
wahrsten Sinn des Wortes zumüllen, und das kann nicht Sinn des ganzen sein;


DKIM ist da dann eine ganz andere Geschichte,
wobei DKIM-signierte Mails landen bei mir grundsätzlich in der 
Quarantäne oder werden mit ein paar Ausnahmen gleich geblockt;


Grüße,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: IPv6 only sinnvoll ??

[Walter H.]

On 26.8.2015 10:18, Patrick Ben Koetter wrote:

* Markus Müller:

Hallo Liste,

ist es sinnvoll, einen Mailserver ausschliesslich mit einer IPv6 Adresse
zu betreiben, oder gibt es kompatibilitätsprobleme mit Mailservern, die
nur IPv4 verstehen?

Gibt es in Deutschland überhaupt noch Mailserver, die ausschliesslich
IPv4 ohne IPv6 verstehen ?

Es gab in 2014 ca. 2.7 Mio. MX-Einträge in der .de-TLD. Das waren
heruntergebrochen ca. 275.000 unique MTAs. Von denen unterstützten 2014 12.092
MTAs IPv6.

Die Zahlen sagen, dass es nicht sinnvoll ist, einen IPv6 only MX zu betreiben.


Hallo Patrick,

eine Kenngröße wäre in diesem Zusammenhang interessant: wieviele der 
etwa 2,7 Mio MX-Einträge verweisen auf diese 12092 MTAs mit IPv6-Support?


Grüße,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: check-client-access-not-working ?

[Walter H.]

On 02.09.2015 14:51, Tobi wrote:


kann es sein, dass du smtpd_delay_reject nicht gesetzt und damit auf
default YES hast?
<<
Wait until the RCPT TO command before evaluating
$smtpd_client_restrictions, $smtpd_helo_restrictions and
$smtpd_sender_restrictions, or wait until the ETRN command before
evaluating $smtpd_client_restrictions and $smtpd_helo_restrictions.


sollte das nicht alleine nur eine Auswirkung darüber haben,
wann der Fehler kommt, ob bereits bei MAIL FROM oder erst bei RCPT TO 
oder später

(es macht manchmal Sinn nur smtpd_recipient_restrictions zu verwenden,
und smtpd_sender_restricitions wegzulassen)

Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Seltsame Mail - bin verwirrt

[Walter H.]

On 11.11.2015 19:14, J. Fahrner wrote:

Am 11.11.2015 um 17:26 schrieb Walter H.:

On 11.11.2015 16:50, J. Fahrner wrote:

Nov 11 09:53:45 s3 postfix/cleanup[5420]: A9CF8221F9: milter-reject:
END-OF-MESSAGE from shared2.swiftslots.com[31.220.2.120]: 5.7.1
rejected by DMARC policy for interfax.net;
from=   to=
proto=ESMTP helo=

ist es eventuell das?

_dmarc.interfax.net text =

 "v=DMARC1; p=reject; rua=mailto:i...@interfax.net";

wonach Du suchst?

und eventuell das

Subject: You have new fax, document 00271650

ein Folgefehler sein ...
das ursprüngliche Mail samt Header wäre von Interesse, denn dieses war
Malware



Das ist auch mein Verdacht, dass die Mail eine Folge einer
vorausgehenden Malware war. Meine Theorie: ein DMARC-Report an
interfax.net wurde zurückgewiesen und schlug dann bei mir auf. Aber
warum wurde dann der Report von interfax.net zurückgewiesen?


das kann ich mir jetzt nicht vorstellen, der DMARC Eintrag von Deiner 
Domain hat

keine E-mail adresse angegeben ...

_dmarc.fahrner.name text =

"v=DMARC1;p=none"

oder das wird einfach interpretiert alles zurückzuknallen ...




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Postfix sendet nicht an mehrere Empfänger

[Walter H.]

On 11.11.2015 22:01, Daniel Schröter wrote:

Müsste jetzt nicht postfix die Mail duplizieren und zweimal an cyrus
übergeben? Warum macht er es nicht? Oder ist das doch die Aufgabe von
cyrus und falls ja: Warum sehe ich die Mail dort nur einmal?

sieh dir /var/log/maillog etwas genauer an;
die kommt doppelt an, aber Cyrus speichert sie nur 1mal;
(evtl. ein nettes Feature von Cyrus nicht via Massenmail angefüllt zu 
werden)





smime.p7s
Description: S/MIME Cryptographic Signature

Re: welche key länge ist sinnvoll für SMTP TLS (2048 bit reicht?)

[Walter H.]

Hallo,

On 23.12.2015 13:53, Roland Schmid wrote:

ist eine key länge von 2048 bit sinnvoll oder besser länger für SMTP TLS?

#TLS

smtpd_enforce_tls  = no

smtpd_use_tls = yes

smtpd_tls_loglevel = 1

smtpd_tls_key_file = /etc/postfix/smtpd.key

smtpd_tls_cert_file = /etc/postfix/smtp.cert


ich würde unterscheiden ob es sich um einen Server handelt, welcher als 
MX dient oder ob es sich um einen Server handelt an dem sich tatsächlich 
Clients anmelden;


im Fall von MX genügt ein DV SSL-Zert mit 2048 bit, im anderen Fall 
würde ich schon ein OV SSL-Zert. aber auch mit 2048 bit nehmen;





smime.p7s
Description: S/MIME Cryptographic Signature

Re: welche key länge ist sinnvoll für SMTP TLS (2048 bit reicht?)

[Walter H.]

Hallo,

On 23.12.2015 15:00, Roland Schmid wrote:

ich würde unterscheiden ob es sich um einen Server handelt, welcher als
MX dient oder ob es sich um einen Server handelt an dem sich tatsächlich
Clients anmelden;

im Fall von MX genügt ein DV SSL-Zert mit 2048 bit, im anderen Fall
würde ich schon ein OV SSL-Zert. aber auch mit 2048 bit nehmen;

der gemeinte Server dient nur als MX für mail relay
(keine lokalen mailboxen)


aber auch nicht als SMTP-Relay, oder?
(der hätte in der Regel nämlich keine lokalen Mailboxen )

nur um sicher zu gehen;

der Hintergedanke bei meiner Unterscheidung ist einfach die, daß
bei Clients (Outlook, Thunderbird, ) der Benutzer das Zertifikat 
auch sieht und daher ein OV SSL-Zert. zu bevorzugen ist;
und wenn es nur ein MX für mail relay ist, sieht niemand das Zertifikat 
und daher ist ein DV SSL-Zert. völlig ausreichend;


Grüße.
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Postfix mit ClavAV Antivirus

[Walter H.]

Hallo,

habe meinem eingehenden Mailserver, auf welchem Postfix mit SpamAssassin 
und Fetchmail bereits läuft um

ClamAv bzw. ClamSmtp erweitert und folgendes in  der main.cf

content_filter = clamav-scan:[127.0.0.1]:10025

bzw. in der master.cf

clamav-scan unix -   -   n   -   16   smtp
   -o smtp_data_done_timeout=1200
   -o smtp_send_xforward_command=yes
   -o disable_dns_lookups=yes
127.0.0.1:10026 inet n   -   n   -   16   smtpd
   -o content_filter=
   -o local_recipient_maps=
   -o 
receive_override_options=no_unknown_recipient_checks,no_header_body_checks

   -o relay_recipient_maps=
   -o smtpd_restriction_classes=
   -o smtpd_client_restrictions=
   -o smtpd_helo_restrictions=
   -o smtpd_sender_restrictions=
   -o smtpd_recipient_restrictions=permit_mynetworks,reject
   -o mynetworks_style=host
   -o smtpd_authorized_xforward_hosts=127.0.0.1

der Virenscan funktioniert; jetzt die Frage:

wie müsste ich es entweder mit
/bin/mail
oder mit
/usr/sbin/sendmail
anstellen, um ein Mail für den Root oder was auch immer abzusetzen, 
welches den Antivirenscan umgeht?


worum geht es:

dem ClamSmtp habe ich ein Skript hinzugefügt, welches die Malware-Mails 
in einem Quarantäne-Ordner ablegt,
und genau diese Mails würde ich dem Hersteller meines auf dem PC 
installieren Antivirenprogrammes zukommen lassen

und direkt an dessen Analyselabor (per E-mail) schicken;

zusätzliche Info: in der main.cf habe ich folgendes eingetragen
relayhost = [mail.srvr1]:25
und mail.storage ist der zentrale Mailserver,
welcher sowohl als SMTP-Server f. die Clients und auch als IMAP-Server 
verwendet wird;


kann ich mit /bin/mail bzw. /usr/sbin/sendmail einen SMTP-Server verwenden?
wenn ja, wie?

Danke,
Walter H.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Absender blocken, die unsere Domain als Versender verwenden aber nicht von unserem Mailserver kommt

[Walter H.]

Hallo,

behandelst Du etwaiges "Verhalten", daß jemand bewußt ein Mail auch an
sich selbst schickt separat über einen "shortcut"-Pfad?

z.B.  From: me
  To: eins, zwei, drei, vier
  BCC: me

On Fri, February 12, 2016 08:35, Andreas Wass - Glas Gasperlmair wrote:
> Ja stimmt!
> An die Reihenfolge der Abarbeitung (permit_mynetworks) hab ich jetzt gar
> nicht mehr gedacht und auf die Idee, seine eigene Domain in der
> check_sender_access restriction mit einem REJECT zu versehen wär ich gar
> nicht gekommen.
>
> Es funktioniert!!
>
> Vielen Dank für die Hilfe ;-)
> Andi
>
> Mit freundlichen Grüßen
>
> *Andi*
>
> Am 11.02.2016 um 16:23 schrieb Marco Dickert:
>> Moin,
>>
>> On 2016-02-11 16:07:00, Andreas Wass - Glas Gasperlmair wrote:
>>> In letzter Zeit häufen sich Mails von Absendern, die unsere Domain
>>> in deren Absenderadressen verwenden und ein Worddokument als Anhang
>>> mitsenden, welches natürlich schadhaft ist.
>>> Gibt es eine Möglichkeit solche Mails zu blocken?
>> ist hier [1] beschrieben. Würde ca so aussehen:
>>
>> /etc/postfix/main.cf:
>>  smtpd_sender_restrictions=
>>  permit_mynetworks
>>  ...
>>  check_sender_access hash:/etc/postfix/sender_restrictions
>>
>> /etc/postfix/sender_restrictions:
>>  example.org REJECT
>>
>>
>> [1] http://www.postfix.org/ADDRESS_VERIFICATION_README.html
>>
>
>

Re: AW: Absender blocken, die unsere Domain als Versender verwenden aber nicht von unserem Mailserver kommt

[Walter H.]

Hallo,

On Thu, February 11, 2016 23:08, Uwe Drießen wrote:

> SPF  hat andere schwächen und ist eigentlich nicht das mittel der Wahl
> dafür
> Mit SPF  kann ein fremder Mailserver-Empfänger prüfen ob die Mailadresse
> vom originalen dafür vorgesehenen Server kommt.

Genau darum geht es ja; es werden nur Mails zugelassen, welche von Servern
kommen, die auch dazu befugt sind im Namen des Absenders zu senden;

> Bei mir sind fremde Mailserver und eigene User strikt getrennt
> Fremde dürfen/müssen über 25 eigene User mit eigenen Restriktionen sind
> nur auf den alternativen (587,465...usw) erlaubt

D.h. Du hast einen Mailserver sowohl als MX (Port 25) als auch als SMTP
für User (Ports 587, 465, ...) in Verwendung?

> In den nachfolgenden restrictions für Port 25 steckt das irgendwo drin
>
> smtpd_recipient_restrictions =
>reject_unknown_sender_domain,
>reject_unknown_recipient_domain,
>permit_mynetworks,
>reject_unlisted_recipient,
>reject_non_fqdn_sender,
>reject_non_fqdn_recipient,
>reject_unlisted_sender,
>reject_unauth_destination,
>reject_unverified_recipient,

damit verhinderst aber keine Mails, welche Deine Domain als Absender
verwenden, obwohl nicht authorisiert ...

Grüße,
Walter

DualStack ein Fluch oder ein Segen ...

[Walter H.]

Hallo,

mein ISP ist momentan noch IPv4 only; seit ein paar Jahren habe ich 
einen IPv6-Tunnel von SixXS in Verwendung;
da dort aber irgendwie in letzter Zeit gewaltige Performance-Einbrüche 
zum einem und die seltsame Geschichte,
daß der PoP sich nicht gerade in einem Land, dessen Sprache man mächtig 
ist, befindet;
so habe ich seitdem einen IPv6-Tunnel eines anderen Tunnelbrokers in 
Verwendung;


ich habe 3 Mailserver [CentOS based] (einer der mit Spamassassin und 
ClamAV, die mittels Fetchmail abgeholten Mails filtert,
einen der als Router fungiert und über die entsprechenden SMTP-Server 
der Mail/ISPs versendet

und einen der als IMAP-Server den Mailstore hat);

nun gut; ich habe am lokalen IPv4-Netz nichts geändert, das war vorher 
und nachher ident;


in der main.cf vom IMAP-Server mit dem Mailstore
habe ich das ...

mynetworks = IPv4-Subnet, [IPv6-Prefix], 127.0.0.0/8, [::1/128]

sowie

smtp_bind_address = IPv4-Address
smtp_bind_address6 = IPv6-Address

ich hatte vergessen, auch den IPv6-Prefix bei 'mynetworks' zu ändern,
und damit hatte der filternde Mail-Server ein Problem, Mails  an den 
Mailstore zu übergeben;


wieso fand hier kein "Fallback" auf IPv4 statt?
welches ja unverändert funktionierte ...

angemerkt sei, daß ich einen Caching-DNS-Server am laufen habe, und dort 
die entsprechenden Zonen
ebenfalls umkonfiguriert hatte; dies bei 'mynetworks' war echt das 
einzige, was ich vergessen hatte, aber
wie sich ein paar Stunden später herausstelle eine "Katastrophe", die 
nur ein paar Newsletter "shredderte"
(leerte manuell nach der Korrektur von 'mynetworks' die Mailqueue am 
filternden Mailserver mit postsuper);


Grüße,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: SPF: A-Record mit mehreren IPs?

[Walter H.]

On 10.06.2016 13:47, Patrick Westenberg wrote:

Achso, ja.
Ich dachte an den DNS-A-Record


und davon kannst mehrere auf verschiedene Adressen haben ...

mail.domain.tld.   IN A 1.1.1.10
mail.domain.tld.   IN A 1.1.1.11
domain.tld.IN MX 10 mail.domain.tld.

oder wäre das hier nicht zulässig?

Walter H.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Unklare Übertragungsprobleme bei einigen Mails

[Walter H.]

On 27.06.2016 10:51, Patrick Ben Koetter wrote:

Hi!

Am 27.06.2016 um 10:25 schrieb Stephan Jacob:

Hallo Postfixler,

ich bin auf ein Phänomen gestoßen, welches ich mir nicht erklären kann. Ggf. 
hat einer von euch eine Idee, wie folgende Situation zu
Stande kommt:

Ich habe einen Relay Server aufgesetzt und diesen mit IPTables abgesichert 
(Regeln sind unten beschrieben).
Der Server soll vornehmlich Mails "von außen" annehmen und dann intern an 3 
verschiedene Mailserver weiterleiten.
Bei der Weiterleitung an einen der 3 Mailserver (den unserer Kollegen aus der 
Uniklinik) kam es bei vereinzelnden Mails zu
Zustellungsproblemen und die Mails wurden mit "status=deferred (conversation 
with uniklinikmailserver[149.AAA.BBB.CCC] timed out
while sending message body)" gequeued.

Das Problem trat grundsätzlich nur bei "großen" Mails (beobachtet bei 5MB bis 35MB) auf. 
Dort aber auch nicht bei allen "großen"
Mails. Als ich verschiedene Testmails verschiedener Größe an den Mailsserver 
gesendet habe, konnte ich den Fehler nicht nachstellen.
Problematische Mails verschwanden irgendwann (mal nach 20 Minuten, mal nach 5 
Stunden) von alleine aus der Queue und wurden laut Log
auch an den Uniklinik-Server übertragen. Auch gingen zum Zeitpunkt, wo der 
Fehler auftritt auf einen anderen Kanal erfoglreich Mails
zum dem Mailserver durch, d.h. er war auch verfügbar.

Der entgegennehmende Server ist temporär überlastet und kann während
dieser Lastspitzen keine grossen Mails in akkzeptabler Zeit prüfen. Ein
Timeout im Client ist die Folge. Wenn die Last gesunken ist *und* wenn
Dein Client einen erneuten Zustellversuch unternimmt, geht die Mail dann
durch.

p@



Das Problem trat auf, als ich folgende IPTabels Regeln aktiv hatte:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j 
ACCEPT
diese line ist merkwürdig, öffnest du ungehindert jeden port für die 
ganze Welt?

-A INPUT -s 141.AAA.240.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn 
--dport 25 -j DROP

diese line kommt hier gar nicht mehr zum tragen ...

-A INPUT -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j ACCEPT
diese line ebenfalls obsolete in dieser reihenfolge ... weil darüber 
schon jeder port für alle freigegeben ist ...

-A INPUT -s 141.AAA.13.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn -m 
multiport --dports 22 -j ACCEPT

sicher, daß SSH nicht von woanders ebenfalls geht ..., sehe oben

-A INPUT -d 141.AAA.BBB.CCC -i eth0 -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -s 141.AAA.BBB.CCC -o eth0 -j ACCEPT
COMMIT

ich denke hier ist irgendwo der hund begraben


(In Zeile 7 wird bewusst eines unserer Subnetze ausgeschlossen, es soll kein 
Mailversand dort stattfinden)
könntest die intentionen, welche du mit iptables bewirken wolltest 
zusammenfassen, dann kann ich dir die korrigierte variante zeigen ...


Im Zuge der Problemfindung habe ich dann die Pakete, die in der Kommunikation 
mit dem Uniklinik-Server gedropt werden mitgeloggt.
Dabei habe ich bei den Mails, bei denen der oben beschriebene Fehler vorkam 
folgende Log-Einträge gefunden:

Jun 23 12:23:33 mx3 kernel: [   10.790460] IPTables-Dropped: IN=eth0 OUT= 
SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=64 TOS=0x00
PREC=0x00 TTL=60 ID=64801 DF PROTO=TCP SPT=25 DPT=60337 WINDOW=480 RES=0x00 ACK 
URGP=0

hier wird ein antwort-paket verworfen ...


Oder bei einer anderen Mail:
Jun 23 12:48:32 mx3 kernel: [ 1509.990907] IPTables-Dropped: IN=eth0 OUT= 
SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=168 TOS=0x00
PREC=0x00 TTL=60 ID=36782 DF PROTO=TCP SPT=25 DPT=32982 WINDOW=3797 RES=0x00 
ACK PSH URGP=0

hier ebenso ...

(149.AAA.BBB.CCC ist der Uniklinikserver und 141.AAA.BBB.CCC bin ich). Zur 
Sicherheit noch einmal: Diese Einträge kamen als ich
(141.AAA.BBB.CCC) an die Uniklinik (149.AAA.BBB.CCC) Mails gesendet habe.

SRC=149.AAA.BBB.CC DST=141.AAA.BBB.CCC SPT=25 DPT=
source = uniklinik server port 25
dest = dein server irgendein port

Es wurden aber nur Pakete bei den Mails verworfen, bei denen die Übertragung 
nicht funktioniert hat.
oder die Umkehrung, weil Pakete verworfen wurden, funktionierte die 
Übertragung nicht ...





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Zertifikat für Mailserver

[Walter H.]

On Thu, October 6, 2016 19:40, Joachim Fahrner wrote:

>> Bei Let's Encrypt: nix
>>>
>>> 4.)Welchen Anbieter könnt ihr empfehlen?
>>>
>
> Ich verwende seit Jahren auf meinem Server ein Zertifikat von
> cacert.org. So weit mir bekannt der einzige Anbieter von kostenlosen
> Wildcard-Zertifikaten.

ich habe eine Quelle erschlossen, welche den genannten Nachteil nicht haben;
siehe hier:

https://www.lowendtalk.com/discussion/81026/free-alphassl-wildcard-and-regular-ssls

bin durch Zufall dorthin "gestolpert"

> Für Mailserver aber egal, da reicht im Prinzip auch ein
> self-signed Zertifikat.

das reicht im Prinzip grundsätzlich; das Zertifikat hat keinen Einfluß auf
die Verschlüsselung; einzig auf die Vertrauensstellung;

> Das mit den Zertifizierungsstellen halte ich ohnehin für Schwachsinn,
> warum sollte ich ausgerechnet z.B. einer "Türktrust" trauen?

'SSL Everywhere' läßt grüßen ...

> Viel sinnvoller wäre es, wenn
> Anbieter, bei denen es auf Sicherheit ankommt (z.B. Banken) ihren Kunden
> den Fingerprint auf sicherem Wege zukommen lassen (z.B. mit den
> Zugangsdaten für das Online-Banking).

nicht wirklich; aber hier gehen die Meinungen konträr auseinander;

Grüße,
Walter

Envelope Sender selektiv umschreiben ...

[Walter H.]

Hallo,

ich habe folgende Konstellation;

auf einem virtuellen Server eines Webhosters läuft ein Postfix,
welcher auch glzt. im DNS der MX Record meiner 2ten Domain zugewiesen ist;
Mails welche an diese 2te Domain gehen, leite (relaye) ich an eine
bestimmte E-mail-Adresse meiner 1ten Domain weiter;

auf dem virt. Server werden aber auch Mails generiert: Logwatch, ...

hier mal relevante Teile meiner Konfig:

smtp_generic_maps = hash:/etc/postfix/generic

r...@vhost.mail  vhost-root@my1stdomain
logwa...@vhost.mail  vhost-logwatch@my1stdomain
postmas...@vhost.mailvhost-postmaster@my1stdomain
mailer-dae...@vhost.mail vhost-mailer@my1stdomain

virtual_alias_maps = hash:/etc/postfix/virtual

@my2nddomainalias@my1stdomain
walter  walter.h@my1stdomain
rootvhost-root@my1stdomain

transport_maps = hash:/etc/postfix/transport

alias@my1stdomain   smtp:mx-of-my1stdomain
@my1stdomainsmtp:smtp-of-mailhoster-of-my1stdomain:587

relay_domains = my2nddomain
relay_recipient_maps = hash:/etc/postfix/relay_recipients

info@my2nddomain  OK
root@my2nddomain  OK
...

sender_canonical_classes = envelope_sender
sender_canonical_maps = regexp:/etc/postfix/canonical

!/(\<)?(.*)\@my1stdomain(\>)?/   alias@my1stdomain

es sollen damit nur bei den Mails, welche meine 2te Domain als Ziel haben
der Envelope-Sender umgeschrieben werden;

mit

//  alias@my1stdomain

werden alle Envelope-Sender umgeschrieben ...

was mache ich falsch oder wie gehts richtig?

Danke,
Walter

Re: Zertifikat für Mailserver

[Walter H.]

On Wed, October 19, 2016 19:58, J. Fahrner wrote:
> Am 10.10.2016 um 21:46 schrieb Johannes Kastl:
>> Was soll das dann bringen? Verschlüsselten Transport zu einer nicht
>> vertrauenswürdigen Endstelle?
>>
>
> Soviel zum Thema "vertrauenswürdig":
> https://www.heise.de/security/meldung/Zertifikats-Klau-Fatale-Sehschwaeche-bei-Comodo-3354229.html
>
>
das ist aber nur bei HTTP(S) kritisch; bei SMTP(S) irrelevant, zumal
niemand die Zertifikate von Mailservern welche als MX eingetragen sind, je
direkt überprüft;
einzig beim eigentlichen SMTP-Server, welchen man beim Mail-Client
eingestellt hat, hat man als Benutzer eine Möglichkeit das Zertifikat
überhaupt zu Gesicht zu bekommen ...

beim Zugriff via POP3(S) oder IMAP(S) auf sein beim ISP oder sonst einem
Hoster gehosteten Postfach, würde einem potentiellen Angreifer einem auf
die Art "gewonnenem" Zertifikat überhaupt nicht gedient sein, weil Du nie
damit in Berührung kommst ...

Re: Zertifikat für Mailserver

[Walter H.]

Hallo Gregor,

On Thu, October 20, 2016 07:57, Gregor Hermens wrote:

> In beiden Fällen muß ich nur zusätzlich Einfluß auf den DNS-Resolver des
> Opfers nehmen können,

was ohne entsprechende Kollateralschäden schon mal nicht möglich ist;

> was bei genügend krimineller Energie kein Hexenwerk ist...

doch, weils in der Menge derer, die diesen Resolver verwenden, garantiert
mind. einen gibt, dem es verhext vorkommt und mit dem Besen andere warnt
;-)

oder anders: ein MITM Angriff auf die Art nur auf EINE ganz bestimmte
Person ist ausgeschlossen;

hat jemand seine eigene Domain, und betreibt zusätzlich seinen eigenen
Resolver sowie auch die Athoritativen DNS Server der Domain, ist ein
derartiger MITM-Angriff das kleinere Problem ...

Grüße,
Walter

Re: Zertifikat für Mailserver

[Walter H.]

Hallo Gregor

On Thu, October 20, 2016 10:29, Gregor Hermens wrote:
>> oder anders: ein MITM Angriff auf die Art nur auf EINE ganz bestimmte
>> Person ist ausgeschlossen;
>
> wenn ich es schaffe, mich in die Internet-Verbindung meines Opfers
> einzuklinken, kann ich mich diesem gegenüber sowohl als dessen Resolver
> als auch Mailserver ausgeben.

auf die Art? ;-)
http://web.archive.org/web/20151202203337/http://telecom.kz/en/news/view/18729

> Beispiel: Ich könnte einen WLAN-Access-Point aufsetzen, ...

seit wann gilt eine WLAN-Verbindung als sicher?

(man benutzt öffentliche WLANs doch grundsätzlich nur mit VPNs)

Grüße,
Walter

Re: Automatische Mailarchiv nach Empfänger User

[Walter H.]

On 25.10.2016 17:57, Lothar Wolff wrote:

Hallo,

eingelieferte E-Mails werden nachdem über Postfix (nach Antivirus V/SPAM etc.) 
an einen anderen MTA (Exchange) weitergeleitet.

Um ein ähnliches System, wie beim vorherigen Maileingang zu er zeugen, wird 
folgendes angestrebt.


-   Für jede eingehende E-Mail Adresse  z.B. xxx at tld.de  soll 
ein Verzeichnis angelegt werden.

-   In diesem Verzeichnis sollen dann alle eingehenden E-Mails für diese 
Adresse abgelegt werden.
Dateiname   xx.eml  oder msg.

-   Optionaljeder Monat ein Unter-Ordner


Wenn dieses Thema in einer ähnlichen Art schon in der Vergangenheit behandelt 
wurde, bitte ich um Benennung eines Links,
oder andere Informationen.  
für denn Fall, daß die eingehenden E-Mail Adressen bereits bestimmt 
sind, gäbe es dafür eine unorthodoxe Lösung ...
sind die E-Mail Adressen nicht bekannt oder werden dynamisch während der 
Laufzeit bestimmt wirds unmöglich, würde ich mal sagen ...


Grüße,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Fwd: Kundensicherheit

[Walter H.]

On 17.12.2016 16:28, Michael Ströder wrote:

Joachim Fahrner wrote:

Ich verstehe nicht, warum 1&1 dem Misbrauch ihrer Server tatenlos zusieht.

AFAIK hat 1&1 eine Abuse-Abteilung,

die hat die Telekom auch, und dahinter sitzen Unwissende ...
(dort wird man nur tätig, wenn man einen E-mail Header vorlegen kann ...)

  bei denen Du Misbrauch ihrer Server melden kannst.
hier würde ich eher mich SPAMcop bedienen als mich mit einzelnen 
herumschlagen ...

"Tatlos zusehen" ist also was anderes.
dann nenne es Volgelstrauß Politik, das Ergebnis ist jedenfalls das 
selbe ...





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Fwd: Kundensicherheit

[Walter H.]

On 17.12.2016 16:20, Joachim Fahrner wrote:

Hallo Robert,

das hört sich ja ziemlich aufwendig an. Ich habe jetzt einfach mal 
alle Server von mout.kundenserver.de geblockt. Mir ist momentan nicht 
bewußt, dass da jemals legitime Mails hergekommen wären. Ich beobachte 
halt jetzt täglich ob da was zuviel geblockt wurde.


Ich verstehe nicht, warum 1&1 dem Misbrauch ihrer Server tatenlos 
zusieht.
Und ich verstehe auch nicht, warum deren Server immer noch auf der 
dnswl.org Whitelist sind. Das führt die Whitelist ad absurdum.
Wie kommt man eigentlich auf diese Whitelist? Gegen Geld? Läuft das da 
ähnlich wie bei den Adblockern mit den "acceptable ads"?

versuche mal sowas ...

smtpd_sender_restrictions = check_sender_mx_access 
cidr:/etc/postfix/drop.cidr, check_sender_ns_access 
cidr:/etc/postfix/drop.cidr, reject_non_fqdn_sender, 
reject_unknown_sender_domain


und /etc/postfix/drop.cidr generierst Du so ...

wget -q -nd --output-document=- http://www.spamhaus.org/drop/drop.lasso 
|awk '/; SBL/ { printf( "%s\tREJECT %s\n", $1, $3 ) }' 
>/etc/postfix/drop.cidr


Grüße Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Fwd: Kundensicherheit

[Walter H.]

On 17.12.2016 20:52, Christian Boltz wrote:

Davon abgesehen: Wenn alle großen Provider den Versand von Spam
unterbinden würden
wäre zumindest ein erster Schritt getan, eine derartige 
Resourcenverschwendung etwas einzudämmen;
wenn Du denkst, es gäbe dann keinen SPAM hast Du Dich ohnehin 
geschnitten ...



- wer würde dann noch freiwillig den Aufpreis für den
Spamfilter fürs eigene Postfach bezahlen? ;-)
so lange ISPs nicht durch irgendwelche Richtlinien, Verträge 
verpflichtet werden (können) Mailverkehr ausschließlich über deren 
Mailserver ausgehend zuzulassen,

wirst Du den auf die Art generierten SPAM ohnehin nicht los ...




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Fwd: Kundensicherheit

[Walter H.]

On 18.12.2016 18:05, Andreas Ziegler wrote:
ohne Vorlage des Mail Headers wird kaum jemand reagieren, wir auch nicht. 
das ist genau das Problem bei Unwissenden, denn ein Log, welcher zeigt 
dass ein bestimmter Host, im Minutentakt versucht ein Mail abzuladen¹,

hat nun mal nur die Mail-Enevelopes, aber keine Mail-Header ...

¹ vor einigen Jahren schnappte mein SMTP derartiges auf, es gab eben nur 
die Mail-Envelopes, weil sie nicht angenommen wurden;
und es handelte sich damals um einen Host eines Kunden der Dt. Telekom, 
der Mitglied eines Botnetzes war, welches
wie wild Mails durch die Gegend sendete und dooferweise meinen SMTP als 
Mail-Relay zu mißbrauchen versuchte ...




smime.p7s
Description: S/MIME Cryptographic Signature

Abbilden von Adressüberschreibungsregeln ...

[Walter H.]

Hallo,

wie kann ich das Überschreiben der Envelope-Sender Adresse nur für 
bestimmte Envelope-Recipeints definieren?


ich habe einen Mailserver, welcher f. eine 2te Domain im DNS als MX 
fungiert, und alle Mails bis auf Ausnahmen
unter Änderung des Envelope-Senders¹ an eine bestimmte Mailadresse 
meiner 1ten Domain (2nddom...@1stdomain.tld) relayen soll;


¹ mein Server ist ja nicht befugt im Namen der Absender zu senden, aber 
im Namen der 2ten Domain (hier 2nddomain.tld)


dies mach ich mit dem
virtual_alias_maps = hash:/etc/postfix/virtual
@2nddomain.tld2nddom...@1stdomain.tld

sender_canonical_classes = envelope_sender
sender_canonical_maps = pcre:/etc/postfix/sndr_canonical.pcre

mit

if /.+/
!/(.+)\@vhost\.mail/nore...@2nddomain.tld
endif

wendet das f. alle ankommenden Mails an,
und genau das ist mein Problem ..., denn
f. ein paar bestimmte Mailadressen der 2ten Domain will ich einen 
Autoreply haben ...


virtual_alias_maps = hash:/etc/postfix/virtual
mit
e...@2nddomain.tlde...@reply.mail

und

transport_maps = hash:/etc/postfix/transport
mit
reply.mail  reply:

und in master.cf

reply   unix-   n   n   -   -   pipe
  flags= user=nobody argv=/etc/postfix/autoreply.sh ${sender} ${recipient}

bekommt das skript   autoreply.sh
als $1 an Stelle des tatsächlichen Absenders den weiter oben überschriebenen
nore...@2nddomain.tld

was mache ich falsch?

Danke für Unterstützung,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Reihenfolge von Adressumschreibungen ...

[Walter H.]

Hallo,

kann man die Reihenfolge von Adressumschreibungen beeinflussen?

habe im westentlichen die Anleitung hier:
https://dokuwiki.tachtler.net/doku.php?id=tachtler:postfix_echo-mailer-script_installieren

verwendet um mir ein echo@domain zu "erschaffen", es funktioniert auch, 
hat aber nur einen Haken,

ich musste auf die kommentierte Zeile

SENDER=`egrep "^From: " $FILE_IN | $HEAD_COMMAND -1 | $SED_COMMAND "s,^From: 
,,"`

zurückgreifen, weil dieser Postfix als MX-Server meiner 2ten Domain 
fungiert,
und alle Mails die dort ankommen so an eine Mailadresse meiner 1ten 
Domain weitergeleitet werden sollen,

daß ich dies im Mail erkenne, und genau das habe ich mit folgendem gemacht:

/etc/postfix/sndr_canonical.pcre

if /.+/
!/(.+)\@vhost\.mail/noreply@2tedomain
endif

und im /etc/postfix/main.cf das

sender_canonical_classes = envelope_sender
sender_canonical_maps = pcre:/etc/postfix/sndr_canonical.pcre

und genau diese Ersetzung wird durchgeführt bevor

das von /etc/postfix/master.cf

reply   unix-   n   n   -   -   pipe
  flags= user=nobody argv=/etc/postfix/autoreply.sh ${sender} ${recipient}

ausgeführt wird;
kann ich diese Ersetzung f. genau eine einzige Zieladresse (echo@2tedomain)
ausnehmen?
wenn ja, wie?

das Relayen/Forwarden von der 2ten Domain auf die 1te Domain habe ich in 
Summe so gelöst


in /etc/postfix/main.cf weiters noch

myhostname = vhost.mail   ; vhost.mail ist im /etc/hosts File auf die 
IPadressen von smtp_bind_address bzw. smtp_bind_address6 gesetzt

inet_interfaces = $myhostname
inet_protocols = all
mydestination = $myhostname, $mydomain

relayhost = leer
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)

sender_dependent_relayhost_maps = hash:/etc/postfix/dependent_relayhost

strict_7bit_headers = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_unknown_hostname, 
reject_non_fqdn_helo_hostname
smtpd_client_restrictions = permit_mynetworks, 
reject_unknown_client_hostname

smtpd_etrn_restrictions = permit_mynetworks, reject

smtpd_sender_restrictions = check_sender_mx_access 
cidr:/etc/postfix/drop.cidr, check_sender_ns_access 
cidr:/etc/postfix/drop.cidr, reject_non_fqdn_sender, 
reject_unknown_sender_domain


smtpd_recipient_restrictions = permit_mynetworks, 
reject_non_fqdn_recipient, reject_unauth_destination, 
reject_unknown_recipient_domain, check_recipient_access 
hash:/etc/postfix/recipient_access, reject


smtpd_discard_ehlo_keywords = silent-discard, dsn

smtpd_reject_unlisted_sender = yes
smtpd_reject_unlisted_recipient = yes
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/postfix/tls.crt/2tedomain-host.crt
smtpd_tls_key_file = /etc/postfix/tls.key/2tedomain-host.key
smtpd_tls_CAfile = /etc/postfix/tls.crt/server-chain-intermediate.crt
smtpd_tls_dh1024_param_file = /etc/postfix/tls.dh/dh2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/tls.dh/dh512.pem
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_cache
smtpd_tls_session_cache_timeout = 3600s

smtp_bind_address = IPv4
smtp_bind_address6 = IPv6

smtp_generic_maps = hash:/etc/postfix/generic
smtp_always_send_ehlo = yes
smtp_helo_name = ipv6home.eu
smtp_helo_timeout = 45
smtp_host_lookup = dns, native
smtp_cname_overrides_servername = no
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
smtp_tls_CAfile = /etc/pki/tls/cert.pem
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_cache
smtp_tls_session_cache_timeout = 3600s

virtual_alias_maps = hash:/etc/postfix/virtual

transport_maps = hash:/etc/postfix/transport

message_reject_characters = \0

message_size_limit = 1048576

unknown_address_reject_code = 554
unknown_client_reject_code = 550
unknown_hostname_reject_code = 554
unverified_recipient_reject_code = 554
unverified_sender_reject_code = 554

relay_domains = 2tedomain


/etc/postfix/dependent_relayhost

@1tedomain  
MX-host-von-domain-hoster-der-im-DNS-von-1te-domain-steht:25
@vhost.mail 
smtp-host-von-domain-hoster-der-fuer-1te-domain-senden-darf:587


/etc/postfix/generic

calc...@vhost.mail  calcbox-worker@1tedomain
wal...@vhost.mail   walter.h@1tedomain
r...@vhost.mail vhost-root@1tedomain
logwa...@vhost.mail vhost-logwatch@1tedomain
postmas...@vhost.mail   vhost-postmaster@1tedomain
echo-re...@vhost.mail   vhost-echoreply@1tedomain
mailer-dae...@vhost.mailvhost-mailer@1tedomain

/etc/postfix/recipient_access

domainmaster@2tedomainOK
hostmaster@2tedomain  OK
postmaster@2tedomain  OK
echo@2tedomainOK
abuse@2tedomain   OK
admin@2tedomain   OK
info@2tedomainOK
root@2tedomainOK
walter.h@2tedomainOK

/etc/postfix/sasl_passwd

smtp-host-von-domain-hoster-der-fuer-1te-domain-sen

Re: Ist ein CNAME bei einer rDNS Abfrage erlaubt?

[Walter H.]

On 12.05.2017 10:06, Tobi wrote:

Hallo zusammen

kurze Frage: habe gestern auf meinem Postfix den rDNS Check aktiviert via

reject_unknown_reverse_client_hostname

in der smtpd_client_restrictions
Heute morgen konnte ich sehen, dass dabei die Mailingliste von ntp.org
abgelehnt wird mit:

Client host rejected: cannot find your reverse hostname,
  [185.140.48.241]

Eine Abfrage des rDNS der IP ergibt ein Resultat, welches ich in dieser
Form noch nicht gesehen habe

241.48.140.185.in-addr.arpa. 2731 INCNAME
241.192/26.48.140.185.in-addr.arpa.
241.192/26.48.140.185.in-addr.arpa. 931IN PTRpsp3.ntp.org.

Gemäss kurzer Recherche im Internet müsste der CNAME erlaubt sein.
Weiss jemand was der Grund ist, dass Postfix meint den reverse Hostnamen
nicht finden zu können?

Gruss

tobi


Hallo Tobias,

ein CNAME ist erlaubt, die Frage die ich mir hier stelle, ist ein / im 
Domainnamen erlaubt?
der Grund warum hier ein derartiger Konstrukt verwendet wurde ist 
einfach der, daß ein IP-Range der nicht
auf einer Byte Grenze  in IPv4 ein /8 ein /16 oder /24 Subnetz vergeben 
wurde, und entsprechend

f. rDNS eine Krücke delegiert wurde ...
ich fürchte postfix stoßt sich an dem / im Domainnamen ...

ich hab in meinem LAN meinen eigenen DNS laufen, und f. das IP
Segment 192.168.0.0/24 natürlich rDNS Eintrage, und weil ich f. einen Teil
z.B. 192.168.0.1-192.168.0.31 DHCP Adressen vergebe und dafür vom DHCP
entsprechende rDNS Einträge setzen wollte hatte ich eine ähnliche Krücke

eine Anleitung dazu siehe hier:
https://books.google.de/books?id=0SIdBAAAQBAJ&pg=PA585&lpg=PA585&dq=DNS+not+byte+boundary&source=bl&ots=xlMTgw5j5h&sig=gYAahxqWCJS0DNB07zXNJ8DQk4I&hl=de&sa=X&ved=0ahUKEwj_4OL04OrTAhXF1hoKHTQzDwMQ6AEIIjAC#v=onepage&q=DNS%20not%20byte%20boundary&f=false

diesen Konstrukt hatte ich im LAN einfach dahingehend weggemacht,
indem ich auf 172.16.0.0/16 umgestellt habe,
und f. DHCP z.B. 172.16.100.0/24 verwende, und damit auf Byte-Grenzen bin

Grüße Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: *.Zip Files im Anhang blockieren und automatische Mitteilung an den Absender.

[Walter H.]

On 31.05.2017 18:09, Wolff, Lothar wrote:


Hallo

Ich möchte im Postfix einstellen

-Alle *.Zip Anhänge sind nicht blockiert

-Absender bekommt einen Hinweis dass er eine Zip Datei gesendet hatte,

die in das System nicht rein gelassen wird und das er diese bitte
nochmal in einem anderen Format senden möge usw. usw .

Wo kann man das am Besten im Postfix einstellen ?



Hallo ich hab etwas ähnliches als header_check bei mir realisiert ...

vielleicht hilft das:

if 
/^content-(disposition|type):[[:space:]](attachment|inline|[[:alnum:]\-]*\/[[:alnum:]\-]*);([[:space:]]|\r|\n)*[[:space:]]*(file)?name[[:space:]]*\=[[:space:]]*\"?(\=\?[[:alnum:]\-]*\?[[:alpha:]]\?)?([[:print:]]*)(\.|=2e)[[:alnum:]\{\-\}]+(\?\=)?\"?[[:space:]]*(;|$)/

/^content-(disposition|type):[[:space:]](attachment|inline|[[:alnum:]\-]*\/[[:alnum:]\-]*);([[:space:]]|\r|\n)*[[:space:]]*(file)?name[[:space:]]*\=[[:space:]]*\"?(\=\?[[:alnum:]\-]*\?[[:alpha:]]\?)?([[:print:]]*)(\.|=2e)(pdf)(\?\=)?\"?[[:space:]]*(;|$)/
OK
/^content-(disposition|type):[[:space:]](attachment|inline|[[:alnum:]\-]*\/[[:alnum:]\-]*);([[:space:]]|\r|\n)*[[:space:]]*(file)?name[[:space:]]*\=[[:space:]]*\"?(\=\?[[:alnum:]\-]*\?[[:alpha:]]\?)?([[:print:]]*)(\.|=2e)(\{[[:digit:]A-F]+[[:digit:]A-F\-]*[[:digit:]A-F]+\}|[[:digit:]]+|7z|ad[ep]|arj|asd|ax|ba[st]|bin|cab|ceo|cmd|c[oh]m|cpl|crt|dll|exe|hlp|ht[at]|in[fs]|jar|isp|jse?|lha|lnk|mde|ms[cipt]|ocx|pcd|pif|rar|reg|sc[rt]|sh[bs]|swf|url|vb[esx]?|vxd|ws[cfh]|(do[ct]|md[ab]|xl[as]|pp[st])x?)(\?\=)?\"?[[:space:]]*(;|$)/
PREPEND X-Hold-in-Queue: Suspicious '$2'-File=$4$5$6$7$8
endif

ich behandle hier auch andere File-Extensions, und an Stelle des PREPEND 
müsstest Du ein REJECT mit dem Hinweistext den Du haben willst, und 
natürlich die Erweiterungen welche Du nicht "behandelt" haben willst 
entfernen;


in der main.cf habe ich das da:

header_checks = pcre:/etc/postfix/hdr_chks.pcre
header_checks_size_limit = 131072
mime_header_checks = $header_checks
nested_header_checks =

Grüße,
Walter


smime.p7s
Description: S/MIME Cryptographic Signature

Re: *.Zip Files im Anhang blockieren und automatische Mitteilung an den Absender.

[Walter H.]

On 31.05.2017 18:44, Joachim Fahrner wrote:


Hallo Lothar,

wozu soll das gut sein? Manchmal muss man größere Datenmengen 
komprimieren um sie als Mailanhang verschicken zu können. Was soll der 
Absender denn dann nehmen? 7z? lzw? Was wäre dann bei anderen 
Kompressionsmethoden der Vorteil?



Hi,

das ist genau der legale usecase von 1-click-hostern udgl. dort die 
daten hinaufladen, und den Link zum Download per Mail schicken ...


Mail ist, auch wenn manche Mailserver meinen Mails mit 100 MB und mehr 
annehmen zu müssen, nicht für den

Datentransfer geschaffen worden ...


smime.p7s
Description: S/MIME Cryptographic Signature

Re: *.Zip Files im Anhang blockieren und automatische Mitteilung an den Absender.

[Walter H.]

On 01.06.2017 07:57, Joachim Fahrner wrote:


Am 2017-05-31 22:18, schrieb Walter H.:



Mail ist, auch wenn manche Mailserver meinen Mails mit 100 MB und 
mehr annehmen zu müssen, nicht für den

Datentransfer geschaffen worden ...


Genau aus dem Grund komprimiert man ja. Dann können aus den 100MB 
schnell mal 1MB werden.


bleib bitte realistisch, 90% Größenreduktion ist schon viel, aber 99% 
nur unter speziellen
Konstellationen, bei denen es dann keinen sinnvollen Use case gibt diese 
Daten per Mail zu versenden ...




smime.p7s
Description: S/MIME Cryptographic Signature

Re: *.Zip Files im Anhang blockieren und automatische Mitteilung an den Absender.

[Walter H.]

On 01.06.2017 18:53, Joachim Fahrner wrote:


Am 2017-06-01 16:38, schrieb Walter H.:

bleib bitte realistisch, 90% Größenreduktion ist schon viel, aber 99% 
nur unter speziellen
Konstellationen, bei denen es dann keinen sinnvollen Use case gibt 
diese Daten per Mail zu versenden ...


Die Diskussion ist fruchtlos. Muss jeder selber sehen, wie weit er 
seine Daten verkleinert kriegt. Bei MP3 und JPEG hast du null Chance, 
bei einem mysqldump kannst du extrem hohe Raten erreichen.


etwas zu komprimieren und etwas als "Mailbombe" zu versenden sind 2 Paar 
Schuhe ...


Was ich sagen wollte: es gibt Anwendungsfälle wo eine Komprimierung 
absolut Sinn macht (erlebe ich in der Arbeit täglich)


dessen Versendung aber in Zeiten, in denen es tatsächlich besser ist, 
jegliche Archivformate (egal welche Dateierweitung) zu blocken, in Frage 
zu stellen ist ...


und du die Daten ohne Komprimierung überhaupt nicht verschicken könntest!


die Frage: muss man etwas per Mail verschicken, nur weil man es kann?


Und ZIP-Files aus ideologischen Gründen (oder was auch immer) zu 
blockieren, ist völliger Unsinn. ZIP-files sind auch nicht 
"schädlicher" als PDF oder irgendeine andere Sorte Files.



relativ ...


Wer das glaubt, glaubt auch an Schlangenöl.

würde ich nicht sagen, mittlerweile kann man folgendes durchaus in 
Betracht ziehen:

was nicht zum Client kommt, kann auch keine Schwachstelle ausnützen ...

warten wir es ab, wenn wieder mal die End-to-End-Encryption-Fanatiker 
wiehern, weil
dann hast bei E-mail ohnehin verloren, und kannst Dir sämtliche 
Filermechanismen in die Haare schmieren ...




smime.p7s
Description: S/MIME Cryptographic Signature

Re: *.Zip Files im Anhang blockieren und automatische Mitteilung an den Absender.

[Walter H.]

On 01.06.2017 21:07, Joachim Fahrner wrote:


Am 2017-06-01 19:41, schrieb Walter H.:


die Frage: muss man etwas per Mail verschicken, nur weil man es kann?


Gegenfrage: soll man ein Päckchen mit der Spedition verschicken, wenns 
auch mit der Post geht?



Hermes, GLS, UPS, DPD ... sind ja nichts anderes wie Speditionen, und nun?

ein E-mail ist ausschließlich f. das konzipiert, das Du in einem 
Briefkuvert p. Post verschickst;




smime.p7s
Description: S/MIME Cryptographic Signature

Re: *.Zip Files im Anhang blockieren und automatische Mitteilung an den Absender.

[Walter H.]

On Fri, June 2, 2017 07:59, Joachim Fahrner wrote:
> Am 2017-06-02 05:12, schrieb Walter H.:
>
>>>
>>
>> ein E-mail ist ausschließlich f. das konzipiert, das Du in einem
>> Briefkuvert p. Post verschickst;
>
> In welcher RFC steht das?

da der Hausverstand in Europa zu Hause ist, in keinem :-)

Re: *.Zip Files im Anhang blockieren und automatische Mitteilung an den Absender.

[Walter H.]

On 02.06.2017 16:03, Joachim Fahrner wrote:

Am 2017-06-02 13:05, schrieb Walter H.:


da der Hausverstand in Europa zu Hause ist, in keinem :-)


Na dann ist ja alles gut. Was nicht in einer RFC steht hat im Internet 
keine Bedeutung. ;-)



dann solltest Dir RFC 2549 zu gemüte führen und erklären wie des mit 
Mailbomben geht :-)




smime.p7s
Description: S/MIME Cryptographic Signature

Ursache eines gelogten Fehlers in /var/log/maillog?

[Walter H.]

Hallo,

habe hier folgenden Eintrag in /var/log/maillog

Jun 12 08:02:33 mail master[1941]: setrlimit: Unable to set file
descriptors limit to -1: Operation not permitted

kommt das von Postfix oder vom Cyrus-IMAP?

Danke,
Walter

Re: AW: ebay-kleinanzeigen (war: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?)

[Walter H.]

On Thu, June 8, 2017 12:38, Patrick Ben Koetter wrote:

> über Unternehmen, die geschäftsmäßig Werbung für Kunden versenden, wird
> strittig diskutiert. Fakt ist, ob man sie nun mag oder nicht mag, sie
> erbringen ihre Dienstleistung auf Grundlage bestehender deutscher Gesetze.

nur, ist das Versenden eines Werbemails ohne expliziter
Bestellung/Zustimmung¹ durch den Empfänger unzulässig ...

es gilt hier die Opt-in Regel ...

> Sie arbeiten aktiv daran, z.B. den unsubscribe-Prozess zu vereinfachen
> und zu beschleunigen (siehe: ),
> weil
> ihnen klar ist wie wichtig 'saubere Mailings' für ihr Geschäft sind.

wenn sie ungefragt verschickt werden, macht es das nicht sauberer ...

¹ die Bestellung/Zustimmung hat auf freiwilliger Basis zu erfolgen und
darf nicht erzwungen² werden;

² die obligatorische Zustimmung zur Verarbeitung der Daten zu Werbezwecken
ist *nicht* zulässig ...

Re: AW: ebay-kleinanzeigen (war: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?)

[Walter H.]

On Mon, June 12, 2017 11:28, Joachim Fahrner wrote:

> Hat irgendjemand behauptet Emarsys würde die Newsletter ohne
> Bestellung/Zustimmung verschicken? Ich jedenfalls nicht.

es hat auch nie jemand ein Mail gesehen, bei dem Emarsys gefragt hätte, ob
man den Newsletter zustellen dürfe ...

wie gesagt der obligatorische Hacken "ich stimme der Nutzung meiner Daten
zu Werbezwecken zu" ist nicht zulässig;

Re: AW: ebay-kleinanzeigen (war: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?)

[Walter H.]

On 12.06.2017 18:00, Joachim Fahrner wrote:
Fakt ist: Emarsys scheint ein Dienstleister zu sein, der im 
Kundenauftrag Newsletter versendet.
es scheint nicht nur so, es ist auch so; und der Empfänger hat bei 
Emarsys NIE die Zustimmung erteilt ...
Ob eine Zustimmung vorliegt, sollte dann ja wohl der Auftraggeber 
prüfen (z.B. Online-Shop).
Falsch, es gilt das Datenschutzgesetz, welches eine Weitergabe von Daten 
grundsätzlich untersagt;

derartige Klauseln in AGBs sind illegal;

Man kann doch jetzt nicht Emarsys pauschal blockieren,

doch kann man ...




smime.p7s
Description: S/MIME Cryptographic Signature

Re: ebay-kleinanzeigen (war: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?)

[Walter H.]

On Tue, June 13, 2017 12:31, Robert Schetterer wrote:
> Am 13.06.2017 um 11:49 schrieb Patrick Ben Koetter:
>> * Joachim Fahrner :
>>> Fakt ist: Emarsys scheint ein Dienstleister zu sein, der im
>>> Kundenauftrag
>>> Newsletter versendet. Ob eine Zustimmung vorliegt, sollte dann ja wohl
>>> der
>>> Auftraggeber prüfen (z.B. Online-Shop). Man kann doch jetzt nicht
>>> Emarsys
>>> pauschal blockieren, nur weil vielleicht ein Kunde die Regeln nicht
>>> ganz so
>>> strikt ausgelegt hat, wie einige Erbsenzähler das hier tun. Bleibt doch
>>> mal
>>> auf dem Teppich!
>>
>> Zur Ergänzung: Die Kunden stellen die Adressliste! Der ESP bietet den
>> Service
>> des Versands mit Auswertung etc. Dabei darf der ESP dem Kunden aus
>> gesetzlichen Gründen nicht mitteilen welche Adressen bounces etc.
>> generieren.
>
> Nicht dein Ernst ?

ist eigentlich die Reinheit der Logik, würdest Du ein Unternehmen
beauftragen Kataloge zu produzieren und zu versenden, dann geht dich auch
das nichts an, welche Kataloge nicht zugestellt werden können ...

hättest sie hingegen selbst zum Versand zur Post gebracht, dann würdest Du
auch wissen, welche nicht zugestellt werden können ...

bei E-mail nicht anders ...

Re: ebay-kleinanzeigen (war: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?)

[Walter H.]

On Tue, June 13, 2017 14:14, Marco Dickert wrote:
> On 2017-06-13 13:41:57, Walter H. wrote:
>> ist eigentlich die Reinheit der Logik, würdest Du ein Unternehmen
>> beauftragen Kataloge zu produzieren und zu versenden, dann geht dich
>> auch
>> das nichts an, welche Kataloge nicht zugestellt werden können ...
>>
>> hättest sie hingegen selbst zum Versand zur Post gebracht, dann würdest
>> Du
>> auch wissen, welche nicht zugestellt werden können ...
>
> Wo genau ist der Unterschied ob ich die Kataloge über das Unternehmen XY
> oder
> über das Unternehmen "Deutsche Post" verschicke?

gar keiner, aber das habe ich auch nicht geschrieben ...

> Solange ich die
> Zieladressen
> vorgebe, sollte ich wissen dürfen, welche Adresse nicht erreichbar ist.

ja wenn Du auch der Absender bist; bist Du aber im Fall daß Du die
Kataloge nicht selbst zur Post oder zum Versanddienstleister zum Versand
bringst aber nicht ...

darum habe ich auch geschrieben die Kataloge produzieren *und* versenden ...

um wieder ins andere Paradigma zu schwenken, beauftragst Du ein
Unternehmen einen Newsletter zu versenden, geht es dich auch nichts an
welche Adressen nicht gehen, weil Du damit auch das Risiko dass der
Mailserver geblockt, gesperrt, oder sonst einer Liste landet an das
Unternehmen zum Newsletterversand abgetreten hast ...

wobei diese Branche ohnehin einen zweifelhaften Ruf hat; ein Bsp. aus
meiner jüngsten Vergangenheit ...

der Versand von MehrwertSMS wurde gekippt und jetzt kann man jede SMS
kostenfrei empfangen ...
als Absendernummer steht dann einfach nur ein Text wie z.B. 'Info'
diese SMS waren obszönen Inhalts und mit sowas wie "Antworte mit HUGO an
0930.." am Textende ...
tägl ein od. 2 solcher SMS, und erst nachdem ich  juristische Schritte
gegen den Laden, der bei der Regulierungsbehörde als Inhaber der 0930...
Nummer aufscheint, androhte, war auf einmal Ruhe ...

sowas zeigt halt dann schon in welchem Graubereich des Rechts hier
operiert wird ...

Re: Email Pot in bei mails an Support

[Walter H.]

On Wed, June 14, 2017 09:03, simoon wrote:
> Hi,
>
> ich würde es gerne so einrichten das bei mails an eine unserer support
> emails der kunde vom mailserver eine mail mit bestätigungslink zurück
> bekommt den er clicken muss damit die mail ins postfach kommt. Hat da
> jemand eine Lösung für?
>
> Wir haben postfix, dovecot, amavis und spamassassin in der config.
>
> Gruss
>
> Alex
>
>
>
sollte nicht allzuschwierig sein - ich habe sowas wie e...@tu-berlin.de -
implementiert, und da habe ich die komplette Mail, welche ich nur als
echo-reply verwende, diese müsste ich einfach speichern, und beim
Reply-Mail, würde der Link ein Skript aufrufen, welches das vorhin
gespeicherte Mail in die Queue gibt ...
das wäre es eigentlich, einen apache würdest in der config da aber auch
noch brauchen ...

Re: Phishing Mails von der FAZ?

[Walter H.]

On 18.06.2017 09:10, Robert Schetterer wrote:

dig -t mx faz.net

dig -t mx faz.de

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> -t mx faz.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46358
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;faz.de.IN  MX

;; ANSWER SECTION:
faz.de. 21600   IN  MX  45 mailserver2.faz.de.
faz.de. 21600   IN  MX  45 mailserver1.faz.de.

;; AUTHORITY SECTION:
faz.de. 86400   IN  NS  dns.globvill.de.
faz.de. 86400   IN  NS  dns.voerde.globvill.de.

;; ADDITIONAL SECTION:
dns.voerde.globvill.de. 75927   IN  A   212.20.160.2
dns.voerde.globvill.de. 75927   IN  2001:40b8::21

;; Query time: 141 msec
;; SERVER: 172.23.1.11#53(172.23.1.11)
;; WHEN: Sun Jun 18 10:50:31 2017
;; MSG SIZE  rcvd: 176



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Phishing Mails von der FAZ?

[Walter H.]

On 18.06.2017 07:52, Joachim Fahrner wrote:

Kann das sein?
Habe heute eine Phishing Mail von mail.faz.net bekommen. Ähnlich wie 
die hier: http://zy0.de/q/46.163.116.28 

außer ein Outdated browser kommt hier nichts ...



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Absender "Displayname" umschreiben mit Variable

[Walter H.]

On 22.06.2017 14:26, Marc Risse wrote:

Hallo Liste,

ich dachte mir ich baue da mal schnell was, verzweifele jetzt aber. 
Ich möchte für eine Vielzahl von Linux-Servern eine Standard-Config 
ausrollen. Diese Server haben nur Postfix an Board um den Admin zu 
informieren, also für Cron etc.
Da wir für unsere Server mehrere eigene DNS-Zonen betreiben (.server, 
.lanserver .etc) und ich auf dem zentralen Mailrelay Mails mit 
"solchen" Zonen zurückweise, habe ich folgendes gebaut:


myorigin  = /etc/mailname
mydestination = localhost, $myhostname
relayhost = relay.foo.de
sender_canonical_maps = regexp:/etc/postfix/sender_canonical

/etc/postfix/sender_canonical:
/./ nore...@foo.de


nore...@foo.de ist auf dem zuständigen Relay ein blackhole, also 
/dev/null


Das ganze Funktioniert! Die Mails haben einen ordentlichen absender 
und werden ordentlich zugestellt. Antworten (Autoreply etc) werden 
direkt vernichtet. Super!
Jetzt beschweren sich die Admins allerdings, dass im FROM leider immer 
"root " steht. Statt des Displaynames sollte dort der 
Hostname des sendenden Servers stehen, also ein FROM à la 
"WEB53.SERVER ".


dann sagst Du einfach, daß sender_canonical nur den Envelope-Sender 
umschreibt


sender_canonical_classes = envelope_sender




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Phishing Mails

[Walter H.]

On 01.07.2017 09:14, Joachim Fahrner wrote:

Hallo,

so langsam wird das hier zum (unfreiwilligen) Hobby mit den 
Phishing-Mails.


Ich frage mich gerade, warum das hier nicht abgewiesen wurde:

Received: from mail.sicherheit.de (unknown [83.169.1.6])

Die IP hat zwar einen Reverse pointer zu mail.sicherheit.de:

$ host 83.169.1.6
6.1.169.83.in-addr.arpa domain name pointer mail.sicherheit.de.

Aber mail.sicherheit.de hat eine ganz andere IP:

$ host mail.sicherheit.de
mail.sicherheit.de has address 72.52.10.14


der Klassiker, wobei die Ursache nicht mal zwingend bösartig war;
dies geschieht z.B. schon dadurch, wenn jemand mit seiner Domain zu 
einem anderen Hoster umzieht und
beim alten Hoster die reverse DNS Einträge nicht zurückgesetzt/geändert 
werden ...

(wobei das dann irgendwie der Beweis f. IPv4s im Überfluss wäre)

Sowas müsste sich doch blocken lassen. Ist das nicht Bestandteil von 
reject_invalid_helo_hostname?


damit blockierst nur die Mails, welche beim HELO eine Domain angeben, 
die es im DNS entweder nicht gibt oder

sonst was ...
wenn da jemand weil er lustig ist eben   mail.sicherheit.de angibt, geht 
das durch, wie Du ja selbst erkannt hast,

gibt es die;

interessanter wäre ein Mechanismus, der exakt die Mails durchläßt, wo 
die IP einen reverse DNS ergibt,

welcher tatsächlich ein forward DNS wieder diese IP ergibt ...
(damit hast den ganzen Quark, wo jemand irgendwas vorgaukelt, weg)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Phishing Mails

[Walter H.]

On 01.07.2017 12:48, Robert Schetterer wrote:

Am 01.07.2017 um 12:45 schrieb Robert Schetterer:

Am 01.07.2017 um 09:55 schrieb Walter H.:

On 01.07.2017 09:14, Joachim Fahrner wrote:

Hallo,

so langsam wird das hier zum (unfreiwilligen) Hobby mit den
Phishing-Mails.

Ich frage mich gerade, warum das hier nicht abgewiesen wurde:

Received: from mail.sicherheit.de (unknown [83.169.1.6])

Die IP hat zwar einen Reverse pointer zu mail.sicherheit.de:

$ host 83.169.1.6
6.1.169.83.in-addr.arpa domain name pointer mail.sicherheit.de.

Aber mail.sicherheit.de hat eine ganz andere IP:

$ host mail.sicherheit.de
mail.sicherheit.de has address 72.52.10.14


der Klassiker, wobei die Ursache nicht mal zwingend bösartig war;
dies geschieht z.B. schon dadurch, wenn jemand mit seiner Domain zu
einem anderen Hoster umzieht und
beim alten Hoster die reverse DNS Einträge nicht zurückgesetzt/geändert
werden ...
(wobei das dann irgendwie der Beweis f. IPv4s im Überfluss wäre)


Sowas müsste sich doch blocken lassen. Ist das nicht Bestandteil von
reject_invalid_helo_hostname?

damit blockierst nur die Mails, welche beim HELO eine Domain angeben,
die es im DNS entweder nicht gibt oder
sonst was ...
wenn da jemand weil er lustig ist eben   mail.sicherheit.de angibt, geht
das durch, wie Du ja selbst erkannt hast,
gibt es die;

interessanter wäre ein Mechanismus, der exakt die Mails durchläßt, wo
die IP einen reverse DNS ergibt,
welcher tatsächlich ein forward DNS wieder diese IP ergibt ...
(damit hast den ganzen Quark, wo jemand irgendwas vorgaukelt, weg)



  http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname

Reject the request when the client IP address has no address->name mapping.
This is a weaker restriction than the reject_unknown_client_hostname
feature, which requires not only that the address->name and
name->address mappings exist, but also that the two mappings reproduce
the client IP address.
The unknown_client_reject_code parameter specifies the response code for
rejected requests (default: 450). The reply is always 450 in case the
address->name lookup failed due to a temporary problem.
This feature is available in Postfix 2.3 and later.


sorry der isses

http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname


reject_unknown_client_hostname (with Postfix<  2.3: reject_unknown_client)
 Reject the request when 1) the client IP address->name mapping
fails, 2) the name->address mapping fails, or 3) the name->address
mapping does not match the client IP address.
 This is a stronger restriction than the
reject_unknown_reverse_client_hostname feature, which triggers only
under condition 1) above.
 The unknown_client_reject_code parameter specifies the response code
for rejected requests (default: 450). The reply is always 450 in case
the address->name or name->address lookup failed due to a temporary
problem.

schon ewig nimmer nachgesehen

das gibt real aber zuviel Aerger, wenn man den anwenden will sollte man
vorfiltern, also nicht per se auf alles anwenden !



ich hab bei meinem der im Internet als mein SMTP (mit TLS Port 587) und 
als MX (Port 25) f. die selbe Domain fungiert folgendes


smtpd_delay_reject = yes

smtpd_helo_required = yes

smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_unknown_hostname, reject_non_fqdn_helo_hostname


smtpd_client_restrictions = permit_mynetworks, 
reject_unknown_client_hostname

smtpd_etrn_restrictions = permit_mynetworks, reject

smtpd_sender_restrictions = check_sender_mx_access 
cidr:/etc/postfix/drop.cidr, check_sender_ns_access 
cidr:/etc/postfix/drop.cidr, reject_non_fqdn_sender, 
reject_unknown_sender_domain


smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_non_fqdn_recipient, 
reject_unauth_destination, reject_unknown_recipient_domain, 
check_recipient_access hash:/etc/postfix/recipient_access, reject


smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_unauth_destination, reject_unknown_recipient_domain


in /etc/postfix/main.cf

mit

wget -q -nd --output-document=- http://www.spamhaus.org/drop/drop.lasso 
|awk '/; SBL/ { printf( "%s\tREJECT %s\n", $1, $3 ) }' 
>/etc/postfix/drop.cidr


aktualiser ich von Zeit zu Zeit /etc/postfix/drop.cidr

wobei vieles kommt gleich gar nicht zum Tragen, weil ich im Falle, daß 
da wirres Zeug per SSH od. HTTP(S) daherkommt (per logwatch mitgeteilt),

ich den gesamten Range der zu einzelnen IPs gehört z.B.
so
-I INPUT -i eth0 -s 1.171.0.0/16 -j DROP
in der IPtables Firewall blockier





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Phishing Mails

[Walter H.]

On 01.07.2017 16:47, Joachim Fahrner wrote:

Am 2017-07-01 15:55, schrieb Robert Schetterer:


also wenn man das verwenden will ist es klug vorher zu filtern
zb mit

smtpd_restriction_classes

oder einem policy server , milter etc


Ok. Aber ich steh da wohl grad auf der Leitung. Nach welchen Kriterien 
sollte man da filtern? Wen prüft man damit, und wen lässt man an der 
Prüfung vorbei?


Jochen 
ich denke er meint, daß es durchaus möglich ist, daß es Mails gibt, 
welche berechtigterweise kommen, aber durch dieses harte blocken aber 
fehlschlagen,
wobei ich mir die Frage stelle, ob ein Mailserver überhaupt eine 
Existenzberechtigung hat, wenn er sich mit
HELO  meldet und dieses  nicht dessen DNS Name ist und die IP 
Adresse welche connected im Reverse DNS ebensowenig  entspricht ...





smime.p7s
Description: S/MIME Cryptographic Signature

Re: SPF - "It is impossible for us to say why it was rejected."

[Walter H.]

On 10.07.2017 15:11, Marc Risse wrote:

Hallo Joachim,

genau deshalb verstehe ich es nicht. DNS in alle möglichen Richtungen 
funktioniert auch ohne Probleme. Ich durchsuche gerade die 
Mailinglisten von OpenSPF, vielleicht finde ich dort etwas. Einen 
Bugtracker habe ich nicht finden können.


:-(


bei dem DNS Eintrag

ruhr-uni-bochum.de  text = "v=spf1 
exists:%{ir}.%{v}._spfx.ruhr-uni-bochum.de 
exists:%{ir}._ip.%{l}._spfx.ruhr-uni-bochum.de -all"


würd ich auch WO geben ...

wie kommt man eigentlich auf eine derartige Paranoia das so zu verkorksen?

ein  "v=spf1 mx -all" oder ähnlich einfaches würde es auch tun ...



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Greylisting

[Walter H.]

On 11.07.2017 17:51, Joachim Fahrner wrote:
Langsam komme ich ins Grübeln, ob ich das nicht doch generell wieder 
für alles aktivieren soll. Ich bekomme in letzter Zeit häufig Spam und 
Phishing von "echten" Mailservern (wurden die gehackt?), für die 
Greylisting nicht angewandt wurde,

in welchen Ländern sind diese "echten" Mailserver?
mich wundert es nur, bei meinem Mailserver - ok diese Domain kräht kein 
Hahn vom Dach - sieht Logwatch typischerweise so aus:



  259   *Warning: Pre-queue content-filter connection overload 
--
  256  After AUTH
  256 unknown
2  After CONNECT
2 unknown
1  After RCPT
1 unknown

1   Reject relay denied 
-
1  50.246.210.5750-246-210-57-static.hfc.comcastbusiness.net
1cookie.nick2...@outlook.com

1   Reject HELO/EHLO 

1  Host not found
1 67.244.24.104cpe-67-244-24-104.nyc.res.rr.com
1192.168.0.155

1   Reject unknown client host 
--
1  unknown
1 192.168.98.169
1...@tea.com
1eax...@yahoo.com

21040   Connections lost 

21039  After AUTH
21039 cpe-67-244-24-104.nyc.res.rr.com
1  After RCPT
1 cpe-67-244-24-104.nyc.res.rr.com

2   Sent via SMTP 
---
2  meine.1te.Domain
1 calcbox-worker
1calc...@vhost.mail
1 vhost-root
1root

3   Timeout (inbound) 
---
3  After AUTH
3 cpe-67-244-24-104.nyc.res.rr.com

2   Hostname verification errors 

2  Address not listed for hostname
1 89.248.160.12serv-kobrekim.com
1 139.162.99.243   scan.security.ipip.net

2   Host offered TLS 

2  smtp.vom.Webhoster


demnach nur gescheiterte Versuche diesen als Relay zu vergewaltigen ...



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Mario Rönsch

[Walter H.]

On 18.07.2017 18:32, Joachim Fahrner wrote:
Ich hab keinen Plan wie ich den effektiv blocken kann. Ich weiß auch 
nicht wie er es schafft unter dem Radar diverser Blacklists zu 
bleiben. Wahrscheinlich, weil seine Adressen eben echte Adressen sind 
und keine Honigtöpfe.

Hat jemand eine Idee?

wenn Du die Domains schon kennst, einfach die sperren ...
header_checks und FROM eben auf .ru, fertig ...

Das ist eine aktuelle Mail von ihm:


eigentlich ein Maillogauszug ...

Jul 18 18:06:04 server postfix/postscreen[8738]: ...

wie sieht wirklich so eine Mail (Mail-Header) aus?



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Microsoft ESMTP MAIL Service

[Walter H.]

On Mon, July 24, 2017 12:27, Joachim Fahrner wrote:
> Hat hier schon mal jemand was mit dem im Betreff genannten Mailserver zu
> tun gehabt?
des is'nen Teil vom MS-Exchange ...

> Der benimmt sich ja merkwürdig.
> Im Envelope-From setzt der ein "prvs=[Hexstring]=" vor den eigentlichen
> Absender. Was soll denn das?
> Und wenn mein reject_unverified_sender versucht dem etwas zuzustellen,
welche Bedeutung soll denn bitte reject_unverified_sender beim Absenden
(übergeben der Mail an Smarthosts, MX-Servern, ...) haben?
Config-Fehler?
> dann kommt folgendes als Antwort:

>
> RCPT from mx00.pricosoft.com[80.152.164.96]: 450 4.1.7
> : Sender address rejected: unverified
> address: host mx00.pricosoft.com[80.152.164.96] said: 451 4.7.1
> : Recipient address rejected: Throttling
> too many connections from new source -  Try again later. (in reply to
> RCPT TO command)

ist das der Logeintrag in DEINEM Postfix, wie Du die Mail dorthin schickst?

Re: Microsoft ESMTP MAIL Service

[Walter H.]

On 24.07.2017 15:29, Joachim Fahrner wrote:
Ob wohl ich ja grundsätzlich irgendwie der Meinung bin "warum sollte 
ich Mails annehmen auf die ich nicht antworten kann"? (oder die im 
Envelope behaupten von jemand anders zu sein).



hat nur den Pferdefuß, daß Du dir dabei selbst eine trittst ... ,
spätestens wenn ausgehender Mailserver vom Sender ein anderer ist als 
der eingehende Mailserver;
(der Mailserver, der Dir eine Mail geben will, wird NIE eine von anderen 
Hosts annehmen)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: AW: AW: Microsoft ESMTP MAIL Service

[Walter H.]

On 24.07.2017 17:05, Joachim Fahrner wrote:

Am 2017-07-24 16:47, schrieb Uwe Drießen:

disable_vrfy_command (default: no)

Disable the SMTP VRFY command. This stops some techniques used to
harvest email addresses.

Example:

disable_vrfy_command = no

Fremde bei mir


Lies nochmal genau was ich geschrieben/zitiert habe. Die Sender 
address verification benutzt NICHT das SMTP VRFY Kommando, sondern 
versucht ganz normal mit RCPT TO eine Mailzustellung. Deswegen schützt 
du dich eben nicht gegen solche Verifikation. Da täuscht du dich. 
was soll das bringen, wenn damit eine Mailzustellung - eigentlich 
sinnlos - verzögert wird?
die andere Seite, muss ja nicht sofort annehmen, und damit schaukelt 
sich etwas auf, was nicht wirklich Sinn macht;
spätestens dann, wenn Du z.B. einen Link zum aktivieren von irgendwas 
bekommst und dieser nur 1 Stunde gültig ist,
und auf die Art es aber mehr als diese 1 Stunde dauert bis die Mail 
erfolgreich zugestellt werden kann ...

macht ja keinen Sinn ...






smime.p7s
Description: S/MIME Cryptographic Signature

Re: Microsoft ESMTP MAIL Service

[Walter H.]

On 24.07.2017 19:36, Joachim Fahrner wrote:

Am 2017-07-24 19:24, schrieb Robert Schetterer:

Jochen , wenn du meinen Server staendig nach mail adressen befragst die
nicht existieren, sperre ich deinen Server weil das wiederum Abuse ist
und melde wiederum deinen Server auf eine RBL


Wieso?

na ja im Envelope passiert ja nur sowas:

EHLO 
reply
MAIL FROM: <...>
reply
RCPT TO: <>
reply
QUIT
reply

und das würde ich als Abuse sehen ...

folgendes sollte hoffentlich nicht passieren, wäre als DDoS durchaus denkbar

ein Botnetz versucht bei Dir Mails abzuladen - mit den verschiedensten 
Absendern,
und das nicht nur auf Deinem Server sondern auch auf vielen, und jetzt 
hast das kartesische Produkt
jeder dieser Ziel-Mailserver veranstaltet mit den bestimmten 
Absender-Servern das Spielen von oben ...

und schwupp, sind diese alle auf einer Liste ...


Du bekommst doch von mir nicht mehr Anfragen als du mir Mails 
schickst. Und zwar pro Absenderadresse nur einmal eine Anfrage. Und 
wenn andere deine Mailadressen massenhaft misbrauchen, dann schütze 
deine Domain eben mit SPF oder DMARC.


SPF ist so gut wie die potentiellen Zielserver der SPAM-Industrie es 
auch implementiert haben ...
DMARC bringt gar nix, ich betrachte nur die vielen Mails, welche als 
Antwort meiner Mails an Maillisten wie diese hier gehen ...
wobei dieser Server hier zumindest was bestimmte Eigenschaften angeht 
korrekt implementiert ist -> signierte Mails kommen auch als signierte 
an ...


Außerdem ändern sich die Zeiten. Spammer müssen heute keine Absender 
mehr erfinden. Die nehmen real existierende Adressen. 
klar, weil sie ja durch sämtliche Mechanismen (SPAMfilter, ...) 
durchkommen wollen ...
Anders bei den Phishing-Betrügern, die wollen ja möglichst unentdeckt 
bleiben. Die erfinden dann so Absender wie "sparka...@autolederer.de". 
Wichtig ist denen, dass Wörter wie "Sparkasse" (oder was sie halt 
gerade abphishen wollen) möglichst oft auftaucht, damit man nicht 
mistrauisch wird.


wenn man bei dem sender_verify ohnehin eine whitelist braucht, kann man 
diese gleich direkt haben,

und alles andere direkt blockieren ...
indem man einfach per IPtables was auch immer nur die Mailserver zuläßt 
von wo man Mails erwartet ...

(wer seinen eigenen privaten Mail server betreibt ist damit am besten dran)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Microsoft ESMTP MAIL Service

[Walter H.]

On 24.07.2017 21:02, Joachim Fahrner wrote:

Am 2017-07-24 20:51, schrieb Robert Schetterer:


das Verfahren ist wirklich nur im absoluten
Einzelfall sinnvoll,


Was verstehst du denn unter "Einzelfall"? Eine bestimmte Installation, 
so wie meine, oder für bestimmte Absenderdomains? Letzteres halte ich 
für wenig sinnvoll, denn die Verifizierung macht ja erst bei 
unbekannten Absendern Sinn. Bei bekannten Absendern kann ich auch 
direkt hart sperren.
eigentlich nur bei bestimmten Absenderdomains wie z.B. gmx, gmail, 
yahoo, ... macht es Sinn;

und andere Absender sind entweder direkt hart gesperrt oder eben nicht;



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Microsoft ESMTP MAIL Service

[Walter H.]

On 24.07.2017 22:06, Martin Steigerwald wrote:

Hallo Walter.

Walter H. - 24.07.17, 20:09:

Anders bei den Phishing-Betrügern, die wollen ja möglichst unentdeckt
bleiben. Die erfinden dann so Absender wie "sparka...@autolederer.de".
Wichtig ist denen, dass Wörter wie "Sparkasse" (oder was sie halt
gerade abphishen wollen) möglichst oft auftaucht, damit man nicht
mistrauisch wird.

wenn man bei dem sender_verify ohnehin eine whitelist braucht, kann man
diese gleich direkt haben,
und alles andere direkt blockieren ...
indem man einfach per IPtables was auch immer nur die Mailserver zuläßt
von wo man Mails erwartet ...
(wer seinen eigenen privaten Mail server betreibt ist damit am besten dran)

Huch, und wer bemerkt dann, falls ein Server-Admin einen dieser Server auf
eine andere IP oder einen anderen Hostnamen/Domain umzieht?

wenn es wichtig ist, wirst Du es mitbekommen, ansonsten ist es unwichtig ...


Bei Ablehnung via
Postscreen oder Ähnliches sehe ich das dann wenigstens im Log.

bei IPtables auch ..., ist nur ein anderer;

Nun, bei vielen Mailinglisten freier Software-Projekte würde ich das ja noch
bemerken, aber bislang kam in meinen privaten Mailserver auch nicht soviel
Mail rein,
bei meinem kam bis jetzt gar keine rein, aber tausende Versuche ihn als 
Relay zu mißbrauchen,
welche damit auch abgestellt sind (auch Versuche via Port 80 udgl. etwas 
zu erreichen) ...



Und auch so… eine Whitelist aller Server, von denen ich Mail erwarte… das sind
*Einige*. Ich denke, den Aufwand möchte ich mir nicht machen.

wie Du meinst ...



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Address verification

[Walter H.]

On 25.07.2017 21:18, Joachim Fahrner wrote:
Ich mach mal einen neuen Thread auf, da das jetzt nix mehr mit dem M$ 
Exchange zu tun hat.


Hier habe ich eine schöne Erklärung gefunden, wie die Adress 
Verifikation ablaufen sollte:


http://www.fsf.org/about/systems/sender-verification

Unter "Misconfiguration #1" kann man lesen: wenn jemand keine Antwort 
erhalten möchte (z.B. auf einen Newsletter-Versand), dann muss er nach 
RFC den Null-Absender verwenden. Er darf keine Adresse verwenden die 
bei ihm nicht existiert.


Jochen
der NULL-Absender hat einen Pferdefuß, ein Mailserver muss diese Mails, 
welche

keine Fehler von durch ihn generierten Mails darstellen nicht annehmen;

ein gut konfigurierter Newsletter-Server verwendet als Absender im 
Mail-Envelope seine eigene Domain,
f. welche er nach SPF auch befugt ist, Mails abzusenden;
devn...@domain.tld ist ja möglich, und devnull wird einfach

in den Shredder /dev/null bevördert ...

genau das mache ich auch bei meiner 2ten Domain, welche nur zum 
Mailserver meiner

1ten Domain (beim Webhoster) weiterleitet ...



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Address verification

[Walter H.]

On 25.07.2017 22:08, Joachim Fahrner wrote:

Am 2017-07-25 21:59, schrieb Martin Steigerwald:

Whoa!

Ich denke da fallen *sämtliche* legitimen Newsletter, die ich 
bekomme, raus.


Weil da heißt es oft "noreply@domain".


Das sagt noch nix. Ich hab mal einige bei mir getestet (mit einem 
Script), und diese noreply-Adressen existieren alle. Die liest halt 
dort nur keiner, landen wahrscheinlich direkt im Papierkorb.
das ist auch die übliche Vorgehensweise, Mails welche automatisiert 
gesendet werden,
aber niemand aktiv Mails, welche an diese Mail-Adresse geschickt werden, 
lesen will/soll/kann;

aber als NULL-Sender sollen diese nicht versendet werden ...
noreply@... ist dabei das meist verbreitetste, was hier verwendet wird;



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Address verification

[Walter H.]

On 26.07.2017 15:49, Joachim Fahrner wrote:

Am 2017-07-26 14:51, schrieb Walter H.:


das ist auch die übliche Vorgehensweise, Mails welche automatisiert
gesendet werden,
aber niemand aktiv Mails, welche an diese Mail-Adresse geschickt
werden, lesen will/soll/kann;
aber als NULL-Sender sollen diese nicht versendet werden ...
noreply@... ist dabei das meist verbreitetste, was hier verwendet wird;


Die Regel ist eigentlich ganz einfach: Der Return-Path muss entweder 
eine gültige Adresse sein, oder leer.
das ist ein Feld im Mail Header, welches zum Zeitpunkt der Sender 
Verification an Hand des MAIL FROM vom Mail-Envelope noch gar nicht 
bekannt ist ...

Beides ist erlaubt.
klar, die höfliche Art ist, wenn die Mailadresse im Envelope (MAIL FROM) 
im Mailheader (Return-Path) und im Mailheader (From) ident sind¹;
aber Mailing lists haben, auf Grund der SPF das Problem, daß sie z.B. 
meine Mail nicht weiterschicken dürfen, weil im SPF eindeutig festgelegt 
ist,
daß dies nur die Mailserver von meinem Mailhoster dürfen, gilt hier die 
sinnvolle Ausnahme, daß der Return-Path im Mail-Header und das
MAIL FROM vom Mail-Envelope auf eine güiltige Mail-Adresse der 
Mailing-Liste gesetzt werden ...


warum es hier Pfusch ist, den Return-Path unverändert zu lassen:
ganz einfach: eine Fehlernachricht, welche z.B. weil Dein Postfach voll 
ist, oder weil Du z.B. einen Abwesenheitsassistenten mit "ich bin auf 
Urlaub" aktiv hast,

bei den Mitgliedern der Mailingliste defintiiv Fehl am Platz sind ...

ich denke hier haben einige Maillinglisten deren Server falsch 
konfiguriert ...


¹ eine Besonderheit gilt hier, Mails in Vertretung abzusetzen, dazu gibt 
es im Mail-Header ein weiteres Feld², und zusätzlich das Reply-To; von 
daher würde ich ein Reply-To welches sich nicht mit dem weiterfen Feld 
deckt, oder das weitere gar nicht vorhanden ist, als SPAM klassifizieren,

gibt sonst keinen sinnvollen Use-Case, welcher ein Reply-To rechtfertigt ...

² dieses nennt sich:  Sender:, man findet auch etwas von On-Behalf-Of: 
was aber proprietär ist


z.B.
From: 
To: 
Sender: 
Reply-to: 
Subject: Test

was in Mail-clients die damit umgehen können - z.B. MS-Outlook - etwa so 
angezeigt wird:


Von:  off...@company.com im Auftrag von root@localAn: walter@local
Betreff: Test

Will jemand keine Antworten zurück haben, dann muss der Return-Pfad 
leer sein. Eine Phantasie-Adresse (die dann bouncen würde) ist nicht 
erlaubt.

auch klar;
und wenn der Return-Path leer ist, und sie nicht das Resultat (z.B. ein 
Fehler, weil Postfach voll, ...)
eines vom Mailserver weggehenden Mails ist,  kann die Mail verworfen 
werden ...


wie ich im anderen Post geschrieben habe, ein NULL-Sender ist, wenn es 
um keine Fehler geht, Unfug;




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Address verification

[Walter H.]

On 26.07.2017 19:32, Joachim Fahrner wrote:

Am 2017-07-26 18:21, schrieb Walter H.:


klar, die höfliche Art ist, wenn die Mailadresse im Envelope (MAIL
FROM) im Mailheader (Return-Path) und im Mailheader (From) ident
sind¹;


Das ist beides das gleiche.

es sollte so sein, ist aber nicht zwingend ...



wie ich im anderen Post geschrieben habe, ein NULL-Sender ist, wenn es
um keine Fehler geht, Unfug;


Nein, kein Unfug. Oder steht das in irgendeiner RFC? E-Mail ist wie 
ganz normale Schneckenpost.
richtig und Schneckenpost ohne Absender am Kuvert bin ich genausowenig 
verpflichtet anzunehmen, als ein Mailserver solche Mails mit NULL-Sender 
annehmen muss, wenn es nicht von ihm verursacht wurde ...


das wär ja traurig, weil damit könntest Dir SPF und Co in die Haare 
schmieren, weil SPAM immer den NULL-Sender verwenden würde, weil ja 
angenommen werden müsste ...
Wenn ich möchte, dass ein unzustellbarer Brief an mich zurück geht, 
dann schreibe ich meinen Absender auf den Umschlag
Du gehst hier davon aus, daß die Zieladresse falsch sein kann, wir reden 
von korrekter Empfängermailadresse ...
. Wenn ich das nicht will, dann schreibe ich eben keinen drauf, kann 
mich dann aber auch nicht beschweren, wenn der Postbote den bei 
Unzustellbarkeit in den Müll wirft. Was ich aber nie machen darf: 
klar darfst Du das, Mails ohne Absender oder mit NULL-Sender musst Du 
nicht annehmen, spätestens, wenn Du einen Smarthost mit 
Authentifizierung hast, ist es sogar unmöglich ..., weil wie soll die 
Authentifikation von statten gehen, wenn Du den NULL-Sender verwendest ...
irgendeinen frei erfundenen Absender auf den Umschlag schreiben. Was 
soll das bringen?
wir reden vom NULL-Sender und das ist eben KEIN Absender auf dem 
Umschlag ...






smime.p7s
Description: S/MIME Cryptographic Signature

header_check und Nichtexistenz eines Eintrags?

[Walter H.]

Hallo,

wie kann man sehr einfach mittels header_checks prüfen, ob im Mail ein
To: ...
vorkommt?
und genau dann wenn es NICHT vorkommt, ein REJECT ...

Danke,
Walter

Re: header_check und Nichtexistenz eines Eintrags?

[Walter H.]

On 17.10.2017 13:59, Kai Fürstenberg wrote:

Hallo,

Am 17.10.2017 um 13:40 schrieb Walter H.:

wie kann man sehr einfach mittels header_checks prüfen, ob im Mail ein
To: ...
vorkommt?
und genau dann wenn es NICHT vorkommt, ein REJECT ...

mit header_checks kannst du das nicht prüfen, dafür müsste Postfix einen
Überblick über alle Zeilen des Headers haben, er prüft aber nur eine
nach der anderen und siehr damit immer nur eine Zeile.

ja diese Eigenschaft bzw. dieses Verhalten ist mir bekannt;

Eine Möglichkeit wäre, das über eine Spamassassin-Regel zu realisieren.
bei Spamassassin habe ich es bis jetzt nur geschafft, daß Mails als SPAM 
markiert werden ...


wie blockiert man Mails - mit entsprechenden Bedingungen - damit?

Danke,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Vor- und Nachteile von check_recipient_access gegenüber '/dev/null'

[Walter H.]

Hallo,

habe folgendes in der main.cf (der Mailserver ist f. 2 Domains als MX im 
DNS eingetragen)


smtpd_recipient_restrictions = permit_mynetworks, 
permit_sasl_authenticated, reject_non_fqdn_recipient, 
reject_unauth_destination, reject_unknown_recipient_domain, 
check_recipient_access hash:/etc/postfix/recipient_access, reject


und recipient_access beinhaltet

mailadresse1@domainOK
mailadresse2@domainOK

damit ist klar, will jemand eine Mail mit Empfänger mailadresse3@domain 
abladen, scheitert er ...


läßt man dies weg, und macht an Stelle

virtual_alias_maps = hash:/etc/postfix/virtual

mit folgenden Inhalt in virtual

mailadresse1@domainmailbox@local
mailadresse2@domainmailbox@local
@domainshredder@devnull

und folgendes in der hosts-Datei

127.0.0.1  devnull

sowie das im transport-File

devnulldiscard:

würde in einem Fall der SPAM-Sender bei fehlerhaften Zieladressen
einen Error bekommen und im anderen nichts davon mitbekommen, richtig?

welche Vor- und Nachteile ergeben sich sonst noch bei diesen Varianten?

Grüße,
Walter





smime.p7s
Description: S/MIME Cryptographic Signature

wer/was manipuliert Mails [was: header_check und Nichtexistenz eines Eintrags?]

[Walter H.]

On 17.10.2017 13:40, Walter H. wrote:

Hallo,

wie kann man sehr einfach mittels header_checks prüfen, ob im Mail ein
To: ...
vorkommt?
und genau dann wenn es NICHT vorkommt, ein REJECT ...

Danke,
Walter

wie kommt es, daß sobald ich exakt diese Mails, welche ich durch keine 
einzige header_check-Regel  sinnvoll erfassen kann,

dann im Mailclient folgendes im Mail header haben:

To: undisclosed recipients;

was aber wiederum mit einer header_check-Regel erfaßbar "wäre" ...

darum die Frage: was fügt dies hinzu, und wieso greift da keine Regel?

folgendes sollte doch klappen:

/^.*undisclosed-recipients.*$/
REJECT 

Danke,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: wer/was manipuliert Mails [was: header_check und Nichtexistenz eines Eintrags?]

[Walter H.]

On 23.10.2017 14:10, Sören Mindorf - Postfix wrote:

Hallo Walter,


21. Oktober 2017 20:40, "Walter H."  schrieb:

[...]


To: undisclosed recipients;

was aber wiederum mit einer header_check-Regel erfaßbar "wäre" ...

darum die Frage: was fügt dies hinzu, und wieso greift da keine Regel?

Soweit ich weiß, wird "undisclosed recipients;" hinzugefügt, wenn es keine TO 
Empfänger gibt,
wohl aber BCC. ;)

soll so sein ...

folgendes sollte doch klappen:

/^.*undisclosed-recipients.*$/
REJECT 

Nö, da es "undisclosed recipients" heißt, und da kein "-" drin ist. ;)

nicht wirklich,
die Mails die ich blockieren würde haben alle "-"...



smime.p7s
Description: S/MIME Cryptographic Signature

Filter Interface / Error handling ...

[Walter H.]

Hallo,

habe hier das Grundgerüst eines Milters ...

https://www.thecodingmachine.com/triggering-a-php-script-when-your-postfix-server-receives-a-mail/

bzw. hier

http://www.postfix.org/FILTER_README.html#simple_filter

ein einfaches Beispiel;

handelt es sich bei den Ausgaben mit echo bei diesem kurzen Skript um
"Fehler" welche beim Absender im Fehlermail aufscheinen?
(vergleichbar mit 'REJECT Text' bei header_checks)

Danke,
Walter

NULL-Sender an ISP-Smarthost bzw. NULL-Sender ersetzen?

[Walter H.]

Hallo,

wie übergibt man Fehlernachrichten, z.B. ein Postfach voll (lokaler
Mailserver) welche ja mit dem NULL-Sender (<>) im Mail-Envelope verschickt
wird, an den Smarthost des ISPs, welcher eine Authentifizierung in
Abhängigkeit der Senderadresse erfordert?

sprich in /etc/postfix/sasl_passwd ist folgendes gelistet
email user:pass
email user:pass
...

und in der main.cf

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =

smtp_sender_dependent_authentication = yes

bzw.

sender_canonical_classes = envelope_sender
sender_canonical_maps = pcre:/etc/postfix/sndr_canonical.pcre

im main.cf und in /etc/postfix/sndr_canonical.pcre

if !/(.+)\@domain\.tld/
/.+/ n...@domain.tld*)
endif

*) diese Ersetzung wird durchgeführt bei allen Mailadressen, welche nicht
mit domain.tld enden, auch beim NULL-Sender - wie lautet der
Suchstring/die Regexp welche exakt EINZIG den NULL-Sender matcht?

Danke,
Walter

SSL-Zertifikat an Stelle von main.cf in master.cf?

[Walter H.]

Hallo,

kann man in der master.cf z.B. so

smtp  inet  n   -   n   -   -   smtpd
  -o smtpd_tls_cert_file=/etc/postfix/tls.crt/mx-host.crt
  -o smtpd_tls_key_file=/etc/postfix/tls.key/mx-host.key
submission inet n   -   n   -   -   smtpd
  ...
  -o smtpd_tls_cert_file=/etc/postfix/tls.crt/smtp-host.crt
  -o smtpd_tls_key_file=/etc/postfix/tls.key/smtp-host.key

unterschiedliche SSL-Zertifikate f. den Submission-Port (587) und den 
SMTP-(MX-)Port (25)

setzen?

Danke,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: PHP mail from Adresse

[Walter H.]

On 30.11.2017 22:42, Ralf Hildebrandt wrote:

  From:
=?UTF-8?B?QmFyZnXDnyBpbSBBbGxnw6R1IDxhZG1pbkBiYXJmdXNzLWFsbGdhZXUuZGU+?=

Und da erkennt Postfix wohl nicht, dass sehr wohl eine Domain enthalten
ist, und hängt die dann nochmal an.
Nenenene. Das geht um die Envelope, nicht den Header.

im Header macht sowas aber auch keinen Sinn ...




smime.p7s
Description: S/MIME Cryptographic Signature

Erkennen eines bestimmten Mails ...

[Walter H.]

Hallo,

mein virtueller Server, welchen ich bei einem Hoster stehen habe, ist 
auch als Mailserver konfiguriert;
dieser hat aber keine Postfächer selbst gespeichert sondern relayed 
einfach an den Mailserver meines ISPs

auf mein Postfach weiter ...
da ich festgestellt habe, daß Mails, welche logwatch sendet, Dinge 
beinhalten, welche der SPAM-Filter

vom ISP verweigert, habe ich folgendes gemacht:

am virtuellen Server im master.cf

convert unix-   n   n   -   -   pipe
  flags= size=262144 user=nobody argv=/etc/postfix/mailcnvt.sh 
${sender} ${recipient}


im main.cf

transport_maps = hash:/etc/postfix/transport
bzw.
convert_destination_recipient_limit = 1

in der /etc/postfix/transport das:
convert.mailconvert:

und das Skript mailcnvt.sh sieht so aus:

#!/bin/bash
EMAIL=$(mktemp)
cat >$EMAIL
(
  echo -e -n "From: Vhost Local <#ISP-E-mail#>\n"
  echo -e -n "To: #ISP-E-mail#\n"
  echo -e -n "X-Mailer: VhostLocal-Cnvrt/1.0\n"
  echo -e -n "Subject: Vhost Local Mail\n"
  egrep --max-count=1 "^Date: " $EMAIL
  echo -e -n "MIME-Version: 1.0\n"
  echo -e -n "Content-Type: text/plain; charset=\"us-ascii\"\n"
  echo -e -n "Content-Transfer-Encoding: 7bit\n\n"
  echo -e -n "-BEGIN BASE64 MAIL-\n"
  cat $EMAIL |base64
  echo -e -n "-END BASE64 MAIL-\n"
)|/usr/sbin/sendmail -f #ISP-E-mail# #ISP-E-mail#
rm $EMAIL
exit 0

und das gegenteilige Prozedere läuft auf meinem lokalen Rechner, welcher
mittels fetchmail die Mails vom Postach beim ISP abholt;

hier habe ich auf die "schnelle" folgende "Erkennung" mittels 
header_check realisiert


/^to: #ISP-E-mail#$/
  REDIRECT ...

das funktioniert auch;

kann ich zur ein  Feld im Header "erfinden" mit dessen Hilfe ich diese
Mails eindeutig erkenne?
(falls diese E-mail Adresse ein SPAM sender verwendet, würde damit 
verhindert werden,

daß die Konvertierroutine angeworfen wird)

Danke,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: DNSBL Problem

[Walter H.]

On 17.12.2017 13:11, Ublun wrote:


Hatte auch nie Probleme mit Spamhaus und Hetzner Server, wenn du das 
Limit nicht überschreitest:


1) Your use of the Spamhaus DNSBLs is non-commercial*,
/and
/2) Your email traffic is less than 100,000 SMTP connections
per day, /and
/3) Your DNSBL query volume is less than 300,000 queries
per day.


darum empfiehlt sich auch die Reihenfolge zu beachten ...

z.B.  aus meiner main.cf

smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_unknown_hostname, reject_non_fqdn_helo_hostname


smtpd_client_restrictions = permit_mynetworks, 
reject_unknown_client_hostname, reject_unknown_reverse_client_hostname, 
reject_rbl_client dnsbl.sorbs.net, reject_rhsbl_client dbl.spamhaus.org


smtpd_sender_restrictions = reject_non_fqdn_sender, 
reject_unknown_sender_domain, check_sender_mx_access 
cidr:/etc/postfix/drop.cidr, check_sender_ns_access 
cidr:/etc/postfix/drop.cidr, check_sender_access 
hash:/etc/postfix/sender_access


smtpd_recipient_restrictions = permit_mynetworks, 
permit_sasl_authenticated, reject_non_fqdn_recipient, 
reject_unauth_destination, reject_unknown_recipient_domain, 
reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, 
check_recipient_access hash:/etc/postfix/recipient_access, reject


smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_unauth_destination, reject_unknown_recipient_domain


das ist sicher noch verbesserungswürdig,
und damit bekomme ich - sogar ohne SpamAssassin - keinen SPAM ...

auf meinem Server läuft ebenfalls ein lokaler BIND



smime.p7s
Description: S/MIME Cryptographic Signature

Re: DNSBL Problem

[Walter H.]

On 17.12.2017 16:59, Ublun wrote:

reject_*_hostname

eine sehr wirksame Waffe gegen SPAM-Sender ...
damit habe ich Probleme, mit denen die über ein Mobile Hotspot senden, 
diese Adressen kommen meistens ohne sauberen hostname daher. ich 
inbegriffen, 

dann einfach permit_sasl_authenticated davor;
weil ich zu Hause nur noch mit einer Flat übers Handy surfe, müsste 
das Android rooten damit könnte ich es wohl umgehen.

was bringt Dir das, wenn das vom DNS kommt?
nebenbei: dein Handy versendet doch nicht direkt sondern mittels eines 
Smarthosts, oder?
Vielleicht kommt dann doch noch ein richtiges Linux Handy auf den Markt. 

eher ein gekochter Eislutscher



smime.p7s
Description: S/MIME Cryptographic Signature

Re: header_check

[Walter H.]

On 24.12.2017 14:38, Ublun wrote:


kann es sein das @gmail.com email Adressen von Postfix nicht gefiltert 
werden?


/^From:.*\newsletter@e-flypgs\.com/ REJECT
wird gefiltert

*jegliche* gmail.com Adressen werden nicht gefiltert, werde da nicht 
schlau.



/^From:.*\newsletter@e-flypgs\.com/ REJECT
/^From:.*\allwehave@gmail\.com/ REJECT


was soll \a denn f. ein Zeichen sein?


nicht dringend, erstmals schöne Feiertage - herzlich David



eventuell einen ganz anderen Weg gehen ...

beim Eintrag
smtpd_sender_restrictions =

das am Ende ergänzen ...
, check_sender_access hash:/etc/postfix/sender_access

und in sender_access

newslet...@e-flypgs.com  REJECT
allweh...@gmail.com  REJECT

postmap   sender_access

postfix reloaden, fertig

der Unterschied:  header_checks beziehen sich auf den Mail-header,
sender_access hingegen auf den Mail-envelope ...

Frohe Weihnachten



smime.p7s
Description: S/MIME Cryptographic Signature

Re: spam...@tiscali.it

[Walter H.]

On 28.12.2017 13:59, Ublun wrote:
Dec 28 08:30:25 postfix/smtpd[10497]: NOQUEUE: reject: RCPT from 
unknown[195.22.125.20]: 450 4.7.25 Client host rejected: cannot find 
your hostname, [195.22.125.20]; from= 
to= proto=ESMTP helo=


wenn du es sagst, den habe ihn auch, aber er wird auch ohne blacklist 
geblockt.


whois 195.22.125.20 da kommt einer aus Polen


kommt bei mir auch regelmässig vor

Dec 25 23:15:12 vhost01 postfix/smtpd[5486]: NOQUEUE: reject: RCPT from 
unknown[37.49.226.140]: 550 5.7.1 Client host rejected: cannot find your 
hostname, [37.49.226.140]; from= 
to= proto=ESMTP helo=
Dec 27 09:20:40 vhost01 postfix/smtpd[10075]: NOQUEUE: reject: RCPT from 
unknown[199.168.137.147]: 550 5.7.1 Client host rejected: cannot find 
your hostname, [199.168.137.147]; from= 
to= proto=ESMTP helo=


ich will keine Verschwörungstheorie lostreten, aber sowas als 
msftncsi-Ersatz hat schon was :-)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: spam...@tiscali.it

[Walter H.]

On 28.12.2017 15:03, Martin Steigerwald wrote:

Walter H. - 28.12.17, 14:23:

On 28.12.2017 13:59, Ublun wrote:

Dec 28 08:30:25 postfix/smtpd[10497]: NOQUEUE: reject: RCPT from
unknown[195.22.125.20]: 450 4.7.25 Client host rejected: cannot find
your hostname, [195.22.125.20]; from=
to=  proto=ESMTP helo=

wenn du es sagst, den habe ihn auch, aber er wird auch ohne blacklist
geblockt.

whois 195.22.125.20 da kommt einer aus Polen

kommt bei mir auch regelmässig vor

Dec 25 23:15:12 vhost01 postfix/smtpd[5486]: NOQUEUE: reject: RCPT from
unknown[37.49.226.140]: 550 5.7.1 Client host rejected: cannot find your
hostname, [37.49.226.140]; from=
to=  proto=ESMTP helo=
Dec 27 09:20:40 vhost01 postfix/smtpd[10075]: NOQUEUE: reject: RCPT from
unknown[199.168.137.147]: 550 5.7.1 Client host rejected: cannot find
your hostname, [199.168.137.147]; from=
to=  proto=ESMTP helo=

ich will keine Verschwörungstheorie lostreten, aber sowas als
msftncsi-Ersatz hat schon was :-)

Willkommen im Club:

/var/log/mail.log.4.gz:Dec  2 01:39:28 mondschein postfix/postscreen[3332]:
NOQUEUE: reject: RCPT from [23.227.199.202]:59527: 550 5.7.1 Service
unavailable; client [23.227.199.202] blocked using zen.spamhaus.org;
from=, to=, proto=ESMTP, helo=

mondschein:~>  zgrep spam...@tiscali.it /var/log/mail.log* | wc -l
44


wie hast Du zen.spamhaus.org  eingebunden?

bei mir scheint
smtpd_client_restrictions = , reject_rbl_client zen.spamhaus.org, ...
nie anzuschlagen ...



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Authentifizierung in Thunderbird "Verschlüsseltes Passwort"

[Walter H.]

On 28.12.2017 22:11, Patrick Ben Koetter wrote:

* Frank Röhm:

Im Moment muss ich ja "Passwort, normal" auswählen, damit es geht. Das ist
ja auch nicht optimal.

Es ist optimal, auch wenn es auf den ersten Blick nicht so wirkt, *solange* Du
STARTTLS vor dem AUTH erzwingst.

Wenn Du eine TLS-verschlüsselte Verbindung erzwingst (nur auf Port 587) sind

nicht ganz;
Port 587 ist der Submissionport, welcher wenn der Serveradmin es 
komplett verkorkst gar keine Verschlüsselung geben muss;

Port 465 ist der SMTPS-Port (das SMTP-pendant) zu HTTPS mit Port 443 ...

wobei ich habe auch schon reines unverschlüsseltes HTTP auf Port 443 
erlebt ...

In so einem Umfeld ist es sicher (so sicher wie TLS ist), wenn Du Benutzername
und Kennwort per PLAIN/LOGIN (lies: "Passwort, normal") an den Server senden
lässt.
Thunderbird, ändert hier die Anzeige, wenn man von 'None' auf 'STARTTLS' 
od. 'SSL/TLS' umstellt;
bei 'None' wird an Stelle von 'Normal password' dann 'Password, 
transmitted insecurely' angezeigt;
ich kenne kaum ein System, welches tatsächlich ohne SSL eine fehlerfreie 
verschlüsselte Übertragung von

UserId / Passwort ermöglicht ...


Der Server, bzw. der sog. Password Verification Service (hier: Dovecot), nimmt
die Daten entgegen, prüft im Backend, ob das übergebene Passwort mit dem User,
der gesendet wurde, mit dem gecrypteten Passwort "passt".
hier gibt es 2 Arten, entweder es handelt sich um echte User am 
Linux-System - so habe ich es gemacht,
oder aber eine eigene vom System losgelöste Verwaltung von Usern (die 
UserIds sind hier dann Mailadressen);


den Unterschied kennt man, ob der User in der /etc/passwd zu finden ist 
oder in der sasldb ...







smime.p7s
Description: S/MIME Cryptographic Signature

Re: Authentifizierung in Thunderbird "Verschlüsseltes Passwort"

[Walter H.]

On 29.12.2017 08:50, Patrick Ben Koetter wrote:

* Walter H.:

On 28.12.2017 22:11, Patrick Ben Koetter wrote:

* Frank Röhm:

Im Moment muss ich ja "Passwort, normal" auswählen, damit es geht. Das ist
ja auch nicht optimal.

Es ist optimal, auch wenn es auf den ersten Blick nicht so wirkt, *solange* Du
STARTTLS vor dem AUTH erzwingst.

Wenn Du eine TLS-verschlüsselte Verbindung erzwingst (nur auf Port 587) sind

nicht ganz;
Port 587 ist der Submissionport, welcher wenn der Serveradmin es komplett
verkorkst gar keine Verschlüsselung geben muss;
Port 465 ist der SMTPS-Port (das SMTP-pendant) zu HTTPS mit Port 443 ...

Ich präzisiere: Das darfst Du nur auf 587 erzwingen, denn auf dem Port 25
können auch MTAs aufschlagen, die gar kein TLS können und die könnten in dem
Fall nicht einmal einen Mail an postmaster@DOMAIN absetzen, um ihr Problem zu
schildern.
für die eigene Domain vielleicht gar nicht mal so doof, auf die Art zu 
sagen:

"besorg Dir einen ordentlichen Mailserver, wennst mir SPAM schicken willst"

- Administrator/Anwender
   Daran arbeiten sie eher selten. Wietse hat intensivst für Postfix daran
   gearbeitet. Wie wenig Arbeit in amavis oder rspamd geflossen ist, erlebt man
   sofort wenn man sich den Programmen nähert.

mein Mailserver kommt mit Postfix/OpenDKIM/OpenDMARC aus,
keine Notwendigkeit f. SPAMassassin, amavis, ...

  Das Interface von Thunderbird
   stammt aus den 90ern - leider.

als ob der Pfusch der "Gegenwart" was Interfaces betriffft, da besser ist;

  Aber da Geld auszugeben lohnt nicht mehr. Die
   Tage der Desktop-Clients sind gezählt.

ob die Welt der "Heizflossen" besser ist, wage ich mal zu bezweifeln;



smime.p7s
Description: S/MIME Cryptographic Signature

Re: DMARC: Sinnvoll oder nicht?

[Walter H.]

On 08.03.2018 16:03, Patrick Ben Koetter wrote:

* Marco Dickert:

-
$ dig _dmarc.sys4.de TXT +short
"v=DMARC1; p=none;"
-

Es ist kein Dummy. Den habe ich mit Absicht gesetzt. Die Policy lautet:

 Ja, wir kennen DMARC
 Ja, wir haben eine DMARC-Policy
 Die Policy lautet: Wir machen nichts.



wodurch unterscheidet sich diese Policy, die ihr angegeben habt
von jeder, welche z.B. so lautet

"v=DMARC1; p=none; ruf=mailaddr; rua=mailaddr;"

Danke,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: DMARC: Sinnvoll oder nicht?

[Walter H.]

On 10.03.2018 08:38, Patrick Ben Koetter wrote:

* Walter H.:

On 08.03.2018 16:03, Patrick Ben Koetter wrote:

* Marco Dickert:

-
$ dig _dmarc.sys4.de TXT +short
"v=DMARC1; p=none;"
-

Es ist kein Dummy. Den habe ich mit Absicht gesetzt. Die Policy lautet:

  Ja, wir kennen DMARC
  Ja, wir haben eine DMARC-Policy
  Die Policy lautet: Wir machen nichts.



wodurch unterscheidet sich diese Policy, die ihr angegeben habt
von jeder, welche z.B. so lautet

"v=DMARC1; p=none; ruf=mailaddr; rua=mailaddr;"

Mit $ruf und $rua teilst Du DMARC-Prüfenden mit, wohin sie _r_eports senden
sollen. Der $ruf ist für _f_ailure reports und der $rua für
_a_ggregierte Reports.

und was teile ich denen mit wenn dies mit p=none angegeben ist?
(darauf wollte ich hinaus)

sprich der Unterschied zu eurer Policy, denn eure sagt, daß ihr nichts 
macht;

und was macht dann diese?

Beim Reporten musst Du darauf achten, *was* Du mitteilst, denn einige Daten,
wie z.B. die IP-Adresse, sind aus Sicht des dt. Datenschutzes personenbezogene
Merkmale.
meiner Meinung sind die Reports Käse, denn f. Menschen lesbar sieht 
anders aus zum einem und zum anderen
so wie DMARC definiert ist, kann es nicht herhalten einen 
eingeschriebenen Brief mit Rückschein nachzubilden ...

Wenn Du DMARC testweise warmfahren willst, ist die Angabe einer report-Adresse
sinnvoll, denn dann kannst Du sehen, welche Verstösse andere wahrnehmen und
dann ggf. von einer DMARC-policy Abstand nehmen oder die Plattform so
anpassen, dass es zu keinen oder weniger Verstössen kommt.

ich hab ein Autoreply mit dem Inhalt, daß es mich nicht interessiert :-)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [postfix] pipe alias permission denied

[Walter H.]

On 12.03.2018 20:29, Carsten wrote:



Ja, postfix ist chrooted in der master.cf.
Jetzt habe angefangen, zu experimentieren, aber bis jetzt hat nichts 
geholfen.
Zum Beispiel habe ich einfach mal die "/etc/passwd" und die 
"/etc/group" in das Verzeichnis "/var/spool/postfix/etc" kopiert und 
postfix neu gestartet.

Leider ohne eine sichtbare Änderung.
Die Frage scheint also lauten zu müssen: Wie bekomme ich den chroot 
des postfix dazu, eine group-datei zu lesen?
SELinux oder so kommt nicht zusätzlich ins Spiel, oder ist SELinux nur 
ein Feature von RHEL basierten Linuxen, was bei Dir ja nicht der Fall 
ist ...


Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: #efail

[Walter H.]

On 14.05.2018 18:32, Robert Schetterer wrote:

Am 14.05.2018 um 17:46 schrieb J. Fahrner:

Mit DKIM signierten Mails sollte das doch eigentlich nicht zum Problem
werden, oder?
https://www.heise.de/security/artikel/PGP-und-S-MIME-So-funktioniert-efail-4048873.html


LG Jochen

hm grad erst eingelesen..
ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
middle", ich stell mir das erstmal so vor, der Boese will doch nicht
entdeckt werden d.h er wird zunaechst ein Kopie herstellen/ausleiten
damit du nicht mitbekommst dass er mitliest. Er arbeitet dann mit der
Kopie und wendet efail an. Insofern wirst du via DKIM keine Manipulation
feststellen koennen.

das Einfügen der beiden Teile vor und nach dem BASE64 Datenstrom?
wobei ich hier mir die Frage stelle, wieso soll ein Mailer hier ein HTML 
rendering
anwerfen, wo es doch darum geht den BASE64 Datenstom unverschlüsselt 
darzustellen?

zumindest das sagt der MIME-Type im Header aus(!)


Die Berichterstattung empfinde
ich etwas zu sensationsgetrieben , von der Sorte "seht Email ist einfach
nicht mehr zu retten"

das ist Heise mittlerweile auf Bild-Niveau  ...




smime.p7s
Description: S/MIME Cryptographic Signature

Re: #efail

[Walter H.]

On 14.05.2018 21:59, J. Fahrner wrote:

Am 2018-05-14 18:32, schrieb Robert Schetterer:

ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
middle",


Der "man in the middle" modifiziert die Mail und fügt einen Anhang 
vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was der 
Empfänger ja leicht feststellen kann (so er denn die Signatur prüft).
soferne die DKIM-Signatur dies erfasst, weil anscheinend ja nur im 
Mail-Body etwas hinzugefügt wird;


schlimmer finde ich ein ganz anderes Szenario, da er ja die 
verschlüsselte Mail im Original hat, hat er auch den Public Key des 
Empfängers, und damit kann er dann den kompletten verschlüsselten Inhalt 
durch was anderes ersetzen - Malware z.B. - und das hebelt dann 
sämtliche Mechanismen am Transport aus - da ja verschlüsselt; und der 
Client kann - schlampig wie sie alle implementiert sind - macht weiß 
Gott was damit ...


DKIM-Signatur hin oder her, ein Mail Client der hier irgendwas anderes 
macht als einen Fehler auszugeben ist kompletter Pfusch;




smime.p7s
Description: S/MIME Cryptographic Signature

Re: #efail

[Walter H.]

On Tue, May 15, 2018 08:06, J. Fahrner wrote:
> Am 2018-05-15 05:23, schrieb Walter H.:
>> schlimmer finde ich ein ganz anderes Szenario, da er ja die
>> verschlüsselte Mail im Original hat, hat er auch den Public Key des
>> Empfängers, und damit kann er dann den kompletten verschlüsselten
>> Inhalt durch was anderes ersetzen
>
> Nur, wenn der Empfänger seinen Key auf einen Keyserver hochgeladen hat.
> In der Mail ist der nicht enthalten. Keys von Keyservern holen kann aber
> jeder, dazu muss er nicht als man-in-the-middle eine Mail abfangen und
> manipulieren. Und Mail signieren kann er überhaupt nicht, dazu bräuchte
> er den private key des Senders.

das ist ja das schöne, wenn der Böse als Man-in-the-Middle das veranstaltet,
dann kommt die Mail eben bei Dir so an, wie wenn ich sie verschickt hätte ...
(er beschädigt in 90% der Fälle die DKIM Signatur eben nicht)
und signieren braucht er die Mail auch nicht ...

Re: #efail

[Walter H.]

On Tue, May 15, 2018 09:03, lst_ho...@kwsoft.de wrote:
>
> Zitat von "J. Fahrner" :
>
>> Am 2018-05-14 18:32, schrieb Robert Schetterer:
>>> ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
>>> middle",
>>
>> Der "man in the middle" modifiziert die Mail und fügt einen Anhang
>> vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was
>> der Empfänger ja leicht feststellen kann (so er denn die Signatur
>> prüft).
>
> Jede Form der Integritätssicherung die auch sinnvoll verwendet wird
> umgeht das Problem.

leider nicht;

> Der eigentliche Fail liegt aber im verwenden von
> HTML und dem nachladen externer Inhalte.

Nein, sondern in der schlampigen Implementierung; wie kommt  ein Mail
client auch nur annähernd auf die Idee, obwohl im Header eindeutig im
MIME-Type steht, daß es sich um was verschlüsseltes handelt, und damit ein
BASE64-Datenstrom zu erwarten ist, etwas anderes hier mitzubeachten an
statt einen Fehler auszugeben ...

> Wer sowas macht braucht sich
> auch um Verschlüsselung und Signaturen keine Gedanken mehr zu machen.

nicht wirklich;

Re: #efail

[Walter H.]

On Tue, May 15, 2018 11:57, lst_ho...@kwsoft.de wrote:
>
> Zitat von "Walter H." :
>
>> On Tue, May 15, 2018 09:03, lst_ho...@kwsoft.de wrote:
>>>
>>> Zitat von "J. Fahrner" :
>>>
>>>> Am 2018-05-14 18:32, schrieb Robert Schetterer:
>>>>> ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
>>>>> middle",
>>>>
>>>> Der "man in the middle" modifiziert die Mail und fügt einen Anhang
>>>> vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was
>>>> der Empfänger ja leicht feststellen kann (so er denn die Signatur
>>>> prüft).
>>>
>>> Jede Form der Integritätssicherung die auch sinnvoll verwendet wird
>>> umgeht das Problem.
>>
>> leider nicht;
>>
>>> Der eigentliche Fail liegt aber im verwenden von
>>> HTML und dem nachladen externer Inhalte.
>>
>> Nein, sondern in der schlampigen Implementierung; wie kommt  ein Mail
>> client auch nur annähernd auf die Idee, obwohl im Header eindeutig im
>> MIME-Type steht, daß es sich um was verschlüsseltes handelt, und damit
>> ein
>> BASE64-Datenstrom zu erwarten ist, etwas anderes hier mitzubeachten an
>> statt einen Fehler auszugeben ...
>>
>>> Wer sowas macht braucht sich
>>> auch um Verschlüsselung und Signaturen keine Gedanken mehr zu machen.
>>
>> nicht wirklich;
>
> Multipart MIME erlaubt alles mögliche.

stimmt, im Mail-Header steht aber das

MIME-Version: 1.0
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
Content-Transfer-Encoding: base64

Re: #efail

[Walter H.]

On Tue, May 15, 2018 12:34, lst_ho...@kwsoft.de wrote:
>
> Zitat von "Walter H." :
>>
>> stimmt, im Mail-Header steht aber das
>>
>> MIME-Version: 1.0
>> Content-Disposition: attachment; filename="smime.p7m"
>> Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
>> name="smime.p7m"
>> Content-Transfer-Encoding: base64
>
> https://www.ciphermail.com/blog/efail-who-is-vulnerable-pgp-smime-or-your-mail-client.html
>
> Der zweite Teil. Dort steht auch warum ein Signatur das ganze umgeht
> solange die Gültigkeit bzw. die Abwesenheit der Signatur beachtet wird.

ich weiß nicht was Du da liest, aber eine multiplart/mixed Geschichte hat
mit Mailverschlüsselung reichlich wenig zu tun zum einem, und zum anderen
habe ich ja bereits erwähnt, daß Mailprogramme mehr als verbugt sind;