1

I have a sendmail server configured to smarthost to a downstream resource. The configuration is currently: 

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

Since it's sending the A record for vip.example.local. I've been told that this is a violation of IETF RFC-5321 section 5.1 which states:

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].

Since mail servers support the option to smart host to an IP, I don't understand how smarthosting to an A record could be a violation.

Mike B
  • 11,871
  • 42
  • 107
  • 168
  • 1
    Me neither. Your server isn't delivering the email directly. It's passing it off to a smarthost for delivery. I'm fairly certain that the RFC isn't relevant at all to your server. Where are you hearing/reading that what you're doing violates the RFC? – joeqwerty Jul 28 '15 at 19:25

2 Answers2

7

This obviously applies to mail servers attempting to deliver mail to its destination. It's utterly irrelevant to situations where you are delivering all mail to a smarthost; the smarthost that you deliver to is responsible for following this, but you are not.

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • Thanks. I agree however I found this Microsoft article which gives me pause: http://blogs.technet.com/b/eopfieldnotes/archive/2014/06/18/outbound-connector-smart-host-behavior.aspx Specifically, there's a section at the bottom: "How does the lookup for the FQDN smart host work?". Admittedly it's a different product/platform but the principle seems similar... – Mike B Jul 29 '15 at 19:32
  • @MikeB That's describing a completely different (though _possibly_ related) scenario, and what MS is doing there is probably wrong. In any case no RFC specifies the behavior in these scenarios anyway. – Michael Hampton Jul 29 '15 at 19:47
  • Actually I'm pretty sure that how MS is abusing MX records there is a horrible idea, as it provides a publicly advertised point for delivering mail that _bypasses_ their filters! – Michael Hampton Jul 29 '15 at 19:50
0

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

So even if its a smart host delivery, you should not use a .local for helo. .local (.lan) are reserved names for Apple's mDNS. (zeroconf)

In you case, you helo is not correct and should always be a resolvable hostname.

If an MX lookup is done based on .local wel that errors.. since it cannot find your hostname on the recieving server.

And depencing on the mail server setting where your relaying over, its allowed. This depends on the provider used.

The client name, should also be resolable, but since lots of people misconfigure there dns and forget the PTR, not many block on "unknown" hostnames.

in you case, your server wil never be able to send email to my servers. These al check on DNS correctness and a resolvable helo hostname.

And more servers are doing this, why, this setting save my for about 80% of spam. So correct your helo hostname or dont run a mail server.

thctlo
  • 1