Re: IETF Policy on dogfood consumption or avoidance - SMTP version

[Hector Santos <[e-mail]>]

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