Systemy Operacyjne
Usługi systemowe
Bazy Danych
Programowanie
CONTENT
  • CHANGES
Szukaj
counter

#top Przydatne informacje


#top Timeout


Zobacz także Timeout dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Timeout dla: ProFTPd | Pure-FTPd | vsftpd | Dovecot | Postfix | OpenLDAP
Zobacz także Timeout dla: pgpool | PostgreSQL | MySQL | Firebird

(Zobacz sekcję Timeout)



#top Load Balancing with HAProxy


Zobacz także Load Balancing with HAProxy dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Load Balancing with HAProxy dla: ProFTPd | Pure-FTPd | vsftpd | Dovecot | Postfix | OpenLDAP
Zobacz także Load Balancing with HAProxy dla: pgpool | PostgreSQL | MySQL | Firebird

Więcej informacji w analogicznym zagadnieniu: Postfix behind HAProxy



#top Postfix behind HAProxy


Zobacz także Postfix behind HAProxy dla: HAProxy (HAProxy)

W niniejszej konfiguracji HAProxy odbiera połączenia przychodzące na port 1025 i przekierowywuje je do Postfix na port 20026:

Plik konfiguracyjny /etc/postfix/master.cf (master.cf):
smtpd     pass  -       -       n       -       -       smtpd
[...]
20026     inet  n       -       n       -       1       postscreen

Plik konfiguracyjny /etc/postfix/main.cf:
# The name of the proxy protocol used by an optional before-postscreen proxy agent.
postscreen_upstream_proxy_protocol = haproxy
# Permanent white/blacklist for remote SMTP client IP addresses.
postscreen_access_list = permit_mynetworks
# The  internal  service that postscreen(8) hands off allowed connections to.
smtpd_service_name=smtpd

Aby w logach access serwera Postfix zamiast adresu serwera Proxy zapisywany był adres klienta łączącego się poprzez Proxy niezbędne jest wprowadzenie powyższych zmian w konfiguracji serwera Postfix.

Wysłaniu wiadomości z hosta o adresie 10.0.0.3 do serwera Postfix po protokole SMTP o adresie 10.41.0.58 w logach powinny pojawiać się informacje analogiczne do poniższych:
Plik z logami /var/log/haproxy/haproxy0.log:
Mar 14 23:52:48 localhost.localdomain haproxy-1.8[3670]: ::ffff:10.0.0.3:44922 [14/Mar/2018:23:52:48.128] public_smtp bknd_cen060x64_smtp/host_cen060x64 1/0/244 181 -- 1/1/0/0/0 0/0
Plik z logami /var/log/mail/mail.log:
Mar 14 23:52:48 cen06x64 postfix/postscreen[8716]: CONNECT from [10.0.0.3]:44922 to [10.41.0.58]:1025
Mar 14 23:52:48 cen06x64 postfix/postscreen[8716]: PASS OLD [10.0.0.3]:44922
Mar 14 23:52:48 cen06x64 postfix/smtpd[8721]: connect from xnd.nat.wbcd.pl[10.0.0.3]
Mar 14 23:52:48 cen06x64 postfix/smtpd[8721]: 20F9B84C2: client=xnd.nat.wbcd.pl[10.0.0.3]
Mar 14 23:52:48 cen06x64 postfix/cleanup[8774]: 20F9B84C2: message-id=<20180314.235248@xnd.nat.wbcd.pl>
Mar 14 23:52:48 cen06x64 postfix/smtpd[8721]: disconnect from xnd.nat.wbcd.pl[10.0.0.3]
Mar 14 23:52:48 cen06x64 postfix/qmgr[9530]: 20F9B84C2: from=<admin@xnd.nat.wbcd.pl>, size=495, nrcpt=1 (queue active)
Mar 14 23:52:49 cen06x64 dovecot: lda(sp): msgid=<20180314.235248@xnd.nat.wbcd.pl>: saved mail to INBOX
Mar 14 23:52:49 cen06x64 postfix/local[8793]: 20F9B84C2: to=<admin@cen06x64.xen.wbcd.pl>, relay=local, delay=0.93, delays=0.34/0.17/0/0.43, dsn=2.0.0, status=sent (delivered via dovecot service)
Mar 14 23:52:49 cen06x64 postfix/qmgr[9530]: 20F9B84C2: removed
Odebrana wiadomość (wraz z nagłówkami) będzie analogiczna do poniższej:
Return-Path: <admin@xnd.nat.wbcd.pl>
X-Original-To: admin@cen06x64.xen.wbcd.pl
Delivered-To: admin@cen06x64.xen.wbcd.pl
Received: from xnd.nat.wbcd.pl (xnd.nat.wbcd.pl [10.0.0.3])
        by cen06x64.xen.wbcd.pl (Postfix) with SMTP id 20F9B84C2
        for <admin@cen06x64.xen.wbcd.pl>; Tue, 14 Mar 2018 23:52:48 +0100 (CET)
Message-ID: <20180314.235248@xnd.nat.wbcd.pl>
User-Agent: smtpcmds/0.56, libsmtp/0.56, prebeta ;)
From: admin@xnd.nat.wbcd.pl
To: admin@cen06x64.xen.wbcd.pl
Subject: HAProxy to Postfix
Date: Tue, 14 Mar 2018 23:52:48 +0100
Content-Type: text/plain; charset=utf-8

body text
body text
body text

Dla porównania poniżej informacje jakie powinny pojawiać się w logach w przypadku zastosowania połączenia HAProxy do Postfix na port 25 (w logach serwera Postfix będzie pojawiać się jako adres IP klienta adres serwera HAProxy):
Plik z logami /var/log/haproxy/haproxy0.log:
Mar 14 23:52:55 localhost.localdomain haproxy-1.8[3670]: ::ffff:10.0.0.3:45625 [14/Mar/2018:23:52:55.559] public_smtp2 bknd_cen060x64_smtp2/host_cen060x64 1/0/116 181 -- 1/1/0/0/0 0/0
Plik z logami /var/log/mail/mail.log:
Mar 14 23:52:55 cen06x64 postfix/smtpd[8761]: connect from cen06x64.xen.wbcd.pl[10.41.0.58]
Mar 14 23:52:55 cen06x64 postfix/smtpd[8761]: 8AC8784C2: client=cen06x64.xen.wbcd.pl[10.41.0.58]
Mar 14 23:52:55 cen06x64 postfix/cleanup[8774]: 8AC8784C2: message-id=<20180314.235255@xnd.nat.wbcd.pl>
Mar 14 23:52:55 cen06x64 postfix/qmgr[9530]: 8AC8784C2: from=<admin@xnd.nat.wbcd.pl>, size=502, nrcpt=1 (queue active)
Mar 14 23:52:55 cen06x64 postfix/smtpd[8761]: disconnect from cen06x64.xen.wbcd.pl[10.41.0.58]
Mar 14 23:52:55 cen06x64 dovecot: lda(sp): msgid=<20180314.235255@xnd.nat.wbcd.pl>: saved mail to INBOX
Mar 14 23:52:55 cen06x64 postfix/local[8793]: 8AC8784C2: to=<admin@cen06x64.xen.wbcd.pl>, relay=local, delay=0.32, delays=0.11/0/0/0.21, dsn=2.0.0, status=sent (delivered via dovecot service)
Mar 14 23:52:55 cen06x64 postfix/qmgr[9530]: 8AC8784C2: removed
Odebrana wiadomość (wraz z nagłówkami) będzie analogiczna do poniższej:
Return-Path: <admin@xnd.nat.wbcd.pl>
X-Original-To: admin@cen06x64.xen.wbcd.pl
Delivered-To: admin@cen06x64.xen.wbcd.pl
Received: from xnd.nat.wbcd.pl (cen06x64.xen.wbcd.pl [10.41.0.58])
        by cen06x64.xen.wbcd.pl (Postfix) with SMTP id 8AC8784C2
        for <admin@cen06x64.xen.wbcd.pl>; Tue, 14 Mar 2018 23:52:55 +0100 (CET)
Message-ID: <20180314.235255@xnd.nat.wbcd.pl>
User-Agent: smtpcmds/0.56, libsmtp/0.56, prebeta ;)
From: admin@xnd.nat.wbcd.pl
To: admin@cen06x64.xen.wbcd.pl
Subject: HAProxy to Postfix
Date: Tue, 14 Mar 2018 23:52:55 +0100
Content-Type: text/plain; charset=utf-8

body text
body text
body text



#top address not listed for hostname


Co oznacza powyższy komunikat pojawiający się w logach oraz jak należy go interpretować:
Dla łatwiejszego zrozumienia przyczyny powstawania takiego komunikatu zostanie to prześledzone na podstawie poniższego przypadku.
Po skonfigurowaniu adresacji IPv6 (IPv6, IPv6) na serwerze na którym jest zainstalowany Postfix oraz skonfigurowaniu reverse DNS (Reverse DNS lookup) dla nowo dodanych adresów zabrakło rekordu AAAA (AAAA_record).
Serwer Postfix z sukcesem rozwiązał adres IPv6 na nazwę, jednakże nazwa domeny na którą wskazywał adres IPv6 na liście adresów IP (IP_address, Adres_IP) nie zawierała adresu, który wskazywał na domenę. W wyniku tego pojawił się w logach poniższy komunikat (ostrzeżenie). Poczta została przyjęta, gdyż adres IP (w tym przypadku IPv6) posiadał reverse DNS (wskazywał na nazwę), jednakże brak wpisu wskazującego na adres IP dla domeny na którą ten adres wskazywał spowodował pojawienie się powyższego komunikatu.
Bardziej czytelnie na podstawie niniejszego przykładu: adres IPv6 fd0a:2002:10:5:a:5:ffff:ffff wkazywał (posiadał wpis PTR (List_of_DNS_record_types)) na nazwę fwwb.nat.wbcd.pl, jednakże nazwa fwwb.nat.wbcd.pl na liście dostępnych adresów (zarówno IPv4 (IPv4, IPv4) jak również IPv6) nie posiadała wpisu (w tym przypadku rekordu AAAA) wskazującego na adres fd0a:2002:10:5:a:5:ffff:ffff).

W związku z powyższym w logach pojawiły się następujące informacje (ostrzeżenia):
Jun 25 05:25:05 wbcd postfix/smtpd[13731]: warning: fd0a:2002:10:5:a:5:ffff:ffff: address not listed for hostname fwwb.nat.wbcd.pl
Jun 25 06:57:39 wbcd postfix/smtpd[13418]: warning: fd0a:2002:10:5:a:5:ffff:ffff: address not listed for hostname fwwb.nat.wbcd.pl
Jun 25 06:58:17 wbcd postfix/smtpd[14831]: warning: fd0a:2002:10:5:a:5:ffff:ffff: address not listed for hostname fwwb.nat.wbcd.pl
Jun 25 06:58:29 wbcd postfix/smtpd[14831]: warning: fd0a:2002:10:5:a:5:ffff:ffff: address not listed for hostname fwwb.nat.wbcd.pl
Jun 25 06:59:30 wbcd postfix/smtpd[15547]: warning: fd0a:2002:10:5:a:5:ffff:ffff: address not listed for hostname fwwb.nat.wbcd.pl

oraz dodatkowo odebrane wiadomości posiadają w nagłówku Received informację analogiczną do poniższej (prosze zwrócić uwagę na nazwę unknown występującą tuż obok adresu IP (w tym przypadku IPv6) serwera od którego wiadomość została odebrana):
Received: from fwwb.nat.wbcd.pl (unknown [IPv6:fd0a:2002:10:5:a:5:ffff:ffff])
	by wbcd.pl (Postfix) with ESMTPS id 51C26442B5
	for <admin@wbcd.pl>; Thu, 25 Jun 2015 05:25:06 +0200 (CEST)


Inny zaobserwowany analogiczną przypadek do powyższego jest następujący: na serwerze cen05.xen.wbcd.pl skonfigurowano usługę syslog z włączoną opcją odbierania logów ze zdalnych maszyn / hostów. Zaobserwowanym mankamentem związanym z odbieraniem logów przez syslog jest rozwiązywanie adresu IP na nazwę domenową dla każdego odebranego pakietu, w wyniku czego powstaje dość duża liczba zapytań wysyłanych do serwera DNS.
Pewnym workaround zmniejszającym ilość zapytań do serwera DNS jest dodanie wpisów nazw mapujących nazwy na adresy IP (zanim została skonfigurowane adresacja IPv6 na hostach dodane zostały tylko wpisy mapujące nazwy na adresy IPv4) i odwrotnie do pliku /etc/hosts. Po skonfigurowaniu adresacji IPv6 na hostach serwer Postfix z sukcesem rozwiązał adresy IPv6 fd0a:2002:10:41:a:29:0:33 i fd0a:2002:10:41:a:29:0:34 na nazwy odpowiednio cen06-1.xen.wbcd.pl i cen06-2.xen.wbcd.pl korzystając z serwera DNS. Następnie serwer Postfix z sukcesem rozwiązał adresy domenowe cen06-1.xen.wbcd.pl i cen06-2.xen.wbcd.pl na adresy IP. Wpisy dla niniejszych domen mapujące adresy domenowe na adresy IPv4 znajdowały się w pliku /etc/hosts toteż nie zostało wysłane zapytanie do serwera DNS. W efekcie serwer Postfix adresy IPv6 rozwiązał na nazwy domenowe, które nie posiadały wpisów (rekordów AAAA) wskazujących na adresy IPv6, co poskutkowało pojawieniem się niniejszego komunikatu w logach:
Jun 11 05:18:11 cen05 postfix/smtpd[22349]: warning: fd0a:2002:10:41:a:29:0:34: address not listed for hostname cen06-2.xen.wbcd.pl
Jun 11 05:18:11 cen05 postfix/smtpd[22349]: connect from unknown[fd0a:2002:10:41:a:29:0:34]
Jun 11 05:18:11 cen05 postfix/smtpd[22349]: setting up TLS connection from unknown[fd0a:2002:10:41:a:29:0:34]
Jun 11 05:18:12 cen05 postfix/smtpd[22349]: TLS connection established from unknown[fd0a:2002:10:41:a:29:0:34]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
Jun 11 05:18:12 cen05 postfix/smtpd[22349]: 3CBCFB200A: client=unknown[fd0a:2002:10:41:a:29:0:34]
Jun 11 05:18:12 cen05 postfix/cleanup[22380]: 3CBCFB200A: message-id=<20160611031809.DB81786A30@cen06-2.xen.wbcd.pl>
Jun 11 05:18:12 cen05 postfix/qmgr[2985]: 3CBCFB200A: from=<root@cen06-2.xen.wbcd.pl>, size=4993, nrcpt=1 (queue active)
Jun 11 05:18:12 cen05 postfix/smtpd[22349]: disconnect from unknown[fd0a:2002:10:41:a:29:0:34]
Jun 11 05:18:14 cen05 dovecot: deliver(admin@cen05.xen.wbcd.pl): sieve: msgid=<20160611031809.DB81786A30@cen06-2.xen.wbcd.pl>: stored mail into mailbox 'logwatch.cen06-2'
Jun 11 05:18:14 cen05 postfix/pipe[22381]: 3CBCFB200A: to=<admin@cen05.xen.wbcd.pl>, relay=dovecot, delay=2.1, delays=0.42/0.07/0/1.6, dsn=2.0.0, status=sent (delivered via dovecot service)
Jun 11 05:18:14 cen05 postfix/qmgr[2985]: 3CBCFB200A: removed

Jun 11 05:21:23 cen05 postfix/smtpd[22349]: warning: fd0a:2002:10:41:a:29:0:33: address not listed for hostname cen06-1.xen.wbcd.pl
Jun 11 05:21:23 cen05 postfix/smtpd[22349]: connect from unknown[fd0a:2002:10:41:a:29:0:33]
Jun 11 05:21:23 cen05 postfix/smtpd[22349]: setting up TLS connection from unknown[fd0a:2002:10:41:a:29:0:33]
Jun 11 05:21:24 cen05 postfix/smtpd[22349]: TLS connection established from unknown[fd0a:2002:10:41:a:29:0:33]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
Jun 11 05:21:24 cen05 postfix/smtpd[22349]: 8A93BB200A: client=unknown[fd0a:2002:10:41:a:29:0:33]
Jun 11 05:21:24 cen05 postfix/cleanup[22380]: 8A93BB200A: message-id=<20160611032121.92F68E29F0@cen06-1.xen.wbcd.pl>
Jun 11 05:21:25 cen05 postfix/qmgr[2985]: 8A93BB200A: from=<root@cen06-1.xen.wbcd.pl>, size=5316, nrcpt=1 (queue active)
Jun 11 05:21:25 cen05 postfix/smtpd[22349]: disconnect from unknown[fd0a:2002:10:41:a:29:0:33]
Jun 11 05:21:27 cen05 dovecot: deliver(admin@cen05.xen.wbcd.pl): sieve: msgid=<20160611032121.92F68E29F0@cen06-1.xen.wbcd.pl>: stored mail into mailbox 'logwatch.cen06-1'
Jun 11 05:21:27 cen05 postfix/pipe[22381]: 8A93BB200A: to=<admin@cen05.xen.wbcd.pl>, relay=dovecot, delay=2.6, delays=0.71/0/0/1.9, dsn=2.0.0, status=sent (delivered via dovecot service)
Jun 11 05:21:27 cen05 postfix/qmgr[2985]: 8A93BB200A: removed

