Re: Return codes, was Updated draft for "SMTP Response for Detected Spam"

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.

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.

				Ned

> It appears that John C Klensin  <[email protected]> said:
> >Let me add one thing to your suggestions.  While it does not
> >appear in the headers, the last sentence of Section 1 of the
> >current draft claims that this updates RFC 5321.  I suppose that
> >is necessary because it adds a reply code that is not in the
> >list that now appears in 5321, following the model of RFC 7504.

> This reminds me, why don't we have an IANA registry for SMTP return
> codes?  That would greatly simplify exercises like this.

> I suggested to Alex that his draft needs to define an extension to let
> client MTAs tell servers that they understand 259:

>  ehlo cruddy.mail.org
>  250-sceptical.server.com
>  250-STARTTLS
>  250-PIPELINING
>  250-ENHANCEDSTATUSCODES
>  250 MAYBESPAM

>  mail from:<[email protected]> MAYBESPAM
>  250 2.1.0 Sender accepted.

>  rcpt to:<[email protected]>
>  250 2.1.5 Recipient accepted.

>  data
>  354 Go ahead
>  -- blah blah blah --
>  .
>  259 2.6.8 That smelled pretty bad.


> In that case it doesn't update 5321, since it's not changing what SMTP
> clients and servers do in the absence of that extension, but it would
> be nice to have a registry so the codes don't accidentally overlap.

> With respect to 259 vs 559, Comcast is a pretty big mail system. If
> they think this could be useful, which they apparently do, I think it
> would be a fine idea to try the experiment (which does not need an RFC
> since we are still not the Network Police) and then later perhaps
> advance the proposal with experience of what it does. Experiments
> would be easier if it were possible to reserve the code points without
> a lot of overhead.

> R's,
> John

> _______________________________________________
> ietf-smtp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-smtp