--On Friday, December 27, 2019 16:08 -0500 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:
On Dec 27, 2019, at 1:42 PM, John C Klensin <john(_at_)jck(_dot_)com>
wrote:
It seems that the -02 has not yet been uploaded, did you mean
for it to be already available?
Sorry... meant -01. Been thinking about and working on -02
too much. It should be up in the next couple of hours.
Thanks, I see it now. Thanks for including the "552 -> 442"
issue, much appreciated.
I'd also like to see a similar placeholder for clarifying the
semantics of a "554" greeting. Is the client expected to
immediately bounce the message, or look for a better MX host?
The spec is not clear and implementations vary.
The text says (Section 4.2.4.2)
"... including 554 and the temporary 450, are used for
more transient situations and situations in which an
SMTP server cannot or will not deliver to (or accept
mail for) a particular system or mailbox for policy
reasons rather than ones directly related to SMTP
processing."
I'd construe "more transient situations" especially if the code
is used instead of 220 when the client attempts to open a
connection, as implying that working down the MX chain is
entirely appropriate. But YMMD here. A different statement of
the problem is that better statements needed about when a server
should reply to a connection opening attempt with a 521 code and
when it should use 554 (or 556). Section 4.2.4.2 is probably
where that should go, but my notes indicate it is new to 5321bis
and was introduced after discussions associated with RFC 7504.
So it should be considered a preliminary proposal, open for
suggestions about rewriting or there modifications once we
actually start working on the document (as distinct from getting
a foundation and issues list in place for doing that).
Past behaviour by some MTAs (returning a 554 banner under
load) made the second choice more appropriate, but I've not
seen recent reports of whether that's ongoing.
Probably worth reviewing RFC 1846 to see what it says about
these issues. I have not done that yet and it isn't at the top
of my queue.
More recently some users are running into policy-based 554
greeting rejects, and don't want to keep retrying message that
will be consistently rejected.
Well, if the policy is that the server isn't accepting mail from
anyone, ever, as a matter of policy, then it probably ought to
be returning a 521 in response to the connection attempt and be
done with it. If the policy reason is "we like some would-be
senders but not you and you should either go to hell or find
some out-of-band way to appeal our decision", then maybe neither
code is right and we should be thinking about a new code.
As has been pointed out about some other issues, anything we
change (or even clarify) here is going to have a long
implementation tail, so clients had best be prepared to use the
"first digit" rule and/or to aggressively apply the robustness
principle.
I'd like to know which is the expected client behaviour, and
which is a work-around for particular unexpected circumstances
a client may encounter.
See above, with the understanding that is not intended to be an
answer but the beginning of a discussion when we are ready to
have such discussions. I've provided additional text in what
will become rfc5321bis-03, but don't hold your breath waiting
for it to appear: unless important new issues turn up or I get
instructions to the contrary from the ADs, -03 is likely to be
delayed until after we have a WG charter in place or at least
under active consideration.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp