--On Monday, December 21, 2009 14:18 -0800 SM <sm(_at_)resistor(_dot_)net>
wrote:
At 10:40 21-12-2009, The IESG wrote:
The IESG has received a request from an individual submitter
to consider the following document:
- 'The Eternal Non-Existence of SINK.ARPA (and other stories)
' <draft-jabley-sink-arpa-02.txt> as a BCP
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send
substantive comments to the
The other stories are in Section 3 of this draft. :-) Please
update the SMTP protocol reference to RFC 5321.
If I understood the story, it is to get compliant MTAs not to
attempt mail delivery to domains which do not wish to accept
mail. This does not really solve the implicit MX question but
that's another story.
Here's some text from Section 5.1 of RFC 5321:
"If MX records are present, but none of them are usable,
or the
implicit MX is unusable, this situation MUST be reported
as an error."
"When a domain name associated with an MX RR is looked up
and the
associated data field obtained, the data field of that
response MUST
contain a domain name. That domain name, when queried,
MUST return
at least one address record (e.g., A or AAAA RR) that
gives the IP
address of the SMTP server to which the message should be
directed."
As the intended status of this draft is BCP, it may have to
take into consideration the above text from RFC 5321 and see
how to resolve the issue.
Let me say this a little more strongly. This proposal
effectively modifies RFC 5321 for one particular domain name at
the same time that it effectively (see notes by others)
advocates against coding the relevant domain name into anything
or treating it in a special way. That combination doesn't seem
to me to work.
The issue that SM refers to as "implicit MX" has been hotly
debated in the email community and there was an explicit
decision (albeit with consensus that was fairly rough) to not
change things when RFC 5321 was approved. If implicit MXs were
prohibited, then this proposal would be unnecessary to
accomplish the desired purposes for email. If implicit MXs
continue to be permitted, this proposal, as I understand it,
would not work.
It seems to me to be a requirement that proposals that modify
existing standards be reviewed on the mailing list(s) associated
with those standards, preferably before going to IETF Last Call.
This proposal has not been reviewed on, or even exposed to,
those lists, at least with regard to email.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf