> -----Original Message----- > From: Phillip Hutchings > Sent: Wednesday, September 24, 2003 1:26 AM
[ Snip ] > > Which leads to the inevitable observation that there are no prizes for > > conformance to the RFC, but there are for getting the job done. The > > job of > > a mail transfer agent is to transfer mail. Not pass a conformance test > > based on a specific interpretation of an RFC... > > I would disagree on this. The MTAs job is to transfer mail based on the > set of standards in the RFCs. Not true. The MTA's job is to transfer mail. Period. The techniques used to transfer mail are defined by the MTAs. But it is simply erroneous to confuse the task with the protocols, and indeed the implementation of the protocols! > If these standards are open to > interpretation then there will be discrepancies between the MTAs. And that would be a problem... why? Oh, yes, because it would impair the ability to transfer mail. So your argument boils down to the notion that relaxing the requirements on MX record definitions to permit users to transfer mail is a problem because it would somehow allegedly impair the ability of the MTA to transfer mail... Logically, we call that reductio ad absurdum, and absurd is an appropriate word! If you look back at the history of the IETF, you'll find that in many cases the RFC simply codifies accepted practice, so the argument that accepted practice is wrong because a given RFC doesn't cover it is erroneous. I would draw your attention to this extract from RFC2555: [ About the culture behind the RFCs: ] "The RFCs themselves also represented a certain sense of fear. After several months of meetings, we felt obliged to write down our thoughts. We parceled out the work and wrote the initial batch of memos. In addition to participating in the technical design, I took on the administrative function of setting up a simple scheme for numbering and distributing the notes. Mindful that our group was informal, junior and unchartered, I wanted to emphasize these notes were the beginning of a dialog and not an assertion of control." > In this case Courier has chosen a stricter interpretation of the RFCs. And, in this case, the question becomes... why? Or at least, why not provide a means to relax that interpretation on a per-site basis? Remember, the RFCs don't *do* anything, so claiming conformance is a hollow claim, *unless* the actual _goals_ that RFCs set out to standardize are also met. In this case, the goal is transferring mail. And absent a good argument *why* the MX records *must* point to an A record (as opposed to SHOULD point to one), refusing to accept mail from clients that don't have an MX pointing to an A is simply capricious: surely it is the DNS system's area of responsibility to enforce DNS rules? [ By contrast, insisting on an MX that is ultimately resolvable to an A record is not capricious, since SMTP requires that... the issue is *how* the MX gets resolved, not whether it gets resolved ]. I've spent a lot of my professional life dealing with standards, and I can promise you that telling a prospective client that the reason your product doesn't interoperate is the other vendor's fault is usually greeted with a question as to the problem with conforming to the de facto, instead of de jure, standard... By the way, this attitude that "the requirement is X, we meet X, therefore any problems must be handled by the other guy is the old attitude of companies like IBM and DEC (who, I grant you, wrote the specs) and Microsoft. None of whom were or are noted for being models of interoperability! Malc. ------------------------------------------------------- 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
