--On Saturday, December 14, 2019 17:27 -0500 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:
In practice some aspects of some RFCs have proved unworkable,
or the situation on the ground has changed over time, and
actual systems deviate from the RFCs to achieve the
interoperability they need "in practice".
Sure.
I don't believe that deviating in some small details from
an 11-year old document (that on the whole has aged quite
well), which in turn is a conservative revision of an
18-year old document, ... amounts to disrespect of the
document as a whole. Things change...
Yes... and no.
If you decide to commit those deviations in your server, I
wouldn't be inclined to say a word, instead attributing it a
local operational decision and/or an invocation and extension of
the principle that a mail server may refuse to handle any
message for any reason, both of which are called out in the
spec. However, two distinctions are, I think, worth making
(without quibbling about the response code or error message
text):
(1) Relative what the spec says, you would be on much more firm
ground rejecting
MAIL FROM:<evil@maleware-are-us.example>
then
EHLO [127.0.0.5] or
EHLO maleware-are-us.example
In the first instance, you'd be rejecting the message on the
basis of its sender, which 5321 very explicitly allows. In the
second pair, you'd be rejecting any message from a point of
origin, perhaps on the basis of a domain name that does not
identify a host or an IP address that doesn't point anywhere
useful. What 5321 says about those things is that you can
check, you can use what you find in logging or reporting, but
you MUST NOT reject on that basis.
(2) We are talking about the ietf.org servers here. I think
that the IETF, quietly and without public explanation or
evidence of community consensus, ignoring the requirements of
its own specifications is bad news. That a specification is
eleven years old does not seem to me to be relevant and no more
appropriate than it would be to argue that some provisions of
RFC 791 that have not bee updated or replaced by later specs
should now be ignored because it is 38 years old. On our own
systems, we should follow our own specs until we are ready to
change them and have community consensus for doing so.
For us, the proper remedy if a provision of a standard has
become unworkable is an I-D that changes that provision and
gets IETF consensus for doing so.
I'm sure you know that doing that often requires a great deal
of effort that may not be commensurate with the reward.
Well, I think I know two things about that. One is that
proposals that are tightly focused and that have clear consensus
usually go through the system rather quickly. The second is
that, when the first is not the case, something is badly broken
to the point that there should be appeals, explanations to the
Nomcom, and/or efforts to fix the recall procedures so that they
are usable.
In general, if there is consensus around there being a problem
with a spec, an I-D specifying a change does not go through
quickly, and none of those actions are taken, it is probabl7 an
indication that no one really cares.
I haven't seen an I-D containing that proposal yet whether
from you, from the members of the IETF leadership who decided
that address literals be rejected, or from anyone else.
Well, you're working on 5321bis, would you be willing to add
text that states that use of address literals by relays is
now strongly discouraged, because they are not infrequently
rejected by the receiving SMTP server?
I would support such text, it represents operational reality.
It could go in "operational considerations".
Short answer, as editor, no, in part because 5321 already
discourages the use of address literals unless they are
necessary and because the discussion so far does not lead me to
conclude that there is strong consensus for making a change.
Note in particular that prohibiting the us of IP literals (which
you did not suggest) would be equivalent to requiring that all
SMTP clients and servers have domain names, a requirement that
821 -> 2821 -> 5321 rather carefully avoid.
More on my general editing rules/ assumptions and policies in a
separate note, forthcoming.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp