> Ned Freed <ned.freed@xxxxxxxxxxx> wrote: > > > Ned Freed <ned.freed@xxxxxxxxxxx> wrote: > > > > > > > > Wrong group of codes. Those are status for mail systems to return, not > > > > > > the routing layer. > > > > > > > > > The point of null MX records it to explicitly say the address is invalid, > > > > > so an address status would seem to make sense. > > > > > > > > No, the point is to say that a host is invalid. > > > > > If you can't use them when the DNS says a mail domain is invalid then I > > > don't understand if it ever makes sense to use 5.1.2 or 5.1.8. > > > > You don't have a way of declaring a domain as invalid at the MTA level? > Yes, but it doesn't make much sense to me to draw an arbitrary line > somewhere on the spectrum between a configuration file, a configuration > table, a configuration database, or getting configuration from LDAP or > DNS, and say that one one side of the line it is an address-related > failure and on the other it is a routing or directory related failure. > In some MTAs, you find out whether an address is valid by trying to route > it. I quite simply disagree. To me it makes a hell of a lot of sense to draw a line between errors caused by stuff under the control of my administrative domain and stuff that isn't. This is especially true of the DNS, where an error right now may not occur later, and there's nothing logged locally to indicate the change. I don't even want to think about how many hours I've spent personally trying to sort out some obscure problem that was made obscure by it not being clear that the error condition originated from the DNS. > > And ask yourself this: Given that the null MX mechanism wasn't part of the > > picture when these codes were developed, and given null MX is the only (AFAIK) > > DNS-based mechanism with these semantics, why was the code even defined? > At least some MTAs in the mid 1990s would treat a mail domain as invalid > if its DNS was set up incorrectly, e.g. MX points to this machine but this > machine isn't configured to handle the domain, or MX does not exist in a > part of the DNS where the postmaster has forbidden fallback-to-A. Unless there's some indication that the existence of that practice was a factor in the design - and I'm pretty sure it wasn't - I fail to see the point. > > Absent a DNS-based mechanism, the best that could be done to address this > > problem was either to MX such hosts to an MTA which was configured to reject > > them, or run a stub SMTP server on the host itself that returns a 521 error as > > the banner a la RFC 1846. In either of those cases a 5.1.2 code would be > > appropriate. > Why not a 5.3.X (mail system status) code? Perhaps because none of those codes are appropriate? > The problem here is that someone writing a specification for a status code > can't choose which sub-code to use based on just RFC 3463 since the > categories overlap and their descriptions are too abstract to make it > clear how to resolve the overlaps. (Another example: why are message size > limits a "mail system status" not a "message content status"? You have to > read between the lines to conclude that X.6.X is exclusively for MIME.) > And you can't use your practical experience of MTA architecture since > implementations differ a lot and the codes are evidently not based on a > sufficiently universal model. I agree that the categories in general overlap and that some of the descriptions are unclear. But that doesn't mean they are unclear in this case, or that we should just throw up our hands and use whatever code we happen to feel like using. The real question is whether or not it makes sense to define a new code to identify this class of error. I think it makes all sorts of sense to do so, and I think that code belongs in the 4.x space. Ned