Correction the message should have been:
http://www.ietf.org/mail-archive/web/ietf/current/msg59761.html
Olafur
At 00:18 22/12/2009, Olafur Gudmundsson wrote:
John, SM
do the changes that Ted Hardie asked for address your concern(s)?
see:
http://www.ietf.org/mail-archive/web/ietf/current/msg59759.html
All we want sink-arpa to do is to create a domain name with known
characteristics and create a mechanism to define other such domain
names that may have other characteristics for various applications.
Olafur
At 23:57 21/12/2009, John C Klensin wrote:
--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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf