Hello John. (I keep emailcore@ in as you did so, too.)
John C Klensin wrote in <84C724A9E37DC38FDA7F02AA@PSB>: |--On Monday, November 18, 2024 21:21 +0100 Steffen Nurpmeso |<stef...@sdaoden.eu> wrote: |>... |> It is unfortunate that SMTP, please let me add emailcore@, has |> several codes for disk full etc, but no possibility for a 5xx |> regarding failed authorization etc, so that people have to use |> "554" for *anything*. [^ Or 550, but that code i was reading used 554 for anything.] |>... |I believe this has been explained several times, but, in case the |explanations got lost in long messages that addressed several issues, |once more: | |The codes specified in RFC 5321 (and 5321bis) are imprecise even |though some are (or seem) more precise than others. That imprecision |is deliberate and goes back to RFC 821. It is one of the reasons why |RFC 3463 was developed and published over twenty years ago. | |I would encourage you to take a careful look at |https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhance\ |d-status-codes.xhtml#smtp-enhanced-status-codes-3 |and, in particular, the many codes and descriptions registered (so |far) as X.7.0 through X.7.30, a fairly significant fraction of which |are authorization failures. Some of these are even DKIM-specific. Thank you, these DKIM codes in particular i have not encountered yet, as RFC 7372 as such. Only one thing for my excuse, RFC 5321bis links several IANA assignments, but among which is not that status code link. It references RFC 3463 often, but RFC 3463 itself does not link to those assignments nor IANA at all. Pete Resnick already requested in private not to Cc: emailcore no more and that, correct in spirit, "if a new reply code would later be needed an additional RFC can be written, and be integrated in a later base spec update (like 7504)". |If you wanted to make a recommendation that systems supporting DKIM |or similar tools be required to provide those extended codes, I think |you would probably get considerable support. There are least two |problems with adding more base three-digit codes. One is that, |unless you brought all of the overhead of a new SMTP extension with |them, you'd never know whether the server supports the new codes or |not. The other is that, if you took the granularity of the current |extended code list as a starting point, there would be insufficient |space for an adequate set of new three digit codes. Ok .. i mean 5321bis links several times the word "typical" with one or multiple reply codes, so i would think that, .. even though i would have to read 5321bis from top to bottom as a whole in order to get (if i would) the real "notion" of the overall impression one gets when getting in contact with it, you know, i consume it more like a "patch pumpkin" for not few years, my one thus resembles a rag rug more than anything else. Eh... "Reply codes as of RFC 5321bis are more like catchalls." But even then, and that is why i Cc:d emailcore again, and especially and also in hindsight to what Lyndon (who i think uses the nmh MUA and is therefore, as an anglo-saxon, bitten by ML MIME reencodings, just to mention it) said and you agreed with, John: The theory of response codes is very simple: if the code starts with a '4', it's a temporary failure; if the code starts with a '5', it's a permamemt failure. That's all the logic an SMTP client needs to reliably do its job. Thus (sic) i think adding reply (thanks for changing all response to reply codes, and these "return codes" are in fact "codes to return") codes for failed authentication and authentification (or vice versa) would be nice even though STARTTLS/Implicit TLS and incarnations of AUTH remain external to the core of SMTP. So, for the very last time, i promise this (i already did to Pete Resnick in private and would have stood by it if you would not have written your message), i throw into the discussion that just like i now read for 554 "although 521 is now preferred for the latter" -- and RFC 7504 is from 2015 and thus also ~35 years into SMTP -- it would be nice, in my opinion, if the same would be done for authentification / authentication, because a *plethora* of reasons unfold behind that "or command rejected for policy reasons" of 550. Yes, there are extended status codes. --End of <84C724A9E37DC38FDA7F02AA@PSB> Thank you dear John, greetings from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |And in Fall, feel "The Dropbear Bard"s ball(s). | |The banded bear |without a care, |Banged on himself fore'er and e'er | |Farewell, dear collar bear _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
