Steffen, Unless I'm misreading something, this discussion is now 100% unrelated to rechartering. Please see my other note and put this topic off until we've completed that process.
-MSK, ART AD On Wed, Nov 20, 2024 at 1:44 PM Steffen Nurpmeso <[email protected]> wrote: > 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 > |<[email protected]> 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 > > -- > Emailcore mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
