Malcolm Weir <[EMAIL PROTECTED]> wrote: > > > > If these standards are open to interpretation then there will be > > > > discrepancies between the MTAs. > > > > > > And that would be a problem... why? > > > > Where did you live during the past 7 years? Under a rock? > > Julian, > > Please try to show me some courtesy, and acknowledge that I > *explicitly* answered my rhetorical question in the next > paragraph, which you for some reason chose to ignore in your post. > > And the answer I provided was that it would problem *if* it > resulted in less stuff working.
So, in effect, you said that it was *not* a problem, which I dissent(ed). Aside from that, please excuse my rude tone, it wasn't meant so. The problem with accepting MX->IP despite the RFC forbidding it is that it leads to more persons expecting it to work, which in turn leads to more software having to be modified to support it. This effect can already be seen from Carlos' initial mail about the topic. Don't get me wrong: I don't really see a harm in accepting MX->IP *in general* (although there still might be one which I don't see). But almost every existing MTA has been written along the RFCs and most ones don't accept MX->IP as a result. So we first should try to reach wide concensus that MX->IP should be generally accepted in the future, and then amend the standards, so software developers have something they can comply with. I know that RFCs haven't always been handled this way in the past, but I think wide concensus should be reached before deliberately loosening standards, especially well-proven and time-tested ones. > No-one is suggesting (despite the slight innuendo) that RFCs be > ignored wholesale. The issue is whether the interoperability > of software should be REDUCED by adhering slavishly to a narrow > (and arguable) viewpoint, as opposed to increased by a more > tolerant viewpoint. This is not about *reducing* interoperability, but about *maintaining* interoperability the same until wide concensus has been reached that a suggested modification to the standard is really a good thing. > There are, obviously, problems when there are conflicting > viewpoints, but there aren't in this situation, and as far as I > can tell there can be no doubt as to what an MX pointing to a > CNAME actually *means*. > > Or do you disagree? Is there some possible meaning of an > MX/CNAME that is not "if the target of the MX is a CNAME, > interpret the CNAME until you get an A"? I'm not so sure about what exactly you are saying here. The above (and initial) problem is about MX->IP, which is clearly not allowed by the RFCs. MX->CNAME is not forbidden by the RFCs, but only discouraged for performance reasons. > The issue with HTML was not "loose interpretation of > standards", but conflicting interpretations. IMO, "conflicting interpretations" are a subset of "loose interpretations". Of course, both require the concerning standards document to be less than 100% explicit, which is the case more often than desirable. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
