user2690527's questions

我最近又更换了我的 DNS 托管商，因为我需要一些以前的 DNS 托管商不提供的功能。每次我更换 DNS 托管商时，我的服务器都会不可用几个小时，直到 DNS 再次恢复正常。我知道 DNS 是一个分布式系统，会缓存几个小时的条目，但一定有一种方法可以在不中断服务的情况下更换提供商。

以下是我采取的主要步骤：

1. 将所有 DNS 记录从之前的 DNS 托管商复制到新的 DNS 托管商。
2. 通过明确查询两个托管商的主 DNS 服务器，dig @<...>以确保两者的配置相同
3. 将新的 DNS 名称服务器告知我的注册商，并向他们提供新的 NS、DNSKEY 和 DS 设置；我的注册商将这些信息转发给 TLD 注册中心（在我的情况下.de是 -zone，即 DENIC）

在我执行第 3 步后大约一小时，我的服务器无法通过 DNS 访问。我的域名的 DNS 解析停止。大约又过了六个小时，一切才恢复正常。

如果我没记错的话，在这个特定案例中，中断是由于 NS 和 DNSKEY 记录与 DS 记录在那六个小时内不匹配造成的。NS 和 DNSKEY 记录已经更新并指向新的 DNS 托管商，而 DS 记录在接下来的六个小时内仍保持旧记录。

避免此类问题的正确方法是什么？

附录（2024-07-30）

今天，我想将我的第二个域名从以前的 DNS 托管商迁移到新的 DNS 托管商，我认为我很聪明。

我提前 48 小时禁用了 DNSSEC，以避免任何签名错误。（最好根本没有 DNSSEC，而不是 DNSSEC 失败。）但后来我又陷入了另一个陷阱。

我首先在新的 DNS 托管商处配置了 DNS 区域信息，然后告诉我的注册商将记录NS从旧 DNS 托管商更改为新 DNS 托管商。但是，更改不是原子性的。他们没有将记录NS从旧更改为新，而是将NS记录从旧值更改为“占位符” f.nic.de.，然后从更改f.nic.de.为实际的新值。这两个步骤相隔 5 分钟。不幸的是，这 5 分钟的时间窗口足以让 Google DNS (8.8.8.8) 拾取错误的中间值，f.nic.de.并且它的 TTL 为 14400，即 4 小时。

当然，f.nic.de.没有关于我实际域名的信息。因此，虽然错误只存在了 5 分钟，但它导致我的域名上某些用户的 DNS 解析中断了另外 4 小时，具体取决于他们查询的 DNS 服务器。

到目前为止，我认为我的虚拟专用服务器的托管商（它还“拥有”我的 IP 地址，也是我的域名的注册商（但不是我的 DNS 托管商））简直是愚蠢的。他们只提供了一个允许输入NS和DNSKEY记录的 Web 表单。（DS记录是从隐式计算的DNSKEY）。但是，没有添加（或删除）记录的选项。只能替换现有记录（每种类型一个）。但是，即使正确且一致地更改这两个值，然后提交 Web 表单，上游更改（在我的注册商和注册表之间）也是不可预测且无序的。鉴于以下答案，我想我除了与我的注册商讨论他们必须让他们的流程井然有序之外别无他法。

德国有一家大型电子邮件托管商 (web.de)，其邮件服务器无法将邮件发送到我的自托管 Postfix 服务器。我发现了类似的报告，但发布的解决方案总是配置错误的 TLSA 记录。不过，我确信我的 TLSA 记录没有问题。

如何解决该问题，以便我的 Postfix 服务器正确接收来自这些服务器的邮件？

• 后缀版本：3.8.5
• OpenSSL 版本：3.0.13-r2

我的 Postfix 日志：

May 08 12:05:37 server postfix/smtpd[90259]: initializing the server-side TLS engine
May 08 12:05:37 server postfix/smtpd[90259]: connect from mout.web.de[212.227.15.4]
May 08 12:05:38 server postfix/smtpd[90259]: setting up TLS connection from mout.web.de[212.227.15.4]
May 08 12:05:38 server postfix/smtpd[90259]: mout.web.de[212.227.15.4]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:!SEED:!IDEA:!3DES:!RC2:!RC4:!RC5:!kDH:!kECDH:!aDSS:!MD5:+RC4:@STRENGTH"
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:before SSL initialization
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:before SSL initialization
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS read client hello
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS write server hello
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS write change cipher spec
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:TLSv1.3 write encrypted extensions
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS write certificate
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:TLSv1.3 write server certificate verify
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS write finished
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:TLSv1.3 early data
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:TLSv1.3 early data
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS read finished
May 08 12:05:38 server postfix/smtpd[90259]: mout.web.de[212.227.15.4]: Issuing session ticket, key expiration: 1715164537
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS write session ticket
May 08 12:05:38 server postfix/smtpd[90259]: Anonymous TLS connection established from mout.web.de[212.227.15.4]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256
May 08 12:05:38 server postfix/smtpd[90259]: SSL3 alert read:fatal:insufficient security
May 08 12:05:38 server postfix/smtpd[90259]: warning: TLS library problem: error:0A00042F:SSL routines::tlsv1 alert insufficient security:../openssl-3.0.13/ssl/record/rec_layer_s3.c:1590:SSL alert number 71:
May 08 12:05:38 server postfix/smtpd[90259]: lost connection after STARTTLS from mout.web.de[212.227.15.4]
May 08 12:05:38 server postfix/smtpd[90259]: disconnect from mout.web.de[212.227.15.4] ehlo=1 starttls=1 commands=2
May

我不确定哪一方在报告“安全保障不足”。我自己这边，即Postfix/TLS服务器？或者远程端，即 web.de 邮件服务器，它是 TLS 客户端？

我的服务器提供了两个 Letsencrypt 证书：

• 一份 EC 证书，
• 一份 RSA 证书。

我的 Postfix 中的相关 TLS 指令main.cf：

# TLS PARAMETERS
#

smtpd_tls_chain_files =
  /etc/letsencrypt/live/server.my-domain.tld:smtps-ec/privkey.pem,
  /etc/letsencrypt/live/server.my-domain.tld:smtps-ec/fullchain.pem,
  /etc/letsencrypt/live/server.my-domain.tld:smtps-rsa/privkey.pem,
  /etc/letsencrypt/live/server.my-domain.tld:smtps-rsa/fullchain.pem
smtpd_tls_CApath              = /etc/ssl/certs
# note: for port 587, smtpd_tls_security_level is overwritten to `encrypt` in master.cf
smtpd_tls_security_level      = may
smtpd_tls_received_header     = yes
smtpd_tls_auth_only           = yes
smtpd_tls_ciphers             = medium
smtpd_tls_protocols           = >=TLSv1.2
smtpd_tls_mandatory_ciphers   = high
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_loglevel            = 0

smtp_tls_CApath              = /etc/ssl/certs
smtp_tls_security_level      = may
smtp_tls_note_starttls_offer = yes
smtp_tls_ciphers             = medium
smtp_tls_protocols           = >=TLSv1.2
smtp_tls_mandatory_ciphers   = high
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_loglevel            = 0

在这两种情况下，信任锚都是“ISRG Root X1”。我的 TLSA 记录是

$ dig TLSA _25._tcp.server.my-domain.tld.
_25._tcp.server.my-domain.tld.   12340 IN   CNAME   letsencrypt._dane.my-domain.tld.
letsencrypt._dane.my-domain.tld. 13104 IN   TLSA    0 1 1 0B9FA5A59EED715C26C1020C711B4F6EC42D58B0015E14337A39DAD3 01C5AFC3

对我自己的 Postfix 服务器运行 SSL Scan 会产生：

# sslscan --verbose --starttls-smtp server.my-domain.tld:25
Version: 2.1.2-static
OpenSSL 3.0.12 24 Oct 2023

Some servers will fail to response to SSLv3 ciphers over STARTTLS
If your scan hangs, try using the --tlsall option

Testing SSL server server.my-domain.tld on port 25 using SNI name server.my-domain.tld

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
OpenSSL OpenSSL 3.0.12 24 Oct 2023 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
OpenSSL OpenSSL 3.0.12 24 Oct 2023 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
Server supports TLS Fallback SCSV

  TLS renegotiation:
OpenSSL OpenSSL 3.0.12 24 Oct 2023 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
use_unsafe_renegotiation_op
Session renegotiation not supported

  TLS Compression:
OpenSSL OpenSSL 3.0.12 24 Oct 2023 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
Compression disabled

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
SSL_connect() returned: 1
Preferred TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
SSL_connect() returned: -1
SSL_get_current_cipher() returned NULL; this indicates that the server did not choose a cipher from our list (TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256)
SSL_connect() returned: 1
Preferred TLSv1.2  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-CHACHA20-POLY1305 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-RSA-CHACHA20-POLY1305   Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-CHACHA20-POLY1305     DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-CCM8       Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-CCM        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-CCM8           DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-CCM            DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-ARIA256-GCM-SHA384 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ARIA256-GCM-SHA384      Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-ARIA256-GCM-SHA384    DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ADH-AES256-GCM-SHA384         DHE 3072 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-GCM-SHA256 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256     DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-CCM8       Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-CCM        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-CCM8           DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-CCM            DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-ARIA128-GCM-SHA256 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ARIA128-GCM-SHA256      Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-ARIA128-GCM-SHA256    DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ADH-AES128-GCM-SHA256         DHE 1024 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA384     Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA256         DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-CAMELLIA256-SHA384 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-RSA-CAMELLIA256-SHA384  Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-CAMELLIA256-SHA256    DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ADH-AES256-SHA256             DHE 3072 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ADH-CAMELLIA256-SHA256        DHE 3072 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA256     Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA256       Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA256         DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-CAMELLIA128-SHA256 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-RSA-CAMELLIA128-SHA256  Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-CAMELLIA128-SHA256    DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ADH-AES128-SHA256             DHE 1024 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ADH-CAMELLIA128-SHA256        DHE 1024 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA          Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-CAMELLIA256-SHA       DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AECDH-AES256-SHA              Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ADH-AES256-SHA                DHE 3072 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ADH-CAMELLIA256-SHA           DHE 3072 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA          Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-CAMELLIA128-SHA       DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AECDH-AES128-SHA              Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ADH-AES128-SHA                DHE 1024 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ADH-CAMELLIA128-SHA           DHE 1024 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384            
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AES256-CCM8                  
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AES256-CCM                   
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ARIA256-GCM-SHA384           
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256            
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AES128-CCM8                  
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AES128-CCM                   
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ARIA128-GCM-SHA256           
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AES256-SHA256                
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  CAMELLIA256-SHA256           
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AES128-SHA256                
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  CAMELLIA128-SHA256           
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AES256-SHA                   
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  CAMELLIA256-SHA              
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AES128-SHA                   
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  CAMELLIA128-SHA              
SSL_connect() returned: -1
SSL_get_current_cipher() returned NULL; this indicates that the server did not choose a cipher from our list (ALL:COMPLEMENTOFALL:!ECDHE-ECDSA-AES256-GCM-SHA384:!ECDHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES256-GCM-SHA384:!ECDHE-ECDSA-CHACHA20-POLY1305:!ECDHE-RSA-CHACHA20-POLY1305:!DHE-RSA-CHACHA20-POLY1305:!ECDHE-ECDSA-AES256-CCM8:!ECDHE-ECDSA-AES256-CCM:!DHE-RSA-AES256-CCM8:!DHE-RSA-AES256-CCM:!ECDHE-ECDSA-ARIA256-GCM-SHA384:!ECDHE-ARIA256-GCM-SHA384:!DHE-RSA-ARIA256-GCM-SHA384:!ADH-AES256-GCM-SHA384:!ECDHE-ECDSA-AES128-GCM-SHA256:!ECDHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES128-GCM-SHA256:!ECDHE-ECDSA-AES128-CCM8:!ECDHE-ECDSA-AES128-CCM:!DHE-RSA-AES128-CCM8:!DHE-RSA-AES128-CCM:!ECDHE-ECDSA-ARIA128-GCM-SHA256:!ECDHE-ARIA128-GCM-SHA256:!DHE-RSA-ARIA128-GCM-SHA256:!ADH-AES128-GCM-SHA256:!ECDHE-ECDSA-AES256-SHA384:!ECDHE-RSA-AES256-SHA384:!DHE-RSA-AES256-SHA256:!ECDHE-ECDSA-CAMELLIA256-SHA384:!ECDHE-RSA-CAMELLIA256-SHA384:!DHE-RSA-CAMELLIA256-SHA256:!ADH-AES256-SHA256:!ADH-CAMELLIA256-SHA256:!ECDHE-ECDSA-AES128-SHA256:!ECDHE-RSA-AES128-SHA256:!DHE-RSA-AES128-SHA256:!ECDHE-ECDSA-CAMELLIA128-SHA256:!ECDHE-RSA-CAMELLIA128-SHA256:!DHE-RSA-CAMELLIA128-SHA256:!ADH-AES128-SHA256:!ADH-CAMELLIA128-SHA256:!ECDHE-ECDSA-AES256-SHA:!ECDHE-RSA-AES256-SHA:!DHE-RSA-AES256-SHA:!DHE-RSA-CAMELLIA256-SHA:!AECDH-AES256-SHA:!ADH-AES256-SHA:!ADH-CAMELLIA256-SHA:!ECDHE-ECDSA-AES128-SHA:!ECDHE-RSA-AES128-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-CAMELLIA128-SHA:!AECDH-AES128-SHA:!ADH-AES128-SHA:!ADH-CAMELLIA128-SHA:!AES256-GCM-SHA384:!AES256-CCM8:!AES256-CCM:!ARIA256-GCM-SHA384:!AES128-GCM-SHA256:!AES128-CCM8:!AES128-CCM:!ARIA128-GCM-SHA256:!AES256-SHA256:!CAMELLIA256-SHA256:!AES128-SHA256:!CAMELLIA128-SHA256:!AES256-SHA:!CAMELLIA256-SHA:!AES128-SHA:!CAMELLIA128-SHA)

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  192 bits  secp384r1 (NIST P-384)
TLSv1.3  260 bits  secp521r1 (NIST P-521)
TLSv1.3  128 bits  x25519
TLSv1.3  224 bits  x448
TLSv1.3  112 bits  ffdhe2048
TLSv1.3  128 bits  ffdhe3072
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  192 bits  secp384r1 (NIST P-384)
TLSv1.2  260 bits  secp521r1 (NIST P-521)
TLSv1.2  128 bits  x25519
TLSv1.2  224 bits  x448

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
ECC Curve Name:      secp384r1
ECC Key Strength:    192

Subject:  server.my-domain.tld
Altnames: DNS:server.my-domain.tld
Issuer:   R3

Not valid before: Mar 11 19:44:07 2024 GMT
Not valid after:  Jun  9 19:44:06 2024 GMT

知道为什么 web.de 邮件服务器不向我的 Postfix 服务器发送邮件吗？

我有一个 Postfix/Dovecot 设置并使用 OpenLDAP 作为用户/密码后端。由于虚拟主机，用户必须使用完全合格的电子邮件地址作为用户名登录，因此域部分对于身份验证是必需的，即用户名类似于<local-part>@<fqdn-domain>.

然而，不断有攻击尝试使用不带域部分的用户名进行身份验证。由于这会导致 LDAP 查询中的 DN 无效，因此我的日志中会出现大量由于 LDAP DN 无效而导致的错误消息。

是否有任何配置选项允许 Dovecot 对提供的用户名强制执行一些初始语法检查，如果失败，Dovecot 通过立即拒绝响应来缩短身份验证过程，而不是查询 LDAP 服务器然后失败？

Dovecot 中的 LDAP 配置是

uris = ldapi://%2frun%2fopenldap%2fslapd.sock
auth_bind = yes
auth_bind_userdn = uid=%n,ou=users,o=%d,dc=my-host,dc=my-domain,dc=my-tld
base = ou=users,o=%d,dc=server,dc=my-host,dc=my-domain,dc=my-tld

正如您所看到的，我的 LDAP 设置使用所谓的“连接点”在 DIT 中为不同的托管域提供不同的子分支。（o=%dDN 中的 - 部分。）根据Dovecot 配置手册 - 用户变量，%d如果用户名后面没有域部分，则为空@。

当攻击者尝试使用不完整的用户名进行身份验证时，这会导致我的日志中出现多余的错误消息，例如

Dec 26 16:25:54 server dovecot[24946]: auth: Error: ldap(root,187.205.80.184): ldap_bind() failed: Invalid DN syntax

这里，来自 187.205.80.184 的攻击者尝试以用户身份进行身份验证root，Dovecot 尝试查找uid=root,ou=users,o=,dc=my-host,dc=my-domain,dc=my-tld这显然是无效的，因为 后没有任何内容o=。

我有一个快速虚拟机，但 systemd 服务systemd-zserdbd.service失败并显示

Dec 01 17:45:32 server-new systemd[1]: Starting systemd-remount-fs.service...

...

Dec 01 17:45:32 server-new (-userdbd)[183]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system
Dec 01 17:45:32 server-new (-userdbd)[185]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system
Dec 01 17:45:32 server-new systemd[1]: Started systemd-journald.service.
Dec 01 17:45:32 server-new (-userdbd)[186]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system
Dec 01 17:45:32 server-new (-userdbd)[187]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system
Dec 01 17:45:32 server-new (-userdbd)[188]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system

...

Dec 01 17:45:32 server-new systemd-fsck[180]: /usr/bin/fsck.xfs: XFS file system.
Dec 01 17:45:32 server-new systemd[1]: Finished systemd-remount-fs.service.

...

Dec 01 17:45:32 server-new systemd[1]: Reached target local-fs-pre.target.

...

Dec 01 17:45:33 server-new systemd[1]: Reached target local-fs.target.

该错误非常明显：systemd-userdbd.service需要可写的根文件系统，但在文件系统重新挂载为可写之前启动。

systemctl edit systemd-userdbd.service --drop-in=wait-for-rw-root因此，我想通过with添加必要的依赖项

[Unit]
Wants=local-fs.target
After=systemd-userdbd.socket systemd-remount-fs.service local-fs.target

但这似乎在启动时创建了循环依赖。重新挂载文件系统需要很长时间，直到 systemd 超时。

1. 如何确保systemd-userdbd.service在根文件系统变得可写后启动而不创建循环依赖？
2. （一个更普遍的问题）我如何分析造成循环依赖的原因？

我在 Ubuntu 23.10 上运行 Postfix 3.8.1。Postfix 为来自其他 MTA 的传入邮件提供端口 25，为经过身份验证的 MUA 提供端口 587。

Postfix 应该在端口 25 上检查来自其他 MTA 的邮件的 SPF，但不会检查端口 587 上来自经过身份验证的 MUA 的邮件。但是，Postfix 会虚假地对经过身份验证的 MUA 执行此操作，并且 SPF 失败（因为该 MUA 没有被列为允许的邮件服务器） ）。

我感觉好像 Postfix 简单地忽略了 MUA 的特殊规则，但我没有发现我的配置错误。

我的master.cnf

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (no)    (never) (100)
# ==========================================================================
smtp      inet  n       -       y       -       -       smtpd
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o cleanup_service_name=header_cleanup
  -o smtpd_client_restrictions=$mua_client_restrictions
  -o smtpd_helo_restrictions=$mua_helo_restrictions
  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_relay_restrictions=$mua_relay_restrictions
header_cleanup unix n   -       -       -       0       cleanup
  -o header_checks=regexp:/etc/postfix/submission_header_cleanup.cf

上面配置的想法是smtpd在端口 587 ( submission) 上应该使用一些特殊的配置。

我的main.cf

smtpd_delay_reject = yes

smtpd_client_restrictions =
  reject_unauth_pipelining,
  reject_unknown_client_hostname
mua_client_restrictions =
  reject_unauth_pipelining

smtpd_helo_required = yes

smtpd_helo_restrictions =
  reject_invalid_helo_hostname,
  reject_non_fqdn_helo_hostname,
  reject_unknown_helo_hostname
mua_helo_restrictions =
  reject_invalid_helo_hostname

strict_rfc821_envelopes = yes

smtpd_sender_restrictions =
  reject_non_fqdn_sender,
  reject_unknown_sender_domain
mua_sender_restrictions =
  reject_non_fqdn_sender,
  reject_unknown_sender_domain
  reject_plaintext_session,
  reject_sender_login_mismatch

smtpd_relay_restrictions =
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  reject_unauth_destination
mua_relay_restrictions =
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  permit_sasl_authenticated,
  reject

smtpd_recipient_restrictions =
  check_policy_service unix:private/policyd-spf,
  permit

policyd-spf_time_limit = 3600

smtpd_sasl_type=dovecot
smtpd_sasl_path=private/auth
smtpd_sasl_auth_enable=no

这个想法是，经过mua_relay_restrictions身份验证的客户端将被无条件允许，而其他一切都会被拒绝。这意味着对于经过身份验证的客户端，访问控制应该停止于此。这也是为什么smtpd_recipient_restrictions端口 25 上只有客户端而没有对应的原因mua_recipient_restriction，因为 Postfix 永远不应该到达那个点。

但是，如果我使用邮件客户端通过 Postfix 邮件服务器将提交的邮件发送到我的另一个邮箱（外部托管），我会在邮件服务器上看到以下日志：

postfix/submission/smtpd[515502]: Anonymous TLS connection established from pd9ecf27b.dip0.t-ipconnect.de[217.236.242.123]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-sign>
policyd-spf[515508]: : prepend Received-SPF: Softfail (mailfrom) identity=mailfrom; client-ip=217.236.242.123; helo=my-touchpad.localnet; [email protected]; receiver=other-domain.tld

SPF 必然会失败，这是显而易见的。MUA 是拨号线路 (pd9ecf27b.dip0.t-ipconnect.de[217.236.242.123]) 上的客户端 (my-touchpad.localnet)，其未在 的 SPF 策略中列出my-domain.tld。当然，这并不是因为 SPF 策略只列出了邮件服务器本身。

然而，我想知道为什么 Postfix 首先要执行该检查。检查 SPF 只是其中的一部分smtpd_recipient_restrictions，不应应用于经过身份验证的 MUA。

如何在 Postfix 中禁用未送达通知（退回邮件）？

我已经使用 rspamd 3.6 设置了 Postfix 3.8.1。垃圾邮件过滤正在发挥作用

admin@host123456:~ $ wget http://spamassassin.apache.org/gtube/gtube.txt -P /tmp
admin@host123456:~ $ sendmail [email protected] < /tmp/gtube.txt

结果是

root@host123456:~ # egrep 4873D80B30 /var/log/mail.log
2023-10-28T21:41:00.297436+02:00 host123456 postfix/pickup[151929]: 4873D80B30: uid=1000 from=<admin>
2023-10-28T21:41:00.301825+02:00 host123456 postfix/cleanup[151958]: 4873D80B30: message-id=<[email protected]>
2023-10-28T21:41:00.352027+02:00 host123456 postfix/cleanup[151958]: 4873D80B30: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Gtube pattern; from=<[email protected]> to=<[email protected]>
2023-10-28T21:41:00.359127+02:00 host123456 postfix/cleanup[151958]: 4873D80B30: to=<[email protected]>, relay=none, delay=0.07, delays=0.07/0/0/0, dsn=5.7.1, status=bounced (Gtube pattern)
2023-10-28T21:41:00.365073+02:00 host123456 postfix/bounce[151960]: 4873D80B30: sender non-delivery notification: 58B2E81258

正如您从最后一个日志行中看到的那样，postfix 向原始发件人（在本例中为 admin@host123456）发回未送达通知。如何配置 Postfix 以简单地拒绝垃圾邮件？

Postfix > 2.10 按什么顺序评估以下指令？

1. smtpd_client_restrictions
2. smtpd_helo_restrictions
3. smtpd_relay_restrictions
4. smtpd_recipient_restrictions

我阅读了Postfix SMTP 中继和访问控制（ACCESS README）和Postfix 配置参数以及 中的注释main.cf，但恕我直言，这些建议并不绝对清晰，甚至是矛盾的。

mydestination注意：当我谈到“本地地址”时，我指的是 Postfix 是最终目的地的任何收件人地址，即其域部分在、virtual_alias_domains或中列出的地址virtual_mailbox_domains。其他都是非本地地址，Postfix 必须将邮件转发到另一个 MTA。

问题 1：是否始终按指定顺序针对任何类型的客户端（MUA 和其他 SMTP 服务器）和任何目标地址评估前两个指令？我想是这样。

问题 2： a) 始终评估还是smtpd_relay_restrictionsb) 仅针对非本地邮件域评估？

问题 3： a smtpd_recipient_restrictions) 始终评估还是 b) 仅评估本地地址？

文档中的一些引用

的文档smtpd_recipient_restrictions说明了 Postfix SMTP 服务器在 smtpd_relay_restrictions 之后在客户端 RCPT TO 命令上下文中应用的可选限制。这表明smtpd_relay_restrictions始终要对其进行评估，包括。本地地址。但该指令的名称暗示它仅考虑转发/中继的非本地地址。

smtpd_recipient_restrictions从 Postfix 2.10开始，文档说明，中继权限规则最好使用 来实现smtpd_relay_restrictions，这样，允许的垃圾邮件阻止策略smtpd_recipient_restrictions将不再导致允许的邮件中继策略。这表明，smtpd_recipient_restrictions仅考虑本地地址，但跳过非本地地址。

smtpd_relay_resrictions但是，默认值中有一条注释main.cf，指出最后没有放置默认操作（允许或拒绝），因为对于外部邮件服务器，此列表与 合并smtpd_recipient_restrictions，因此早期的reject操作会过早中止。这表明smtpd_recipient_restrictions始终会对其进行评估。

我有一台带有单个 Postfix 实例的机器，该实例托管不同的虚拟邮件域。

是否可以配置 Postfix，以便根据 SMTP 客户端用于连接到服务器的域使用不同的 TLS 服务器证书（具有不同的域名）？

我正在寻找类似于Apache基于SNI（服务器名称指示）的虚拟主机的功能。

我的（虚构的）DNS 配置如下所示

host12345678.my-hoster.tld.   IN  A           203.0.113.1
1.113.0.203.in-addr.arpa.     IN  PTR         host12345678.my-hoster.tld.

mail.my-1st-domain.tld.       IN  CNAME       host12345678.my-hoster.tld.
my-1st-domain.tld.            IN  MX     10   mail.my-1st-domain.tld.

mail.my-2nd-domain.tld.       IN  CNAME       host12345678.my-hoster.tld.
my-2nd-domain.tld.            IN  MX     10   mail.my-2nd-domain.tld.

我的（虚构的）Postfix 配置看起来像

myhostname              = host12345678.my-hoster.tld
mydomain                = host12345678.my-hoster.tld
myorigin                = $myhostname
mydestination           = $myhostname
virtual_mailbox_domains = my-1st-domain.tld my-2nd-domain.tld
virtual_mailbox_maps    = ldap:/etc/postfix/ldap-virtual-mailboxes.cf
virtual_transport       = lmtp:unix:/run/dovecot/dovecot-lmtp

如何向 Postfix 添加不同的 TLS 证书，以便根据客户端是否使用或来my-cert-chain-for-1st-domain.pem解析203.0.113.1？my-cert-chain-for-2n-domain.pemmail.my-1st-domain.tldmail.my-2nd-domain.tld

我正在使用 OpenLDAP 2.6。当我通过设置对象的密码时

ldappasswd -x -D <dn of root user> -W -S <dn of object whose pwd shall be set>

然后密码的一些哈希值最终出现在属性中userPassword。

使用什么哈希函数ldappasswd？如何配置哈希函数？从它的外观来看，我认为它默认为不再安全的 SHA1。