A hospedagem inteligente de um registro A viola a seção 1 da RFC-5321?

Question

Eu tenho um servidor sendmail configurado para smarthost para um recurso de recebimento de dados. A configuração está atualmente:

define('SMART_HOST','relay:[vip.example.local]')dnl

Como ele está enviando o registro A para vip.example.local . Eu tenho dito que isso é uma violação do IETF RFC-5321 seção 5.1, que afirma:

Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in Sections 2.3.5 and 3.6), a DNS lookup MUST be performed to resolve the domain name (RFC 1035
[2]). The names are expected to be fully-qualified domain names
(FQDNs): mechanisms for inferring FQDNs from partial names or local
aliases are outside of this specification. Due to a history of
problems, SMTP servers used for initial submission of messages SHOULD NOT make such inferences (Message Submission Servers [18] have
somewhat more flexibility) and intermediate (relay) SMTP servers MUST NOT make them.

The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name. If a non-existent domain error is returned, this situation MUST be reported as an error. If a temporary error is returned, the message MUST be queued and retried later (see Section 4.5.4.1). If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. If MX records are present, but none of them are usable, or the implicit MX is unusable, this situation MUST be reported as an error.

If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any address RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only
if there are no MX records present. If MX records are present, but
none of them are usable, this situation MUST be reported as an error.

When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST
contain a domain name. That domain name, when queried, MUST return
at least one address record (e.g., A or AAAA RR) that gives the IP
address of the SMTP server to which the message should be directed.
Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard.
The prohibition on labels in the data that resolve to CNAMEs is
discussed in more detail in RFC 2181, Section 10.3 [38].

Como os servidores de e-mail oferecem suporte à opção de host inteligente para um IP, não entendo como a inteligência inteligente para um registro A pode ser uma violação.

    

Answer 1

Isso obviamente se aplica a servidores de correio que tentam entregar mensagens ao seu destino. É totalmente irrelevante para situações em que você está entregando todos os e-mails para um smarthost; o smarthost que você entrega é responsável por seguir isso, mas você não é.

    

Answer 2

Me neither. Your server isn't delivering the email directly. It's passing it >> off to a smarthost for delivery

Portanto, mesmo que seja uma entrega de host inteligente, você não deve usar um .local para o helo. .local (.lan) são nomes reservados para o mDNS da Apple. (zeroconf)

No seu caso, o helo não está correto e deve ser sempre um nome de host resolvível.

Se uma pesquisa de MX é feita com base em .local, bem que erros .. desde que ele não pode encontrar o seu nome de host no servidor de recebimento.

E depende da configuração do servidor de e-mail em que sua retransmissão é permitida. Isso depende do provedor usado.

O nome do cliente, também deve ser resolúvel, mas como muitas pessoas desconfiguram o dns e esquecem o PTR, não há muitos bloqueios em hostnames "desconhecidos".

no seu caso, o seu servidor nunca poderá enviar e-mails para meus servidores. Eles também verificam a exatidão do DNS e um nome de host helo solucionável.

E mais servidores estão fazendo isso, por que, essa configuração salva o meu por cerca de 80% do spam. Então, corrija o seu helo hostname ou não execute um servidor de email.