Re: [ietf-smtp] Return codes, was Updated draft for "SMTP Response for Detected Spam"

[Ned Freed <[e-mail]>]

> --On Thursday, March 31, 2022 10:45 -0700 Ned Freed
> <[e-mail]> 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