oraz dodatkowo odebrane wiadomości posiadają w nagłówku Received informację analogiczną do poniższej (prosze zwrócić uwagę na nazwę unknown występującą tuż obok adresu IP (w tym przypadku IPv6) serwera od którego wiadomość została odebrana):
Received: from cen06-2.xen.wbcd.pl (unknown [IPv6:fd0a:2002:10:41:a:29:0:34])
	by cen05.xen.wbcd.pl (Postfix) with ESMTP id 3CBCFB200A
	for <admin@cen05.xen.wbcd.pl>; Sat, 11 Jun 2016 05:18:12 +0200 (CEST)

Received: from cen06-1.xen.wbcd.pl (unknown [IPv6:fd0a:2002:10:41:a:29:0:33])
	by cen05.xen.wbcd.pl (Postfix) with ESMTP id 8A93BB200A
	for <admin@cen05.xen.wbcd.pl>; Sat, 11 Jun 2016 05:21:24 +0200 (CEST)

Dodanie stosowych wpisów do pliku /etc/hosts mapujących nazwy domenowe również na adres IPv6 rozwiązało niniejszy problem.



Kolejny zaobserwowany analogiczny przypadek do powyższego jest następujący: Adres IP 94.102.51.96 wskazuje na nazwę zed.yandex.ru (stan z dnia 2015/10/25), jednakże nazwa zed.yandex.ru wskazuje na adres IP 213.180.204.242. Adres IP 213.180.204.242 zgodnie z bazą danych RIPE (RIPE) należy do (stan z dnia 2015/10/25):
inetnum:        213.180.204.0 - 213.180.204.255
netname:        YANDEX-213-180-204
[...]
route:          213.180.204.0/24
descr:          Yandex enterprise network
origin:         AS13238
natomiast adres IP 94.102.51.96 wskazujący na nazwę zed.yandex.ru należy do (stan z dnia 2015/10/25):
inetnum:        94.102.51.0 - 94.102.51.255
netname:        NL-ECATEL
[...]
route:          94.102.48.0/20
descr:          AS29073 Route object
origin:         AS29073
Zgodnie z powyższymi informacjami adres IP 213.180.204.242 należy do puli adresów przyznanych przez RIPE dla Yandex, natomiast adres IP 94.102.51.96 nie należy do puli adresów przyznanych dla Yandex, toteż niniejszy adres IP wskazuje na nazwę z bliżej nieokreślonych powodów.



Kolejny zaobserwowany analogiczny przypadek do powyższego jest następujący: Adres IP 27.72.45.109 wskazuje na nazwę localhost (stan z dnia 2017/04/19), jednakże nazwa localhost wskazuje na adres IP 127.0.0.1. Adres IP 27.72.45.109 zgodnie z bazą danych RIPE (RIPE) należy do (stan z dnia 2015/10/25):
inetnum:        27.72.0.0 - 27.75.255.255
netname:        Newass2011xDSLHN-NET
country:        VN
descr:          New IP range in 2011 for XDSL service of Viettel in HCMC
descr:          1 Tran Huu Duc, My Dinh, Tu Liem, Hanoi
Zgodnie z powyższymi informacjami adres IP 27.72.45.109 należy do puli adresów przyznanych przez APNIC dla Newass2011xDSLHN-NET. Jak można zauważyć w opisie (desc: New IP range in 2011 for XDSL service of Viettel in HCMC) jest to pula adresów IP przydzielona do obsługi XDSL.



Oczywiście nie jest to jedyna przyczyna powstania pojawienia się powyższego ostrzeżenia w logach serwera Postfix, jednakże bardzo dokładnie obrazuje sytuację w jakiej takie ostrzeżenie się pojawia.
Inną przyczyną pojawienia się powyższej sytuacji mogą być oczywiści problemy sieciowe w komunikacji pomiędzy serwerem na którym jest zainstalowany Postfix oraz serwerem DNS z którego Postfix korzysta, jak również problemy sieciowe w komunikacji pomiędzy serwerem DNS a innymi serwerami DNS z których serwer DNS korzysta do rozwiązania adresu IP na nazwę oraz nazwy na adres IP. Dodatkowo również nieadekwatna do warunków sieciowych konfiguracja serwera DNS (temat opisany również w sekcji network unreachable resolving dotyczącej serwera DNS Named:Bind) również może sprzyjać pojawianiu się niniejszych ostrzeżeń w logach serwera Postfix.


Dodatkowe informacje można znaleźć na poniższej stronie dodane przez autora serwera Postfix Wietse Venema zawierające wyjaśnienie powyższych przyczyn powodujących pojawianie się niniejszych komunikatów w logach serwera Postfix:
http://www.iredmail.org/forum/topic5073-iredmail-support-address-not-listed-for-hostname.html
Interesujący cytat z powyższej strony:
Re: address not listed for hostname

Caused by incorrect reverse DNS:

$ host 198.52.115.74
74.115.52.198.in-addr.arpa domain name pointer 74-115-52-198-dedicated.multacom.com.

$ host 74-115-52-198-dedicated.multacom.com
74-115-52-198-dedicated.multacom.com has address 204.13.152.7

Reference: http://tech.groups.yahoo.com/group/post...age/274279 (Wietse wrote this post, he is author of Postfix)

Wietse wrote:
    
FYI,

I have changed the warnings from the code that implements
forward-confirmed reverse DNS (FCRDNS).

When the "reverse" name has no IP address:

hostname foo.example.com does not resolve to address 1.2.3.4:
host not found, try again

When the "reverse" has some address but not the expected address:

hostname foo.example.com does not resolve to address 1.2.3.4

The old warnings were very different.

1.2.3.4: hostname foo.example.com verification failed: host
not found, try again

1.2.3.4: address not listed for hostname foo.example.com

That's in both smtpd(8) and qmqpd(8).

Wietse



#top hostname verification failed: Name or service not known


Feb  6 01:45:21 wbcd postfix/smtpd[17148]: warning: 77.121.14.122: hostname undefined.sim.volia.net verification failed: Name or service not known
Feb  6 01:45:21 wbcd postfix/smtpd[17148]: connect from unknown[77.121.14.122]
Feb  6 01:45:22 wbcd postfix/smtpd[17148]: disconnect from unknown[77.121.14.122]

(stan z dnia 2015/12/02)
dig -t PTR +noauth +noadditional 122.14.121.77.in-addr.arpa


; <<>> DiG 9.3.4-P1 <<>> -t PTR +noauth +noadditional 122.14.121.77.in-addr.arpa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32861
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;122.14.121.77.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
122.14.121.77.in-addr.arpa. 2990 IN     PTR     undefined.sim.volia.net.

;; Query time: 16 msec
;; SERVER: 10.0.0.3#53(10.0.0.3)
;; WHEN: Mon Feb  6 08:11:30 2017
;; MSG SIZE  rcvd: 192

(stan z dnia 2015/12/02)
dig -t MX +noauth +noadditional undefined.sim.volia.net


; <<>> DiG 9.3.4-P1 <<>> -t MX +noauth +noadditional undefined.sim.volia.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50586
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;undefined.sim.volia.net.       IN      MX

;; Query time: 93 msec
;; SERVER: 10.0.0.3#53(10.0.0.3)
;; WHEN: Mon Feb  6 08:12:18 2017
;; MSG SIZE  rcvd: 106



#top Malformed DNS server reply


Co oznacza powyższy komunikat pojawiający się w logach oraz jak należy go interpretować:
Dla łatwiejszego zrozumienia przyczyny powstawania takiego komunikatu zostanie to prześledzone na podstawie poniższego przypadku.
Serwer Postfix odrzucił wiadomość z kodem i informacją:
450 4.1.8 <sanjaykathleensanjaykuma009@hotmal.com>: Sender address rejected: Malformed DNS server reply
oraz w logu pojawił się następujący komunikat: 
Dec  2 14:55:08 wbcd postfix/smtpd[28160]: connect from mail.huaicana.fin.ec[186.46.56.42]
Dec  2 14:55:09 wbcd postfix/smtpd[28160]: warning: valid_hostname: empty hostname
Dec  2 14:55:09 wbcd postfix/smtpd[28160]: warning: malformed domain name in resource data of MX record for hotmal.com:
Dec  2 14:55:09 wbcd postfix/smtpd[28160]: NOQUEUE: reject: RCPT from mail.huaicana.fin.ec[186.46.56.42]: 450 4.1.8 <sanjaykathleensanjaykuma009@hotmal.com>: Sender address rejected: Malformed DNS server reply; from=<sanjaykathleensanjaykuma009@hotmal.com> to=<*****@wbcd.pl> proto=ESMTP helo=<mail.huaicana.fin.ec>
Dec  2 14:55:09 wbcd postfix/smtpd[28160]: disconnect from mail.huaicana.fin.ec[186.46.56.42]

Aby zrozumieć przyczynę powstania powyższego komunikatu wystarczy sprawdzić wpis MX (MX_record) dla domeny hotmal.com, poniżej przedstawiono wyniki dla zapytania o rekord MX (MX_record) domeny hotmal.com z użyciem poleceń dig oraz host (stan z dnia 2015/12/02).

dig -t MX +noauth +noadditional hotmal.com


;; QUESTION SECTION:
;hotmal.com.                    IN      MX

