ietf
[Top] [All Lists]

Re: summary for Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A Null MX Resource Record for Domains that Accept No Mail) to Proposed Standard

2014-07-19 08:10:07
Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> 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.

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.

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?

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.

Tony.
-- 
f.anthony.n.finch  <dot(_at_)dotat(_dot_)at>  http://dotat.at/
Southwest Forties, Cromarty, Forth: Easterly 4 or 5, increasing 6 or 7 for a
time, veering southerly or southwesterly later. Slight or moderate,
occasionally rough later in Cromarty. Thundery showers, fog patches later.
Moderate or poor, occasionally very poor later.

<Prev in Thread] Current Thread [Next in Thread>