> > > > In an IETF that believes the potential recursion of URNs and > > > > NAPTR records is reasonable, it is really hard for me to get > > > > excited about that one possible extra lookup. YMMD, of course. > > > > I can't get excited about this either. > > > > > Doug's issue, which sparked off this latest debate, would > > > be addressed by codifying "MX 0 .". This would allow hosts > > > to say that do not accept email and any email (MAIL FROM) > > > claiming to come from such a domain to be dropped in the > > > SMTP session. > > > > OTOH, I think standardizing this convention makes all sorts of sense, but > > not, of course, in 2821bis. > Why not in 2821bis? Mainly because this entire exercise is focused on a move to draft with this revision and a move to draft is not the time to introduce new features. > Is 2821bis really that time critical? It is somewhat time critical, but to be blunt I'm much more worried that if we delay long enough to get consensus on this change and force a recycle at proposed the necessary energy to move this document to draft won't be there when it is possible to do so. I'm also concerned that opening the door to new features and additions to this document will result in a slew of additional well intentioned proposals for changes and additions that will delay things even more. This entire effort to revise the core email protocol documents has only been been able to reach some sort of closure because we've managed to keep a pretty narrow focus on just cleaning ujp what's there in the base specifications. And even then it has taken a huge amount of work. I don't think you realize the potential for harm opening the door the way you propose can do. Ned _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf