no arquivo /etc/postfix/main.cf você pode colocar esta diretiva:
smtp_tls_secure_cert_match = hostname, nexthop, dot-nexthop
colocar isso no main.cf permitirá que uma correspondência de nome de host dos registros MX do DNS seja permitida para o nível de política seguro. Tudo o que isso em essência faz é converter o nível de política segura em nível de política de verificação, portanto, você pode simplesmente alterar o nível de política de tls para verificar ou diminuir. Para responder à sua pergunta sobre o que está causando falha no seu destinatário original,
[email protected]
quando você define sua política de tls para proteger a variável de controle é
smtp_tls_secure_cert_match (default: nexthop, dot-nexthop)
e nexthop, a menos que tenha uma sobreposição em uma tabela de transporte, é determinado conforme discutido na página 5 postconf man postada abaixo.
the next-hop domain, which is either the recipient domain, or the transport next-hop configured for the domain
seu próximo salto na política segura com esse endereço de e-mail é fastmail.fm enquanto o único domínio que está no registro MX é o messagingengine.com , nunca corresponderá à política de segurança. No entanto, olhando para o registro MX de fastmail.fm.
[[email protected] openssl]# host -t MX fastmail.fm
fastmail.fm mail is handled by 10 in1-smtp.messagingengine.com.
fastmail.fm mail is handled by 20 in2-smtp.messagingengine.com.
se você relaxasse a diretiva de correspondência de certificado seguro para incluir o nome do host ( novamente exatamente a mesma coisa que smtp_tls_security_level = verify ), o certificado verificaria com base no registro MX que aponta para in1 -smtp.messagingengine.com que corresponde ao CommonName * .messagingengine.com . Isso também acontece com [email protected] , e tenho certeza que muitos outros, so como eles dizem no man 5 pagina para postconf
smtp_tls_security_level (default: empty)
verify Mandatory TLS verification. At this security level, DNS MX lookups are trusted to be secure enough, and the name verified in the server certificate is usually
obtained indirectly via unauthenticated DNS MX lookups. The smtp_tls_verify_cert_match parameter controls how the server name is verified. In practice
explicit control over matching is more common at the "secure" level, described below. This security level is not an appropriate default for systems delivering
mail to the Internet.
secure Secure-channel TLS. At this security level, DNS MX lookups, though potentially used to determine the candidate next-hop gateway IP addresses, are not trusted
to be secure enough for TLS peername verification. Instead, the default name verified in the server certificate is obtained from the next-hop domain as speci‐
fied in the smtp_tls_secure_cert_match configuration parameter. The default matching rule is that a server certificate matches when its name is equal to or is
a sub-domain of the nexthop domain. This security level is not an appropriate default for systems delivering mail to the Internet.
This security level is not an appropriate default for systems delivering mail to the Internet.
em seguida, novamente, diz que também para a política de tls verificar também, mas é por isso que sempre falhará.
para referência a página postconf man5 para as duas diretivas mencionadas acima:
smtp_tls_secure_cert_match (default: nexthop, dot-nexthop)
How the Postfix SMTP client verifies the server certificate peername for the "secure" TLS security level. In a "secure" TLS policy table ($smtp_tls_policy_maps)
entry the optional "match" attribute overrides this main.cf setting.
This parameter specifies one or more patterns or strategies separated by commas, whitespace or colons. In the policy table the only valid separator is the colon
character.
For a description of the pattern and strategy syntax see the smtp_tls_verify_cert_match parameter. The "hostname" strategy should be avoided in this context, as in
the absence of a secure global DNS, using the results of MX lookups in certificate verification is not immune to active (man-in-the-middle) attacks on DNS.
Sample main.cf setting:
smtp_tls_secure_cert_match = nexthop
Sample policy table override:
example.net secure match=example.com:.example.com
.example.net secure match=example.com:.example.com
This feature is available in Postfix 2.3 and later.
também faz referência a smtp_tls_verify_cert_match para entender melhor
smtp_tls_verify_cert_match (default: hostname)
How the Postfix SMTP client verifies the server certificate peername for the "verify" TLS security level. In a "verify" TLS policy table ($smtp_tls_policy_maps)
entry the optional "match" attribute overrides this main.cf setting.
This parameter specifies one or more patterns or strategies separated by commas, whitespace or colons. In the policy table the only valid separator is the colon
character.
Patterns specify domain names, or domain name suffixes:
example.com
Match the example.com domain, i.e. one of the names the server certificate must be example.com, upper and lower case distinctions are ignored.
.example.com
Match subdomains of the example.com domain, i.e. match a name in the server certificate that consists of a non-zero number of labels followed by a .exam‐
ple.com suffix. Case distinctions are ignored.
Strategies specify a transformation from the next-hop domain to the expected name in the server certificate:
nexthop
Match against the next-hop domain, which is either the recipient domain, or the transport next-hop configured for the domain stripped of any optional socket
type prefix, enclosing square brackets and trailing port. When MX lookups are not suppressed, this is the original nexthop domain prior to the MX lookup, not
the result of the MX lookup. For LMTP delivery via UNIX-domain sockets, the verified next-hop name is $myhostname. This strategy is suitable for use with the
"secure" policy. Case is ignored.
dot-nexthop
As above, but match server certificate names that are subdomains of the next-hop domain. Case is ignored.
hostname
Match against the hostname of the server, often obtained via an unauthenticated DNS MX lookup. For LMTP delivery via UNIX-domain sockets, the verified name is
$myhostname. This matches the verification strategy of the "MUST" keyword in the obsolete smtp_tls_per_site table, and is suitable for use with the "verify"
security level. When the next-hop name is enclosed in square brackets to suppress MX lookups, the "hostname" strategy is the same as the "nexthop" strategy.
Case is ignored.
Sample main.cf setting:
smtp_tls_verify_cert_match = hostname, nexthop, dot-nexthop
Sample policy table override:
example.com verify match=hostname:nexthop
.example.com verify match=example.com:.example.com:hostname