Kategorien-Archiv Blog

Postfix – Absender darf nur spezielle Domains adressieren

Ausgangslage:

Mehrere Systeme im Haus, relayen über den zentralen Postfix-Mailserver

Anforderung:

Ein bestimmter Absender (benachrichtigung@cubewerk.de) darf nur 3 bestimmte Zieldomains (microsoft.com, aol.com, yahoo.com) anschreiben.

Für alle anderen Domains, soll dieser eine Absender ein reject erhalten.

main.cf erweitern um:

smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/benachrichtigung
smtpd_restriction_classes = benachrichtigung
benachrichtigung = check_recipient_access hash:/etc/postfix/erlaubt, reject

/etc/postfix/benachrichtigung erstellen mit
benachrichtigung@cubewerk.de benachrichtigung

postmap /etc/postfix/benachrichtigung

/etc/postfix/erlaubt erstellen mit
microsoft.com OK
aol.com OK
yahoo.com OK

postmap /etc/posfix/erlaubt

Abschließend ein /etc/init.d/posfix restart

Jetzt der Praxistest:

bauer@mail05:~$ telnet localhost 25
Trying ::1…
Connected to localhost.
Escape character is ‚^]‘.
220 mail05.int ESMTP Postfix (Ubuntu)
mail from: benachrichtigung@cubewerk.de
250 2.1.0 Ok
rcpt to: test@microsoft.com
250 2.1.5 Ok
rcpt to: test@yahaoo.com
250 2.1.5 Ok
rcpt to: anderer-empfaenger@t-online.de
554 5.7.1 <benachrichtigung@cubewerk.de>: Sender address rejected: Access denied

Restliche Absender davon nicht berührt:

bauer@mail05:~$ telnet localhost 25
Trying ::1…
Connected to localhost.
Escape character is ‚^]‘.
220 mail05.int ESMTP Postfix (Ubuntu)
mail from: interner-absender@cubewerk.de
250 2.1.0 Ok
rcpt to: anderer-empfaenger@t-online.de
250 2.1.5 Ok

kopano K-1216 – security update – duration np-defrag

Aufgrund CVE-2018-8950 und CVE-2018-8951 sollte aktuell jeder Kopano-Server aktualisiert werden.

Details hierzu hier:

Kopano Groupware Core 8.5.8: Vulnerability fixes and more (updated)

Bei unserem Server mit ~ 120 Benutzern und Corosync/Pacemaker-Cluster und ~ 200GB Mysql-Datenbank dauerte der anschließende Aufruf von opano-dbadm k-1216 ~ 5 1/2 Stunden.

Trotz 32 CPU-Kernen schnappt sich MySQL immer nur einen Kern wie es scheint.

Auszug des Laufs:

up: merging #3946 into #1375 in „lob“…
dbadm: executing action „np-defrag“
defrag: 2960 IDs
defrag: moving 2 -> 1 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 4 -> 2 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 6 -> 3 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 8 -> 4 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 10 -> 5 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 12 -> 6 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 14 -> 7 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 16 -> 8 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 18 -> 9 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 19 -> 10 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 21 -> 11 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 23 -> 12 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 25 -> 13 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 27 -> 14 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 29 -> 15 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 31 -> 16 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 33 -> 17 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 35 -> 18 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 37 -> 19 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 39 -> 20 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 41 -> 21 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 43 -> 22 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 45 -> 23 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 47 -> 24 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 49 -> 25 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 51 -> 26 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 53 -> 27 (names) (properties)

vr-networld langsam – Mehrbenutzer – Netzlaufwerk

Wir haben bemerkt ,dass der Zugriff mit VR-Networld auf ein Netzlaufwerk, welches von mehreren Rechnern genutzt wird (Empfehlung maximal 3 laut Vr-Bank) nur performant läuft, wenn der Datenbestand als gemapptes Laufwerk eingebunden wird und nicht direkt per UNC \\192….