Thank you Gerardo for your reply. I have some additional information regarding WHY the MX RRs are broken. The mailserver admin does not intend to keep these broken. I also have a comment about how RFC1035 is implemented in Courier.
Regarding RFC1035 in Courier; I looked through the most recent source code for Courier-mta and have discovered that my revision contains the same code that exists today. I have lightly reviewed the code in the file courier/courier/rfc1035/rfc1035mxlist.c. It seems to me that what is happening is only the first three MX entries are used. Please correct me on this! In my case, the first two MX entries were intentionally broken, but the THIRD was an rfc1035 violation! The third entry contained an IP address. There were three additional lower priority entries also for the domain, all adding up to a total of six MX entries. Is it possible that courier is ignoring the fourth, fifth, and sixth entries? > >It was explained to me that the other guy's ISP (otherguysisp.com) has > >the broken domain's entries purposely broken for the first few MX records > >(brokendomain.com). He says that his ISP wants to keep the first few MX > >records broken, and that the problem is with MY mailserver. > > If he broke the mx entries on purpose then ask him where in the RFC it > states that type of methadology, or what "best business" practice is he > following here. He does not seem to be concerned about following the full intent of the RFCs, but is still concerned about being 'standards-based'. Please read the following fromt he guy: "The intention of this was to hide the domain's real SMTP servers from the internet (we have been seeing spammers pick MX records at random, rather than just the highest preference, for the past year and a half). brokendomain.com did not choose to make use of this feature, so their real SMTP server is listed, after the anti-spam boxes. We also preferred using the MX's for choosing final delivery because it was standards-based, and wouldn't require us to do any sort of nasty munging in Sendmail." > > Keep the first few MX records broken? If they want to break these then > tell him to keep them internal, and tell them to run a sandbox DNS > solution. If he wants to play the game of interconnectivity then he > needs to play along with everyone else, and the standards (and > suggestions) provided in the RFC's. You are right about the sandbox approach. It seems that he's trying to a sandbox approach, but is still exposing the first few MXs. Read his explanation: "They need to have their mail routed through an anti-spam system before it gets to their SMTP servers. By having the 1st 2 records unresolvable, mail from the internet is delivered to MX 30, the anti-spam boxes. The anti-spam boxes *are* able to resolve the *.mx.otherguysisp.com records (MX 10 and 20), and MX 10 just points to brokendomain.com's primary SMTP server." I'll recommend that he read the 'sandbox' section of the RFC > > I have ran into admins in the past who have done the same thing. Blame > the software I am running because they dont follow the RFC. One big > example is IP addresses in the MX record, and then they defend their > stance by stating to me "Well I can get mail from everyone else". As it > happens everyone else is "Hotmail" or "Yahoo Mail", it is a sad thing > that some admins use such services as the "measuring" stick for > interconnections. You are right about this, however it is possible that Courier isn't checking more than three MX RRs, which isn't a violation of RFC, but isn't complete compliance either. His nameserver entries may be messed up, but courier should be able to look at the fourth, fifth, etc. MX entries. > > It is hard sometimes to make idiots that think like this to even see > reason. Where I work I am not even the Systems Administrator, it just > happens that I have taken some system responsabilities (email being one) > because of the staffing issues presented in my department. > He's actually being very cooperative. He made some changes to the domain until we get these issues further resolved: "This is probably left over from the last time they renumbered. Put in place temporarily and meant to be fixed when things had stabilized. You know how that goes :) I can get this fixed, but I'd like to see if the change I made yesterday fixes it first. That will tell us which issue it was." > > Esperience has taught me to take these issues to the individuals > supervisor's, or superiors and reference the RFC to them, explaining > where they are not being "net frinedly" and also what solutions they can > do in turn [sadly enough you have to think for them also]. > > I still see no reasoning as to what they are gaining by breaking an MX > record. Escept that the guy misconfigured something and now wants to > act that it was done like that for some meaningless purpose as to not > admit that he had no idea what he was doing. Although he seems fairly familiar with > > Good Luck getting those MX records fixed! More than likely they will > just ignore reasoning and if it is crucial for your organization to > receive email from their hosted domain(s), then you might have to do > extra work and host internal zones of their domains for your systems to > resolve them properly. > > Gerardo A. Gregory > Manager Network Administration and Security > "King of mispellings, and run on sentences" > ------------------------------------------- > Affinitas, Corp. > One customer|One relationship|One source. > Visit us at http://www.affinitas.net > > > Kirk A Wolff wrote: > > > First off: Courier-mta is the BEST! > > > > Question: Does courier iterate through all available MX records even if > > the first few are broken and possibly violate RFC1035? > > > > I have been getting a complaint from someone trying to send an email to > > me. She gets an error from her mailserver thus: > > > > -------------------------------------------------------------- > > > > >>> Mail Delivery Subsystem < > > [EMAIL PROTECTED] > 1/6/2004 3:43:24 PM > > The original message was received at Tue, 6 Jan 2004 15:43:14 -0600 > > (CST) > > from 12-23-34-45.otherguysisp.com [12.23.34.45] (may be forged) > > ----- The following addresses had permanent fatal errors ----- > > < [EMAIL PROTECTED] > > > (reason: 517-MX records for brokendomain.com violate section 3.3.9 of RFC > > 1035.) > > ----- Transcript of session follows ----- > > ... while talking to mail.! mydomain.net.: > > MAIL From:< [EMAIL PROTECTED] > SIZE=1911517-MX records for > > brokendomain.com violate section 3.3.9 of RFC 1035. > > <<< 517 Invalid domain, see <URL: ftp://ftp.isi.edu/in-notes/rfc1035.txt > > > 554 5.0.0 Service unavailable > > > > --------------------------------------------------------------- > > > > It was explained to me that the other guy's ISP (otherguysisp.com) has the > > broken domain's entries purposely broken for the first few MX records > > (brokendomain.com). He says that his ISP wants to keep the first few MX > > records broken, and that the problem is with MY mailserver. > > > > I am running Courier-mta 0.43.2 and it was compiled on my redhat 8.0 box > > with the ldap auth module loaded and running. > > > > - Kirk > > ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
