On Jun 15, 2012, at 6:44 AM, Charlie Brady wrote: > On Wed, 13 Jun 2012, Matt Simerson wrote: > >> https://github.com/smtpd/qpsmtpd/pull/29 > > I consider this statement to be troublesome also: > > Per RFC 2821, the HELO hostname must be the FQDN of the sending server or > address literal.
-Per RFC 2821, the HELO hostname must be the FQDN of the sending server or an +Per RFC 2821, the HELO hostname is the FQDN of the sending server or an s/must be/is/ > RFC 2821 doesn't say "must". It says neither should nor must, but simply > > The argument field contains the fully-qualified domain name of the SMTP > client if one is available. In that very same paragraph, and the preceding one, the RFC spells out the purpose of the HELO hostname, which is to identify the sending system. I believe that's why the RFC writers chose to use the definite article when defining the FQDN, rather than saying "a FQDN," or "any FQDN," or "anything that suits your fancy." The purpose is explicit, to identify the sending system. > Mail servers can certainly be expected to have a FQDN. But expecting them > to have *only one* FQDN may be too tight a constraint. Where did I say I expect the smtp client to have *only one* FQDN? You are arguing with the RFC, not me. :-) In principle, I mostly agree with you. Limiting a SMTP client to a single FQDN would be too strict. Which is why I don't do it. Not even when 'policy strict' is set. Read the POD or the code, and you'll see that my optional, off by default, DNS tests do not limit the HELO hostname to 'the' FQDN, but to any A or AAAA record that matches the hostname, and any PTR that matches the IP. The match test is only enabled with 'policy strict.' Although I believe the RFC allows it, the 'policy rfc' setting does not impose matching DNS. It simply requires that the HELO hostname and IP address both resolves to something. Anything. > Is there a definition of canonical FQDN? RFC 1035. Legal characters. Length limits. The whole enchilada. > Is the canonical FQDN anything > other than just the name defined by whoever manages reverse DNS? That's not a FQDN, that's a matching PTR record, aka reverse DNS. However, a FQDN normally does, but is not required to have a matching PTR record. Think of cases like apache virtual hosting, where a thousand FQDNs share a single IP and do not, and should not, have matching PTR records. > In my experience, reverse DNS is frequently managed (or, frequently, not > managed) by an ISP, not by the admin of the mail server. In my experience, every ISP that provides clients with dedicated IPs also provides the client with the ability to manage the reverse DNS for them. Either via a support request or automated means. I did when I owned my ISP in the early 90s, and every ISP and hosting provider I've ever worked for or with since does as well. The good providers even provide rwhois on the delegated IP space and automatically populate it with the clients billing data. (see RFC 1941). Matt
