On 12/19/2019 5:07 AM, Eliot Lear wrote:
That's hardly acceptable.
Alessandro, I respect your opinion, but *we* don’t get to decide that
for others. The person who gets to decide whether a PTR is required is
the MTA administrator and nobody else. I take the point about market
concentration, but that has to be balanced against other operational
considerations, and it will likely lose every time.
Eliot
Hi Eliot,
I think we need to take a step back and recognize the developer vs
administrative conflicts and the contention this particular ip-literal
issue is highlighting.
For nearly four decades, we asked implementators to follow IETF
guidelines and we did. Code is burned in and for SMTP, the ip literals
is an acceptable base component of the protocol. It is part of the
base SMTP engine and state machines, so even if all the guidelines are
followed 100%, what has occurred here, breaks the protocol, change
code.
The impact may be small, but nonetheless, there are violations of the
specs on both side.
So who takes responsibility, what are we asking of implementators?
Technically, the mail.ietf.org is RFC2821 correct in one respect. If
the Client has any public FQDN for the machine, then per spec it MUST
use one. Per spec, IFF there are no public FQDN, then it MUST use a
squared bracket IP-literal.
Thats that rule and I will 100% accept it because I can't argue it if
it was the reason for the mail.ietf.org rejection. My MTA did not use
an FQDN when in fact there is one.
But the SMTP specs also say, it MUST NOT reject on this basis and I
was part of the WG encouraging text that we now find in section 7.9
because we had new situations where a "MUST NOT reject" rule was not
appropriate for 100% detectable MTA problems using deterministic
protocols. We had greylisting, SPF, CBV and DKIM/ADSP coming and we
needed to arm administrators with some new negative reply codes to
explain and justify rejections. Please note that none of the new SMTP
add-on technology broke SMTP or changed it. It enhanced it. It was
backward compatible.
However, mail.ietf.org rejection on a perfectly defined per spec item
was not done because a valid FQDN was found to be available, hence
reject on that basis. No, it simply flat out rejected ip literal usage
all together despite correction. The odd thing of forcing FQDN is not
validating it.
In other word, the mail.ietf.org implementation is promoting
obsolescence and implementers who may use this server as a test site
and example of the "standards" to resolve ambiguous design issues, it
could begin to change things and I am not sure this is a desirable
situation. Or is it?
I don't think we are at evolutionary SMTP stage yet were eliminating
the IP-literal would be desirable.
From a DNS standpoint, we advocate no PTR records, but from a Mail
Admin AVS standpoint we do. But even SPF as deprecated the use of PTR
directives.
I ask for sound engineering consistency. That is all I even ask in
all my time participating the WG as an implementator. I don't say much
until I have too because now it steps on my toes.
Do I have to change my SMTP code to avoid using ip literals? Do I even
give operators the opportunity to set it up this way?
Thanks
--
HLS