;; ANSWER SECTION:
hotmal.com.             1473    IN      MX      10 .


host -t MX hotmal.com


hotmal.com mail is handled by 10 .

Zgodnie z powyższymi wynikami domena hotmal.com posiada wpis MX (MX_record) wskazujący na nieprawidłową nazwę (pustą, informacja również pojawia się w logach jako ostrzeżenie: warning: valid_hostname: empty hostname) serwera odbierającego pocztę dla wspomnianej domeny.
Dodatkowo rekord TXT (TXT_Record) dla domeny hotmal.com również nie zawiera prawidłowych informacji, w szczególności definicja wpisu SPF (Sender_Policy_Framework, Sender_Policy_Framework) dla wspomnianej domeny nie zawiera poprawnych informacji, poniżej przedstawiono wyniki dla zapytania o rekord TXT (TXT_Record) domeny hotmal.com z użyciem poleceń dig oraz host (stan z dnia 2015/12/02).

dig -t TXT +noauth +noadditional hotmal.com


;; QUESTION SECTION:
;hotmal.com.                    IN      TXT

;; ANSWER SECTION:
hotmal.com.             3579    IN      TXT     "v=DMARC1\; p=reject"
hotmal.com.             3579    IN      TXT     "v=spf1 -all"


host -t TXT hotmal.com


hotmal.com descriptive text "v=spf1 -all"
hotmal.com descriptive text "v=DMARC1\; p=reject"



#top valid_hostname: misplaced delimiter:


Co oznacza powyższy komunikat pojawiający się w logach oraz jak należy go interpretować:
Dla łatwiejszego zrozumienia przyczyny powstawania takiego komunikatu zostanie to prześledzone na podstawie poniższego przypadku.
Oct 15 06:01:11 wbcd postfix/smtpd[30886]: warning: valid_hostname: misplaced delimiter: .
Oct 15 06:01:11 wbcd postfix/smtpd[30886]: connect from unknown[89.163.203.38]
Oct 15 06:01:11 wbcd postfix/smtpd[30886]: disconnect from unknown[89.163.203.38]

Oct 15 10:39:26 wbcd postfix/smtpd[18607]: warning: valid_hostname: misplaced delimiter: .
Oct 15 10:39:26 wbcd postfix/smtpd[18607]: connect from unknown[89.163.203.38]
Oct 15 10:39:26 wbcd postfix/smtpd[18607]: disconnect from unknown[89.163.203.38]

Oct 15 15:19:37 wbcd postfix/smtpd[3441]: warning: valid_hostname: misplaced delimiter: .
Oct 15 15:19:37 wbcd postfix/smtpd[3441]: connect from unknown[89.163.203.38]
Oct 15 15:19:37 wbcd postfix/smtpd[3441]: disconnect from unknown[89.163.203.38]

Oct 15 19:59:46 wbcd postfix/smtpd[20165]: warning: valid_hostname: misplaced delimiter: .
Oct 15 19:59:46 wbcd postfix/smtpd[20165]: connect from unknown[89.163.203.38]
Oct 15 19:59:46 wbcd postfix/smtpd[20165]: disconnect from unknown[89.163.203.38]

Aby zrozumieć przyczynę powstania powyższego komunikatu wystarczy sprawdzić rewers dla adresu IP 89.163.203.38, poniżej przedstawiono wyniki dla zapytania o rewers dla adresu 89.163.203.38 z użyciem poleceń dig oraz host (stan z dnia 2016/10/16).

dig -t PTR +noauth +noadditional 38.203.163.89.in-addr.arpa


;; QUESTION SECTION:
;38.203.163.89.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
38.203.163.89.in-addr.arpa. 42719 IN    PTR     .


host -t PTR 89.163.203.38


38.203.163.89.in-addr.arpa domain name pointer .

Zgodnie z powyższymi wynikami adres IP 89.163.203.38 posiada rewers PTR wskazujący na nieprawidłową nazwę (pustą, informacja również pojawia się w logach jako ostrzeżenie: warning: valid_hostname: misplaced delimiter: .) hosta który połączył się z serwerem Postfix.



#top warning: hostname verification failed: No address associated with hostname


Co oznacza powyższy komunikat pojawiający się w logach oraz jak należy go interpretować:
Dla łatwiejszego zrozumienia przyczyny powstawania takiego komunikatu zostanie to prześledzone na podstawie poniższego przypadku.
Dec 27 23:20:58 wbcd postfix/smtpd[7689]: warning: 197.249.5.116: hostname apiex.gov.mz verification failed: No address associated with hostname

Aby zrozumieć przyczynę powstania powyższego komunikatu wystarczy sprawdzić rewers dla adresu IP 197.249.5.116, poniżej przedstawiono wyniki dla zapytania o rewers dla adresu 197.249.5.116 z użyciem poleceń dig oraz host (stan z dnia 2018/12/27).

dig -t PTR +noauth +noadditional 116.5.249.197.in-addr.arpa


;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;116.5.249.197.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
116.5.249.197.in-addr.arpa. 10800 IN    PTR     apiex.gov.mz.
116.5.249.197.in-addr.arpa. 10800 IN    PTR     apiex.co.mz.
116.5.249.197.in-addr.arpa. 10800 IN    PTR     gazeda.gov.mz.


host -t PTR 197.249.5.116


116.5.249.197.in-addr.arpa domain name pointer gazeda.gov.mz.
116.5.249.197.in-addr.arpa domain name pointer apiex.co.mz.
116.5.249.197.in-addr.arpa domain name pointer apiex.gov.mz.

Zgodnie z powyższymi wynikami adres IP 197.249.5.116 posiada rewers PTR wskazujący na 3 nazwy domenowe. Dla każdej z tych wyników sprawdzono czy nazwa posiada prawidłowy wpis typu A (czyli posiada adres IPv4, sprawdzanie wpisów AAAA pominięto, gdyż żadna z tych nazwa nie pisada adresu IPv6). Wyniki są następujące:

Dla nazwy gazeda.gov.mz otrzymano następujący rezultat:
dig -t A +noauth +noadditional gazeda.gov.mz


;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gazeda.gov.mz.                 IN      A

;; ANSWER SECTION:
gazeda.gov.mz.          10800   IN      A       197.249.5.116


host -t A gazeda.gov.mz


gazeda.gov.mz has address 197.249.5.116

Dla nazwy apiex.co.mz otrzymano następujący rezultat:
dig -t A +noauth +noadditional apiex.co.mz


;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;apiex.co.mz.                   IN      A

;; ANSWER SECTION:
apiex.co.mz.            10800   IN      A       197.249.5.116


host -t A apiex.co.mz


apiex.co.mz has address 197.249.5.116

Dla nazwy apiex.gov.mz otrzymano następujący rezultat:
dig -t A +noauth +noadditional apiex.gov.mz


;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;apiex.gov.mz.                  IN      A


host -t A apiex.gov.mz


apiex.gov.mz has no A record

Zgodnie z powyższymi wynikami nazwa apiex.gov.mz nie posiada rekordu A, jak również rekordu AAAA (informacja pojawia się w logach jako ostrzeżenie: warning: 197.249.5.116: hostname apiex.gov.mz verification failed: No address associated with hostname) będąca wpisem rewers dla hosta który połączył się z serwerem Postfix.



#top numeric domain name in resource data of MX record


Co oznacza powyższy komunikat pojawiający się w logach oraz jak należy go interpretować:
Dla łatwiejszego zrozumienia przyczyny powstawania takiego komunikatu zostanie to prześledzone na podstawie poniższego przypadku.
Aug 19 16:23:41 wbcd postfix/smtpd[20870]: warning: numeric domain name in resource data of MX record for mailing.apcompany.ltd: 54.38.48.60

Aby zrozumieć przyczynę powstania powyższego komunikatu wystarczy sprawdzić serwery MX dla domeny mailing.apcompany.ltd, poniżej przedstawiono wyniki dla zapytania o rewers dla adresu mailing.apcompany.ltd z użyciem poleceń dig oraz host (stan z dnia 2019/08/19).

dig -t MX +noauth +noadditional mailing.apcompany.ltd


;; QUESTION SECTION:
;mailing.apcompany.ltd.         IN      MX

;; ANSWER SECTION:
mailing.apcompany.ltd.  300     IN      MX      10 51.38.142.133.


host -t MX mailing.apcompany.ltd


mailing.apcompany.ltd mail is handled by 10 51.38.142.133.

Zgodnie z powyższymi wynikami domena mailing.apcompany.ltd posiada serwer MX wskazujący na nieprawidłową nazwę (adres IP zamiast nazwy domenową, informacja również pojawia się w logach jako ostrzeżenie: warning: numeric domain name in resource data of MX record for mailing.apcompany.ltd: 54.38.48.60) hosta który połączył się z serwerem Postfix.
Zgodnie ze specyfikacją RFC 974 oraz RFC 1035
RFC 974
Each MX matches a domain name with two pieces of data, a preference value (an unsigned 16-bit integer), and the name of a host.
RFC 1035
MX RDATA format
PREFERENCE EXCHANGE
where:
PREFERENCE - A 16 bit integer which specifies the preference given to this RR among others at the same owner. Lower values are preferred.
EXCHANGE - A <domain-name> which specifies a host willing to act as a mail exchange for the owner name.
każdy wpis MX składa się z dwóch części: liczby określającej preferencję kolejności wyboru serwera oraz nazwy serwera (nazwa domenowa).



