Because all I have read is sounding more and more like a crock of ____ (ADLIB)
Especially when it was stated that these where broken for security sakes. Yeah right! The KRAFT security architecture [RFC 10101010101] - swiss cheese style!!!
Maybe that admin can give a presentation at a SANS conference and explain his ideology of securing your SMTP server by "breaking" [whatever breaking means] MX records...'us' in the security field are anxious to deploy this method as quickly as possible since then we wont have to "fidget with sendmail" as was stated in his earlier post [laziness if you ask me].
Furthermore read the subject...it says first TWO mx entries are bad, then read the threads posted all day, where the story becomes only one bad MX entry and two legit for spam boxes...
The information provided changes over and over...
I referred the RFC in case you feel the need to change the definition of a legit MX record in RFC 1035 (or STD 0013). RFC [2926] tells you how to submit your request, so they can revise the standard and define a broken MX for all of us who only know one type of MX record...Now where is a broken MX stated in the definition below? THERE IS ONLY ONE TYPE OF MX RECORD, ANYTHING ELSE IF PLACED INSIDE THE RECORD FIELD IS INCORRECT. NOW WHAT IS SO HARD TO UNDERSTAND ABOUT THAT!!!!!!!!!!!!!!
3.3.9. MX RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGE /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PREFERENCE A 16 bit integer which specifies the preference given to
this RR among others at the same owner. Lower values
are preferred.
EXCHANGE A <domain-name> which specifies a host willing to act as
a mail exchange for the owner name.
MX records cause type A additional section processing for the host
specified by EXCHANGE. The use of MX RRs is explained in detail in
[RFC-974].
Anyway...do whatever you feel.."break" all of them for all I care...see how far that gets you in the real world.
Gerardo
Roger B.A. Klorese writes:
Explain me your ideology here...it is either a CORRECT one or NOT.
It doesn't matter if any of them are incorrect/broken. It only matters if
*all* of them are. Just as you shouldn't refuse to access foo.bar.com
because an A record for zap.bar.com is malformed, you shouldn't refuse to
try the 7th MX for bar.com because the 3rd one is malformed.
Now if you want the acceptance of broken MX records are being legitimate DNS entries by the internet community then I refer this again > RFC 2926
What does 2926 have at all to do with MX records?
------------------------------------------------------- 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
Gerardo A. Gregory
Manager Network Administration and Security
------------------------------------------------
Affinitas - Latin for "Relationship"
Helping Businesses Acquire, Retain, and Cultivate
Customers
Visit us at http://www.affinitas.net
------------------------------------------------------- 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
