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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Friday, July 18, 2014 01:01 +0000 Viktor Dukhovni
<ietf-dane@xxxxxxxxxxxx> wrote:

>> (d) It seems to me that the cases this proposal addresses are
>> special enough that a dedicated Extended Status Code would be
>> in order.  Instead, the document specifies the highly generic
>> 5.1.2 (even those the RFC 3463 definition of X.1.2 includes
>> "incapable of accepting mail" and "invalid for mail" (which
>> don't mean quite the same thing).   Especially since there is
>> not an easily-located WG discussion, the document should at
>> least explain its choice.
> 
> This is likely already practiced, and is clear enough in
> practice. Keep in mind that there are no legitimate senders of
> mail blocked by nullmx rejection, so the DSN status codes are
> of little interest to anyone but the bad guys.

In an odd way, your comment above illustrates the reason I think
an extended status code would be useful and why I'm concerned
that this draft might not have received adequately broad review.
If the use of nullmx were confined to parted domains, I would
agree with you and not see a problem.  But the document doesn't
say that -- from reading it, one could get the impression that
it is being recommended for the domain associated with any
system that doesn't expect to receive mail.  That leads into
some of the other cases, including the large mail operator whose
sending and receiving hosts are separate, as discussed earlier
and, e.g., some interesting questions about what happens if,
despite what it says in the document, multiple MX records are
configured only one of which has "." as the data.   In some of
those cases, the cause of rejection might be an operational
configuration error, not an error on the part of the sender.
For such cases (including the examp1e.com one) details status
codes could be a big advantage.

> The primary use for nullmx is parked domains.  At previous
> employer we configured thousands of parked domains with nullmx
> RRs.

I'm not recommending this but, if the documents said "this is
for parked domains, for any other cases, the structure is
outdated and SHOUDL NOT be used except under special
circumstances and with adequate explanation.

     john





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]