#top warning: the Postfix sendmail command has set-uid root file permissions


Więcej informacji w analogicznym zagadnieniu: Postfix sendmail and set-uid bit

Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: the Postfix sendmail command has set-uid root file permissions
Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: or the command is run from a set-uid root process
Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: the Postfix sendmail command must be installed without set-uid root file permissions



#top warning: or the command is run from a set-uid root process


Więcej informacji w analogicznym zagadnieniu: Postfix sendmail and set-uid bit

Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: the Postfix sendmail command has set-uid root file permissions
Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: or the command is run from a set-uid root process
Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: the Postfix sendmail command must be installed without set-uid root file permissions



#top warning: the Postfix sendmail command must be installed without set-uid root file permissions


Więcej informacji w analogicznym zagadnieniu: Postfix sendmail and set-uid bit

Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: the Postfix sendmail command has set-uid root file permissions
Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: or the command is run from a set-uid root process
Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: the Postfix sendmail command must be installed without set-uid root file permissions



#top Postfix sendmail and set-uid bit


Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: the Postfix sendmail command has set-uid root file permissions
Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: or the command is run from a set-uid root process
Nov 15 11:15:15 wbcd postfix/sendmail[7278]: warning: the Postfix sendmail command must be installed without set-uid root file permissions

Wyjaśnienie przyczyny pojawiania się powyższych komunikatów w logach mozna znaleźć na poniższych stronach:

Postfix sendmail command has set-uid root file permissions
https://bugs.centos.org/view.php?id=5571

"Postfix sendmail command has set-uid root file permissions" error occurs.
https://access.redhat.com/solutions/76483



Dla łatwiejszego zrozumienia przyczyny pojawiania się w logach powyższego komunikatu zostanie to prześledzone poniżej.

Za pojawianie się w logach powyższego komunikatu odpowiedzialny jest poniższy fragment kodu znajdujący się w pliku sendmail.c w kodzie źródłowym serwera Postfix.
SELECT ALL
	/*
	 * Some sites mistakenly install Postfix sendmail as set-uid root. Drop
	 * set-uid privileges only when root, otherwise some systems will not
	 * reset the saved set-userid, which would be a security vulnerability.
	 */
	if (geteuid() == 0 && getuid() != 0) {
		msg_warn("the Postfix sendmail command has set-uid root file permissions");
		msg_warn("or the command is run from a set-uid root process");
		msg_warn("the Postfix sendmail command must be installed without set-uid root file permissions");
		set_ugid(getuid(), getgid());
	}
getuid() returns the real user ID of the current process.
geteuid() returns the effective user ID of the current process.
Zgodnie z powyższym fragmentem kodu kiedy efektywny identyfikator użytkownika (Effective User ID) procesu jest równy 0 ale rzeczywisty identyfikator użytkownika (Real User ID) jest różny od zera to nastąpiła sytuacja w której użytkownik posiadający rzeczywisty identyfikator uruchomił proces (program) posiadający ustawiony bit set-uid, dzięki któremu program posiada uprawnienia superużytkownika bez względu na to kto uruchamił proces (program).
Taki bit set-uid mają ustawione m.in. polecenia su, sudo, crontab pozwalające w sposób konfiguracyjnie kontrolowalny uruchamiać określonym użytkownikom ściśle określone polecenia z uprawnieniami innego użytkownika.

Zgodnie z powyższym komunikatem komenda sendmail z pakietu Postfix posiada ustawiony bit set-uid.
Zweryfikować tę informację można komendą ls (poniżej został użyty alias wywołujący komendę z opcją długiego listowania) poprzez wyświetlenie atrybutów i uprawnień komendy sendmail z pakietu Postfix:
ll /usr/sbin/sendmail /etc/alternatives/mta /usr/sbin/sendmail.postfix

Rezultat powyższego wylistowania:
lrwxrwxrwx. 1 root root     26 2012-03-03 00:51 /etc/alternatives/mta -> /usr/sbin/sendmail.postfix*
lrwxrwxrwx. 1 root root     21 2012-03-03 00:51 /usr/sbin/sendmail -> /etc/alternatives/mta*
-rwxr-xr-x. 1 root root 213616 2010-11-11 17:10 /usr/sbin/sendmail.postfix*

Zgodnie z powyższym rezultatem komenda sendmail nie posiada na liście uprawnień ustawionego bitu set-uid.
Powyższy komunikat pojawia się w logach pomimo, że komenda sendmail nie posiadda na liście uprawnień ustawione bitu set-uid

Aby zrozumieć kiedy powyższy warunek w przedstawionym kodzie zostanie spełniony zostanie to przedstawione na poniższym przykładzie programu getuid znajdującego się w sekcji: Programowanie / ANSI C / Posix. W tym celu po skompilowaniu programu należy zmienić właściciela programu oraz ustawić bity set-uid oraz set-gid.
chown root:root /home/local/code/ansiccode/posix/getuid
chmod ug+s /home/local/code/ansiccode/posix/getuid

Następnie komendą ls należy wyświetlić rezultat wprowadzonych zmian.
ll /home/local/code/ansiccode/posix/getuid

Rezultat wprowadzonych zmian powienien być analogiczny do poniższego:
-rwsrwsr-x. 1 root root 5952 2014-06-20 10:05 /home/local/code/ansiccode/posix/getuid*

Następnie należy tak przygotowany program uruchomić z konta zwykłego użytkownika (w tym przypadku zostało to wykonane z konta użytkownika, którego identyfikator użytkownika (Real User ID) to UID=501 oraz identyfikator grupy (Real Group ID) to GID=100):
/home/local/code/ansiccode/posix/getuid

Rezultat został przedstawiony poniżej:
DO using sudo or as root and then execute:
------------------------------------------
chown root:root /home/local/code/ansiccode/posix/getuid
chmod ug+s /home/local/code/ansiccode/posix/getuid

getuid: myuid=getuid(): myuid=501
getuid: myeuid=geteuid(), myeuid=0
getuid: mygid=getgid(): mygid=100
getuid: myegid=getegid(): myegid=0
getuid: myuid=501 myeuid=0 mygid=100 myegid=0

Jak widać powyżej identyfikator użytkownika (Real User ID) oraz identyfikator grupy (Real Group ID), który uruchomił powyższe polecenie jest taki sam jaki uruchomił polecenie UID=501 oraz GID=100. Natomiast efektywny identyfikator użytkownika (Effective User ID) oraz efektywny identyfikator grupy (Effective Group ID) jest taki sam jak właściciela programu. Jest to spowodowane właśnie bitami set-uid oraz set-gid, które zmieniają efektywny identyfikator użytkownika (Effective User ID) oraz efektywny identyfikator grupy (Effective Group ID) na identyfikator właściciela uruchamanego programu EUID=0 oraz EGID=0. Na podstawie powyższego przykładu nasuwa się następujący wniosek: program należący do użytkownika posiadającego UID=0 oraz GID=0 posiada ustawiony bit set-uid, który następnie uruchamił program sendmail, czego efektem jest spełnienie przedstawionego powyżej warunku w powyższym fragmencie kodu (proces potomny dziedziczy uprawnienia procesu, który go uruchomił), a tym samym program sendmail powoduje pojawianie się powyższych komunikatów w logach serwera poczty.



#top Network is unreachable


W przypadku dostępnej w systemie obsługi adresacji IPv6 oraz włączonej obsługi protokołu IPv6 (inet_protocols (default: all) - domyślnie obsługa jest włączona) przy próbie wysyłania wiadomości do domeny, której serwery MX posiadają adresy IPv6 mogą wystąpić problemy wynikające z braku możliwości połączenia się z serwerami MX z użyciem adresacji IPv6, co można zaobserwować w logach serwera pocztowego (poniżej został przedstawiony fragment na którym można zaobserwować jakie informacje pojawiły się w logach).

tail -F /var/log/mail/mail.log


Sep 29 09:34:43 wbcd postfix/smtpd[6597]: connect from xnd.nat.wbcd.pl[fd0a:2002:10:0:a::3]
Sep 29 09:34:44 wbcd postfix/smtpd[6597]: setting up TLS connection from xnd.nat.wbcd.pl[fd0a:2002:10:0:a::3]
Sep 29 09:34:44 wbcd postfix/smtpd[6597]: Anonymous TLS connection established from xnd.nat.wbcd.pl[fd0a:2002:10:0:a::3]: TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Sep 29 09:34:45 wbcd postfix/smtpd[6597]: 55D7E1977BF: client=xnd.nat.wbcd.pl[fd0a:2002:10:0:a::3], sasl_method=PLAIN, sasl_username=*****@wbcd.pl
Sep 29 09:34:45 wbcd postfix/cleanup[6630]: 55D7E1977BF: message-id=<20180929.093445@xnd.nat.wbcd.pl>
Sep 29 09:34:45 wbcd postfix/qmgr[6559]: 55D7E1977BF: from=<******@wbcd.pl>, size=637, nrcpt=1 (queue active)
Sep 29 09:34:45 wbcd postfix/smtpd[6597]: disconnect from xnd.nat.wbcd.pl[fd0a:2002:10:0:a::3]
Sep 29 09:34:45 wbcd postfix/smtpd[6633]: connect from wbcd.pl[10.5.5.5]
Sep 29 09:34:45 wbcd postfix/smtpd[6633]: B7BBC1977C0: client=wbcd.pl[10.5.5.5]
Sep 29 09:34:45 wbcd postfix/cleanup[6630]: B7BBC1977C0: message-id=<20180929.093445@xnd.nat.wbcd.pl>
Sep 29 09:34:45 wbcd postfix/qmgr[6559]: B7BBC1977C0: from=<*****@wbcd.pl>, size=882, nrcpt=1 (queue active)
Sep 29 09:34:45 wbcd postfix/smtpd[6633]: disconnect from wbcd.pl[10.5.5.5]
Sep 29 09:34:45 wbcd postfix/smtp[6631]: 55D7E1977BF: to=<test*****@*.pl>, relay=10.5.5.5[10.5.5.5]:10025, delay=0.65, delays=0.27/0.03/0.15/0.19, dsn=2.0.0, status=sent (250 Ok: queued as B7BBC1977C0)
Sep 29 09:34:45 wbcd postfix/qmgr[6559]: 55D7E1977BF: removed
Sep 29 09:34:49 wbcd postfix/smtp[6635]: connect to aspmx3.googlemail.com[2607:f8b0:400e:c09::1a]:25: Network is unreachable
Sep 29 09:34:49 wbcd postfix/smtp[6635]: connect to alt1.aspmx.l.google.com[2404:6800:4008:c01::1a]:25: Network is unreachable
Sep 29 09:34:49 wbcd postfix/smtp[6635]: connect to aspmx.l.google.com[2a00:1450:4010:c0b::1a]:25: Network is unreachable
Sep 29 09:34:49 wbcd postfix/smtp[6635]: connect to alt2.aspmx.l.google.com[2607:f8b0:400e:c09::1a]:25: Network is unreachable
Sep 29 09:34:49 wbcd postfix/smtp[6635]: connect to aspmx2.googlemail.com[2404:6800:4008:c01::1b]:25: Network is unreachable
Sep 29 09:34:49 wbcd postfix/smtp[6635]: B7BBC1977C0: to=<test*****@*****.pl>, relay=none, delay=3.6, delays=0.11/0.04/3.4/0, dsn=4.4.1, status=deferred (connect to aspmx2.googlemail.com[2404:6800:4008:c01::1b]:25: Network is unreachable)


Zgodnie z dokumentacją: inet_protocols (default: all)
When IPv4 support is enabled via the inet_protocols parameter, Postfix will look up DNS type A records, and will convert IPv4-in-IPv6 client IP addresses (::ffff:1.2.3.4) to their original IPv4 form (1.2.3.4). The latter is needed on hosts that pre-date IPV6_V6ONLY support (RFC 3493).
When IPv6 support is enabled via the inet_protocols parameter, Postfix will do DNS type AAAA record lookups.
When both IPv4 and IPv6 support are enabled, the Postfix SMTP client will choose the protocol as specified with the smtp_address_preference parameter. Postfix versions before 2.8 attempt to connect via IPv6 before attempting to use IPv4.
co w praktyce niestety oznacza, że serwer Postfix w wersji wcześniejszej niż 2.8 po rozwiązaniu z sukcesem nazwy serwera MX na adres(y) IPv6 będzie próbował połączyć się z serwerem MX używając adresów IPv6. W przypadku nie powodzenia serwer Postfix użyje nastepnego na liście serwera MX nie próbując nawet nawiązywać połączenia z użyciem adresacji IPv4.

Jednym ze sposobów rozwiązania takiego problemu jest włączenie obsługi tylko i wyłącznie protokołu IPv4, w tym celu należy w pliku konfiguracyjnym /etc/postfix/main.cf ustawić opcję (inet_protocols) tak jak poniżej:
# NOTE: enable only IPv4, but this disable IPv6,
inet_protocols = ipv4
niestety to wyłącza osbługę protokołu IPv6 przez serwer nawet dla lokalnych połączeń (zarówno w obrębie localhost jak również lokalnej podsieci, w której może być skonfigurowana adresacja IPv6, dostępna tylko dla danej sieci LAN).



Inny sposób rozwiązania takiego problemu wymaga posiadania co najmniej wersji 2.8 serwera Postfix, w którym została dodana odpowiednia opcja smtp_address_preference pozwalająca wybrać preferowaną w pierwszej kolejności adresację dla połączeń wychodzących. W przypadku serwera Postfix w wersji 2.8 i późniejszych należy upewnić się, że opcja smtp_address_preference jest ustawiona na wartość domyślną, a jeśli nie to ustawić ją w pliku konfiguracyjnym /etc/postfix/main.cf na wartość tak jak poniżej:
# NOTE: enable smtp address preference to both: IPv4 and IPv6,
smtp_address_preference = any

Zgodnie z dokumentacją: smtp_address_preference (default: any)
The address type ("ipv6", "ipv4" or "any") that the Postfix SMTP client will try first, when a destination has IPv6 and IPv4 addresses with equal MX preference. This feature has no effect unless the inet_protocols setting enables both IPv4 and IPv6.
Postfix SMTP client address preference has evolved. With Postfix 2.8 the default is "ipv6"; earlier implementations are hard-coded to prefer IPv6 over IPv4.
Notes for mail delivery between sites that have both IPv4 and IPv6 connectivity:
  • The setting "smtp_address_preference = ipv6" is unsafe. It can fail to deliver mail when there is an outage that affects IPv6, while the destination is still reachable over IPv4.
  • The setting "smtp_address_preference = any" is safe. With this, mail will eventually be delivered even if there is an outage that affects IPv6 or IPv4, as long as it does not affect both.
This feature is available in Postfix 2.8 and later.
co oznacza, że wiadomość zostanie dostarczona nawet w przypadku pojawienia się problemów z połączeniem sieciowym z użyciem adresacji IPv6 lub IPv4, pod warunkiem, że problem z połączeniem sieciowym będzie dotyczyć tylko jednej z tych adresacji, a nie obydwu jednocześnie.



Znacznie lepszym rozwiązaniem jest skonfigurowanie transportu dla połączeń wychodzących z włączoną obsługą tylko protokołu IPv4.
W tym celu w pliku konfiguracyjnym /etc/postfix/master.cf należy wprowadzić zmiany analogiczne jak poniżej (oczywiście należy dodać transport, który nie jest poprzedzony znakiem komentarza, analogicznie jak poniżej, transport poprzedzony znakiem komentarza zostanie zignorowany):
smtpout4  unix  -       -       n       -       -       smtp -o inet_protocols=ipv4
#smtpout6  unix  -       -       n       -       -       smtp -o inet_protocols=ipv6
#smtpoutA  unix  -       -       n       -       -       smtp -o inet_protocols=all
W pliku konfiguracyjnym /etc/postfix/main.cf należy zmodyfikować opcję konfiguracyjną transport_maps, do istniejacej mapy typu hash dodać jeszcze jedną mapę typu pcre:
# TRANSPORT MAP
#
# See the discussion in the ADDRESS_REWRITING_README document.
transport_maps = hash:/etc/postfix/transport, pcre:/etc/postfix/transportsmtp.pcre

Dla domen, które są osbługiwane przez serwer (oraz serwery znajdujące się w podsieci LAN, w której jest skonfigurowana adresacja IPv6) należy ustawić null transport i null nexthop, dzięki czemu poczta adresowana do serwera będzie przetwarzana w sposób bez zmian. Natomiast poczta wysyłana do domen po lokalną podsiecią, która nie jest dostępna za pośrednictwem adresacji IPv6 będzie wysyłana z użyciem transportu smtpout4 skonfigurowanego w taki sposób aby używać tylko adresacji IPv4.
W tym celu w pliku konfiguracyjnym /etc/postfix/transportsmtp.pcre będącym mapą typu pcre należy dodać następujące wpisy:
/wbcd.pl$/      :
/.*/            smtpout4:
Zgodnie z dokumentacją transport - Postfix transport table format null transport i null nexthop jest to sam znak : z pominięciem zarówno nazwy transportu jak również nazwy/adresu serwera przeznaczenia dla domeny,
A null transport and null nexthop result means "do not change":
use the delivery transport and nexthop information
that would be used when the entire transport table did not exist.

In order to deliver internal mail directly, while using a mail relay
for all other mail, specify a null entry for internal destinations (do
not change the delivery transport or the nexthop information) and
specify a wildcard for all other destinations.
my.domain    :
.my.domain   :
*            smtp:outbound-relay.my.domain

Po przeprowadzeniu testu informacje zawarte w logach serwera pocztowego potwierdzają działanie konfiguracji zgodne z oczekiwaniem, zarówno dla poczty wysyłanej do adresów poza lokalną podsiecią LAN, jak również w obrębie lokalnej podsieci LAN:

tail -F /var/log/mail/mail.log


Sep 29 09:36:52 wbcd postfix/smtpd[8097]: connect from cen05.xen.wbcd.pl[fd0a:2002:10:41:a:29:0:32]
Sep 29 09:36:52 wbcd postfix/smtpd[8097]: setting up TLS connection from cen05.xen.wbcd.pl[fd0a:2002:10:41:a:29:0:32]
Sep 29 09:36:52 wbcd postfix/smtpd[8097]: Anonymous TLS connection established from cen05.xen.wbcd.pl[fd0a:2002:10:41:a:29:0:32]: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Sep 29 09:36:52 wbcd postfix/smtpd[8097]: EBB1E1977BF: client=cen05.xen.wbcd.pl[fd0a:2002:10:41:a:29:0:32]
Sep 29 09:36:52 wbcd postfix/cleanup[8115]: EBB1E1977BF: message-id=<20180929.093652@xnd.nat.wbcd.pl>
Sep 29 09:36:53 wbcd postfix/qmgr[8048]: EBB1E1977BF: from=<*****@cen05.xen.wbcd.pl>, size=936, nrcpt=1 (queue active)
Sep 29 09:36:53 wbcd postfix/smtpd[8097]: disconnect from cen05.xen.wbcd.pl[fd0a:2002:10:41:a:29:0:32]
Sep 29 09:36:53 wbcd postfix/smtpd[8118]: connect from wbcd.pl[10.5.5.5]
Sep 29 09:36:53 wbcd postfix/smtpd[8118]: 341841977C0: client=wbcd.pl[10.5.5.5]
Sep 29 09:36:53 wbcd postfix/cleanup[8115]: 341841977C0: message-id=<20180929.093652@xnd.nat.wbcd.pl>
Sep 29 09:36:53 wbcd postfix/qmgr[8048]: 341841977C0: from=<*****@cen05.xen.wbcd.pl>, size=1297, nrcpt=1 (queue active)
Sep 29 09:36:53 wbcd postfix/smtpd[8118]: disconnect from wbcd.pl[10.5.5.5]
Sep 29 09:36:53 wbcd postfix/smtp[8116]: EBB1E1977BF: to=<*****@wbcd.pl>, relay=10.5.5.5[10.5.5.5]:10025, delay=0.54, delays=0.22/0.03/0.04/0.25, dsn=2.0.0, status=sent (250 Ok: queued as 341841977C0)
Sep 29 09:36:53 wbcd postfix/qmgr[8048]: EBB1E1977BF: removed
Sep 29 09:36:54 wbcd dovecot: lda(*****@wbcd.pl): sieve: msgid=<20180929.093652@xnd.nat.wbcd.pl>: stored mail into mailbox 'INBOX' realsize=1334 virtsize=1365 From=*****@cen05.xen.wbcd.pl Subject=IPv4/IPv6 transport test
Sep 29 09:36:54 wbcd postfix/pipe[8125]: 341841977C0: to=<*****@wbcd.pl>, orig_to=<*****@wbcd.pl>, relay=dovecot, delay=0.81, delays=0.14/0.03/0/0.63, dsn=2.0.0, status=sent (delivered via dovecot service)
Sep 29 09:36:54 wbcd postfix/qmgr[8048]: 341841977C0: removed

Sep 29 09:37:16 wbcd postfix/smtpd[8097]: connect from xnd.nat.wbcd.pl[fd0a:2002:10:0:a::3]
Sep 29 09:37:16 wbcd postfix/smtpd[8097]: setting up TLS connection from xnd.nat.wbcd.pl[fd0a:2002:10:0:a::3]
Sep 29 09:37:16 wbcd postfix/smtpd[8097]: Anonymous TLS connection established from xnd.nat.wbcd.pl[fd0a:2002:10:0:a::3]: TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Sep 29 09:37:16 wbcd postfix/smtpd[8097]: CADD31977BF: client=xnd.nat.wbcd.pl[fd0a:2002:10:0:a::3], sasl_method=PLAIN, sasl_username=*****@wbcd.pl
Sep 29 09:37:16 wbcd postfix/cleanup[8115]: CADD31977BF: message-id=<20180929.093716@xnd.nat.wbcd.pl>
Sep 29 09:37:16 wbcd postfix/qmgr[8048]: CADD31977BF: from=<*****@wbcd.pl>, size=637, nrcpt=1 (queue active)
Sep 29 09:37:16 wbcd postfix/smtpd[8097]: disconnect from xnd.nat.wbcd.pl[fd0a:2002:10:0:a::3]
Sep 29 09:37:17 wbcd postfix/smtpd[8118]: connect from wbcd.pl[10.5.5.5]
Sep 29 09:37:17 wbcd postfix/smtpd[8118]: 3E78F1977C0: client=wbcd.pl[10.5.5.5]
Sep 29 09:37:17 wbcd postfix/cleanup[8115]: 3E78F1977C0: message-id=<20180929.093716@xnd.nat.wbcd.pl>
Sep 29 09:37:17 wbcd postfix/qmgr[8048]: 3E78F1977C0: from=<*****@wbcd.pl>, size=882, nrcpt=1 (queue active)
Sep 29 09:37:17 wbcd postfix/smtpd[8118]: disconnect from wbcd.pl[10.5.5.5]
Sep 29 09:37:17 wbcd postfix/smtp[8116]: CADD31977BF: to=<test*****@*****.pl>, relay=10.5.5.5[10.5.5.5]:10025, delay=0.58, delays=0.14/0/0.26/0.17, dsn=2.0.0, status=sent (250 Ok: queued as 3E78F1977C0)
Sep 29 09:37:17 wbcd postfix/qmgr[8048]: CADD31977BF: removed
Sep 29 09:37:17 wbcd postfix/smtp[8275]: setting up TLS connection to aspmx.l.google.com[64.233.162.26]:25
Sep 29 09:37:17 wbcd postfix/smtp[8275]: Trusted TLS connection established to aspmx.l.google.com[64.233.162.26]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Sep 29 09:37:17 wbcd postfix/smtp[8275]: 3E78F1977C0: to=<test*****@*****.pl>, relay=aspmx.l.google.com[64.233.162.26]:25, delay=0.66, delays=0.12/0.13/0.19/0.23, dsn=2.0.0, status=sent (250 2.0.0 OK 1538206637 k16-v6si5580131ljk.192 - gsmtp)
Sep 29 09:37:17 wbcd postfix/qmgr[8048]: 3E78F1977C0: removed



#top TLS SNI


Zobacz także TLS SNI dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także TLS SNI dla: ProFTPd | Pure-FTPd | vsftpd | Dovecot | Postfix | OpenLDAP
Zobacz także TLS SNI dla: pgpool | PostgreSQL | MySQL | Firebird

Dokumentacja Postfix: DANE TLS authentication.
When usable TLSA records are obtained for the remote SMTP server the Postfix SMTP client sends the SNI TLS extension in its SSL client hello message. This may help the remote SMTP server live up to its promise to provide a certificate that matches its TLSA records.

For purposes of protocol and cipher selection, the "dane" security level is treated like a "mandatory" TLS security level, and weak ciphers and protocols are disabled. Since DANE authenticates server certificates the "aNULL" cipher-suites are transparently excluded at this level, no need to configure this manually. RFC 6698 (DANE) TLS authentication is available with Postfix 2.11 and later.

When a DANE TLSA record specifies a trust-anchor (TA) certificate (that is an issuing CA), the strategy used to verify the peername of the server certificate is unconditionally "nexthop, hostname". Both the nexthop domain and the hostname obtained from the DNSSEC-validated MX lookup are safe from forgery and the server certificate must contain at least one of these names.

When a DANE TLSA record specifies an end-entity (EE) certificate, (that is the actual server certificate), as with the fingerprint security level below, no name checks or certificate expiration checks are applied. The server certificate (or its public key) either matches the DANE record or not. Server administrators should publish such EE records in preference to all other types.

The pre-requisites for DANE support in the Postfix SMTP client are:

  • A compile-time OpenSSL library that supports the TLS SNI extension and "SHA-2" message digests.
  • A compile-time DNS resolver library that supports DNSSEC. Postfix binaries built on an older system will not support DNSSEC even if deployed on a system with an updated resolver library.
  • The "smtp_dns_support_level" must be set to "dnssec".
  • The "smtp_host_lookup" parameter must include "dns".
  • A DNSSEC-validating recursive resolver (see note below).

The above client pre-requisites do not apply to the Postfix SMTP server. It will support DANE provided it supports TLSv1 and its TLSA records are published in a DNSSEC signed zone. To receive DANE secured mail for multiple domains, use the same hostname to add the server to each domain's MX records. There are no plans to implement SNI in the Postfix SMTP server.

Najbardziej istotny fragment z powyższej zacytowanej dokumentacji:
There are no plans to implement SNI in the Postfix SMTP server.
oznaczający, że serwer Postfix pełniący rolę serwera SMTP nie będzie wspierał funkcjonalności SNI, czyli będzie wysyłał domyślnie skonfigurowany certyfikat, bez próby dopasowania certyfikatu do wysłanej nazwy SNI w komunikacie TLS HELO.



#top SNI config


Zobacz także SNI config dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także SNI config dla: ProFTPd | Pure-FTPd | vsftpd | Dovecot | Postfix | OpenLDAP
Zobacz także SNI config dla: pgpool | PostgreSQL | MySQL | Firebird

Brak obsługi TLS SNI !!! Przeczytaj komentarz powyżej TLS SNI.



#top SNI check


Zobacz także SNI check dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także SNI check dla: ProFTPd | Pure-FTPd | vsftpd | Dovecot | Postfix | OpenLDAP
Zobacz także SNI check dla: pgpool | PostgreSQL | MySQL | Firebird

Brak obsługi TLS SNI !!! Przeczytaj komentarz powyżej TLS SNI.



#top Protocol Secure


Zobacz także Protocol Secure dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Protocol Secure dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także Protocol Secure dla: pgpool | PostgreSQL | MySQL | Firebird



#top Remove Service Version Information


Zobacz także Remove Service Version Information dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Remove Service Version Information dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także Remove Service Version Information dla: pgpool | PostgreSQL | MySQL | Firebird

(Zobacz sekcję Banner)



#top Add HTTP Response Headers Security


Zobacz także Add HTTP Response Headers Security dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Add HTTP Response Headers Security dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także Add HTTP Response Headers Security dla: pgpool | PostgreSQL | MySQL | Firebird

Niedotyczy! Zalecana konfiguracja dotyczy serwerów obsługujących protokół HTTP.



#top TLS Secure


Zobacz także TLS Secure dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także TLS Secure dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także TLS Secure dla: pgpool | PostgreSQL | MySQL | Firebird



#top Disable SSLv2/SSLv3 Protocols


Zobacz także Disable SSLv2/SSLv3 Protocols dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Disable SSLv2/SSLv3 Protocols dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także Disable SSLv2/SSLv3 Protocols dla: pgpool | PostgreSQL | MySQL | Firebird

(Zobacz sekcję TLS Protocols)
Resolution for POODLE SSLv3.0 vulnerability (CVE-2014-3566)
Vulnerability Summary for CVE-2014-3566



#top Disable weak Cipher Suites


Zobacz także Disable weak Cipher Suites dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Disable weak Cipher Suites dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także Disable weak Cipher Suites dla: pgpool | PostgreSQL | MySQL | Firebird

(Zobacz sekcję TLS CipherSuite)
MITRE CVE dictionary (CVE-2015-2808)
Vulnerability Summary for CVE-2015-2808
Ivan Ristic Mitigating the BEAST attack on TLS



#top Disable RC4 CipherSuite


Zobacz także Disable RC4 CipherSuite dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Disable RC4 CipherSuite dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także Disable RC4 CipherSuite dla: pgpool | PostgreSQL | MySQL | Firebird

Więcej informacji w analogicznym zagadnieniu: Disable weak Cipher Suites



#top Disable Anonymous CipherSuite


Zobacz także Disable Anonymous CipherSuite dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Disable Anonymous CipherSuite dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także Disable Anonymous CipherSuite dla: pgpool | PostgreSQL | MySQL | Firebird

Więcej informacji w analogicznym zagadnieniu: Disable weak Cipher Suites



#top Disable SSL Compression


Zobacz także Disable SSL Compression dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Disable SSL Compression dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także Disable SSL Compression dla: pgpool | PostgreSQL | MySQL | Firebird

(Zobacz sekcję TLS Compression)
The CRIME attack uses SSL Compression

Bug 857051 - (CRIME, CVE-2012-4929) CVE-2012-4929 SSL/TLS CRIME attack against HTTPS
The openssl packages in Red Hat Enterprise Linux 5 (starting with RHBA-2009:0181 update released in Red Hat Enterprise Linux 5.3) and 6, and also in Fedora, contain a patch that makes the library check if OPENSSL_NO_DEFAULT_ZLIB environment variable is set (can have arbitrary value, even empty string) and disable the default zlib support.

Setting the OPENSSL_NO_DEFAULT_ZLIB environment variable before starting a client or a server application using OpenSSL can be used to disable zlib compression support and hence mitigate this flaw. For example, httpd with mod_ssl has compression enabled by default in Red Hat Enterprise Linux 5 and 6, and hence it is used when client also supports it. Adding the following line to the /etc/sysconfig/httpd file:

export OPENSSL_NO_DEFAULT_ZLIB=1

and restarting the httpd service disables the use of SSL/TLS compression in mod_ssl and the compression will not be negotiated even when connecting client supports it. Note that this environment variable only affects the use of SSL/TLS protocol compression and does not affect the use of HTTP protocol compression implemented by the mod_deflate module.

CVE-2012-4929 SSL/TLS CRIME attack against HTTPS
The MITRE CVE dictionary describes this issue as:

The TLS protocol 1.2 and earlier, as used in Mozilla Firefox, Google Chrome, Qt, and other products, can encrypt compressed data without properly obfuscating the length of the unencrypted data, which allows man-in-the-middle attackers to obtain plaintext HTTP headers by observing length differences during a series of guesses in which a string in an HTTP request potentially matches an unknown string in an HTTP header, aka a "CRIME" attack.

Find out more about CVE-2012-4929 from the MITRE CVE dictionary and NIST NVD.

Vulnerability Summary for CVE-2009-1891
The TLS protocol 1.2 and earlier, as used in Mozilla Firefox, Google Chrome, Qt, and other products, can encrypt compressed data without properly obfuscating the length of the unencrypted data, which allows man-in-the-middle attackers to obtain plaintext HTTP headers by observing length differences during a series of guesses in which a string in an HTTP request potentially matches an unknown string in an HTTP header, aka a "CRIME" attack.



#top Set custom DH parameters


Zobacz także Set custom DH parameters dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Set custom DH parameters dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także Set custom DH parameters dla: pgpool | PostgreSQL | MySQL | Firebird

(Zobacz sekcję TLS Cert/Key File)



#top Avoid certificates with Signature Algorithm: SHA1


Zobacz także Avoid certificates with Signature Algorithm: SHA1 dla: Apache | Nginx | Lighttpd | thttpd | HAProxy | Varnish | SQUID
Zobacz także Avoid certificates with Signature Algorithm: SHA1 dla: ProFTPd | Pure-FTPd | vsftpd | Postfix | Dovecot | OpenLDAP
Zobacz także Avoid certificates with Signature Algorithm: SHA1 dla: pgpool | PostgreSQL | MySQL | Firebird

Mozilla plans to phase out support of SHA-1 hash algorithm
After Jan. 1, 2016, Firefox will present an "Untrusted Connection" error when a newly issued SHA-1 certificate is encountered, and after Jan. 1, 2017, Firefox will present an "Untrusted Connection" error whenever a SHA-1 certificate is encountered at all, according to a Tuesday post.

SHA-1 has been around for nearly two decades, and in recent years researchers have demonstrated SHA-1 mathematical weaknesses that could be exploited given enough time and computing power, Richard Barnes, engineering manager, cryptography and PKI, with Mozilla, told SCMagazine.com in a Wednesday email correspondence.

Mozilla Security Blog
Many of the certificates used by secure websites today are signed using algorithms based on a hash algorithm called SHA-1. The integrity of the hash algorithm used in signing a certificate is a critical element in the security of the certificate. Weaknesses in hash algorithms can lead to situations in which attackers can obtain fraudulent certificates. Mozilla, along with other browser vendors, is working on a plan to phase out support for the SHA-1 hash algorithm.

SHA-1 is nearly twenty years old, and is beginning to show its age. In the last few years, collision attacks undermining some properties of SHA-1 have been getting close to being practical. Collision attacks against the older MD5 hash algorithm have been used to obtain fraudulent certificates, so the improving feasibility of collision attacks against SHA-1 is concerning. In order to avoid the need for a rapid transition should a critical attack against SHA-1 be discovered, we are proactively phasing out SHA-1.









































Zmodyfikowany ostatnio: 2019/08/19 20:11:00 (4 lata temu), textsize: 81,6 kB, htmlsize: 108 kB
Zapraszam do komentowania, zgłaszania sugestii, propozycji, własnych przykładów, ...
Dodaj komentarzKomentarze użytkowników