--On Thursday, March 31, 2022 10:45 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
In our world at least, use of previously undefined status
requires an extension. This is because a certain library for a
certain language whose name begins with "J" throws an
exception when it sees a status code it doesn't recognize.
Hmm. Should I assume that it has been pointed out to the
authors of said library that they are in violation of a rather
specific provision of RFC 5321 and that they are not listening?
It's been pointed out. It may even have been fixed. But then there's
the issue of release and deploying. Getting this sort of thing out
of the field takes a long time.
Of course you can modify the app to catch and ignore the
exception, but customrs are curiously reluctant to do that.
Maybe this implies that a
ACCEPTANYSYNTACTICALLYVALIDSTATUSCODE extension would be
useful. Or not.
Not really an extension because of the paragraph of Section 4.2
of RFC 5321 that starts
"An SMTP client MUST determine its actions only by the
reply code,..."
if that paragraph is not sufficiently clear that clients are not
allowed to throw exceptions (or otherwise have fits) when they
receive a reply code of three digits starting with 2, 3, 4, or
5, this would be a good time to suggest improvements.
And, for this particular case, perhaps an
IAMINTERESTEDINWHATTHEMDATHINKSOFTHISMESSAGE extension, which
would generalize from MAYBESPAM and include "maybe highly
focused phishing attack" and other possible conclusions from
analysis on the delivery system, would be useful. Or not.
Yep. All sorts of elaborations are possible.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp