[Top] [All Lists]

Re: RFC2821bis-01 Issue 3: EHLO parameter

2007-03-31 03:40:55

Alex van den Bogaerdt wrote:
On Fri, Mar 30, 2007 at 06:50:07AM -0400, Hector Santos wrote:

With the MUST NOT/SHOULD NOT approach, it is discouraging future development.

I have trouble following this thread, and I could be wrong about my
interpretation of current 2821, so that's why I am asking this in
simple words:

I believe the current spec allows rejection, except for one clearly
defined case:

DNS_lookup(PTR,$incoming_ip_address) != $domain_name_parameter

In this particular case, section 4.1.4 says MUST NOT refuse.
Rejection based on other knowledge is (implicitly) allowed.

If a client uses my name, or my IP address, I know for sure that
this is not the client's property, so I can reject.  If protocols
such as SPF say the client is not authorized to use this domain
name, I can reject.  If the parameter is not a FQDN nor an address
literal, I can reject.

Is this correct, or not?

If it is correct: what is the proposed change?

Short answer:

   a) Change it to "MAY REJECT" based on current and new
      technical compliance requirements for the EHLO/HELO

   b) Remove it and rely on the implied document theory
      that protocol non-compliance across all commands
      is always acceptable *technical* reason for
      invalidating or rejecting a transaction.

Long answer:

Agreed, you are correct. Restating the current statement:

   An SMTP server MAY verify that the domain name argument in the EHLO
   command actually corresponds to the IP address of the client.
   However, if the verification fails the server MUST NOT refuse to
   accept a message on that basis.

You correctly presumed the implied DNS A/PTR/IP matching method as the exception. It is a relatively high overhead process and historically known to be problematic and unreliable method, DNS servers do go down, hence the historically strong recommendation to not reject on this basis.

However, that does not cover the actual usage and all possibilities.

A simple case in point is the IP literal matching. Arguably, to be considered an invalid "data" error, it can also be technically considered an non-DNS based IP mismatch error that is applicable to the first sentence above regarding domain input and the corresponding IP address of the client.

A second case in point is John's new condition of AAA/IPv6 DNS considerations, updating your rule.

Where will it end?

Thats why I suggested in my original postings to concentrate on the technical compliance requirements. I gave an example rough outline of what I believe are the contemporary technical compliance requirements for a possible EHLO/HELO verification implementation:

   - SHOULD:  Domain/IP syntax check
   - SHOULD:  Connecting IP domain Literal match check
   - MAY:   DNS A/PTR IP matching check

Frank added IPV6 to that list. He also suggested the latter two should be lump as one. I can see that point, but I don't agree since the literal match does not require a DNS lookup which in my view should be a "MAY" because of its overhead and unreliability potential. But I can go either either way.

Anyway, overall, I just think in this EHLO/HELO verification case, MUST/SHOULD NOT just doesn't fit the direction of current software and implementations. A growing amount of systems are simply not honoring this MUST NOT for many reasons, including using DNS based lookups. It takes away the option to do it even as the administration, configuration, operations and software has improved over the years and it can discourage new technology that might have a black box formula with DOMAIN and IP data points:

    VALID = EHLOHELO_HOOK(client_domain,client_ip)

The suggestion by Tony Finch to demote this to SHOULD NOT fits the modus operandi, which is better than nothing I suppose, but IMO I don't think it fits either.