ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP

2020-01-02 12:17:29


--On Thursday, 02 January, 2020 12:14 -0500 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:

On 1/2/20 9:56 AM, Hector Santos wrote:

If some local sites decide to reject IP-literals based on
decision  that contains bias so be it, they will deal with
the false positives,  but it is not SMTP.

I agree that it doesn't belong in the SMTP spec.  But the
cumulative effect of receiving sites' ad hoc and ill-informed
filtering policies is to degrade the utility of Internet email
for everyone.    It's not only a problem for the sites that
set the policies.

With regard to this and many other issues [1], I think there is
a higher-level answer if we know that "many" sites are doing
something other than what the spec recommends.  Whether we
change the spec to follow their practices or retain and clarify
the recommendation, it seems to me that we are going to need
text, somewhere, that explains our decisions, why we are giving
whatever advice we are providing, and why people should follow
that advice.  That text, which probably belongs in a separate
document from RFC531bis, may actually be more important than
whatever we put in 5321bis. Absent our providing a persuasive
explanation of why people should, or should not, do something,
experience, both on the anti-spam side and based on continuing
references to 2821, suggests that sites will do whatever they
(locally) think best and that some of those decisions will be
ill-informed.

The same principle applies, IMO, to suggestions that we pull
material out of 5321 that is considered obsolete, irrelevant, or
not belonging there. Some of the arguments about what should be
included ultimately date from the 1980s and involve questions of
whether the envelope-message body (with headers) separation
arrived at then was correct, whether we should have placed more
reliance on message processing rather than transport processing
or vice versa, and so on.  That even includes such questions as
whether RFC 974 was the right solution to that problem and
remains the right solution in a world in which the DNS is being
optimized for other things and we have strongly discouraged open
relays (something else 5321 says little or nothing about) and
whether, when we introduced EHLO, we should also have introduced
a three-layer envelope [2] and whether we should do that now via
a new but strongly-recommended extension.

In any event, I believe the discussion we need now is how we get
to a WG and how to sort out the details of Barry's suggested
approach for moving forward.  As just one example, as I read his
suggestion, I don't think it allows making major scope changes
in 5321bis, especially because, because of the way it is
constructed, different parts of that document are sufficiently
intertwined that simply adding or removing a substantive
sections or two may lead to inconsistencies that would require
very careful examination and revisions to sort out [3] [4].

back to lurking.
    john


[1] As I mentioned earlier in another context, I don't have time
to follow all of this traffic and my motivation goes down as it
becomes more repetitive.   I'm unlikely to try to make that time
before there is a WG and a consensus-determining mechanism
rather than people just stating their positions with great
passion and conviction.

[2] Somewhat like the X.400 P1/P2/P3 distinction but not
necessarily using that model.  I note that many of the rough
edges associated with the relationship between trace information
from xx21 and the header specifications of xx22 and many of the
issues with signatures over message headers would be at least
considerably simplified by pushing that type of information into
an intermediate layer or structure.

[3] The unresolved question of whether acceptance of IP address
literals is encouraged or mandated by 5321 because references
are not exact and apparently-different things are said in
different places is probably a good example of a situation we
don't want to accidentally make worse.

[4] Of course, 2821 and hence 5321 are paste-together jobs
rather than a complete rewrite and integration job because, at
the time the effort that produced 2821 was underway, we (for
some value of "we"( made an explicit decision that, given the
complexities and available energy and expertise, we'd be
unlikely to be able to take the other approach without
introducing errors that would talk a long time to find and sort
out.   Unless there is evidence that there is more energy now,
it is probably still the right decision.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>