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
command.
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.
--
HLS