Friday, May 11, 2007
false positives due to Microsoft's bad advice!
My systems try to reject as much incoming spam as possible by its origin, so we don't have to spend time analyzing it all. There are basically three ways:
This week we had a new one. The sender's IP Address doesn't really have a name: its name is only an alias (a "CNAME") of something else. Of course I put an exception in my Postfix setup for that particular sender. (Chico.com.)
But tracking down the problem revealed an interesting cause. The Domain Name System was invented in the early 1980s by some geniuses (Mockapetris, Barr, Postel, etc) and it works in a way that is described in some "RFC" documents from the Internet Engineering Task Force. These RFCs achieve "standards track" status after years of discussion and testing by more geniuses. RFCs level the playing field, by saying exactly how Internet software programs must talk to each other. That way anybody can write Internet software and expect it to work pretty well with what's already out there.
The RFCs say an Internet Protocol Address should be given a name and that name should be published in a "Pointer Resource Record" ("PTR Record" for short) in the DNS. The geniuses reserved a special domain for those, in-addr.arpa. I suppose that means something like "inverse addresses on the ARPANET." Then they say the name in the PTR Record must be defined by an Address Record.
Postfix lets you reject email from senders who don't have those two things (a PTR Record and a corresponding Address Record) going for them. The test is called "smtpd_client_restrictions = reject_unknown_client" and it's really productive. There are tens of millions of unnamed cable modems and DSL lines, full of trojaned Microsoft boxes, sending spam, and we reject it all.
The standard book about the DNS, DNS and BIND by Albitz and Liu, mentions the requirement that the PTR name must have a real Address Record. (They also mention that a workaround exists in the Internet Systems Consortium's domain name resolver subroutines, for PTRs that have an alias instead of a real name.) Cisco's book says "PTRs use official names not aliases." IBM's tutorial for setting up DNS on its unix (AIX) servers says "the name in the PTR record should have an actual Address record."
But Microsoft's Knowlege Base says go ahead and use CNAME Aliases for the names in your PTR records! They're telling people to break the rule that helps us reject spam efficiently. Why? Well, Microsoft has an attitude about the Internet standards. They don't like anything that levels the playing field. So their software intentionally misoperates in subtle ways. That way, if you're in an all-Microsoft shop, your stuff will work, inside your shop, and you'll think those weirdos out there who use software from anybody else are using broken software. They're counting on the all-Microsoft users to not know or care about the standards. This attitude and behavior was identified in Microsoft internal memos as a strategy. It's called "embrace, extend, and extinguish."
- The sender's IP address, or the range it's in, is known to send nothing but spam.
- The sender's software makes some protocol mistake during the SMTP session that legitimate senders don't make.
- The sender identifies itself with a name that isn't defined, or its IP Address (numerical network location) doesn't have a name, or has a name that isn't defiined.
This week we had a new one. The sender's IP Address doesn't really have a name: its name is only an alias (a "CNAME") of something else. Of course I put an exception in my Postfix setup for that particular sender. (Chico.com.)
But tracking down the problem revealed an interesting cause. The Domain Name System was invented in the early 1980s by some geniuses (Mockapetris, Barr, Postel, etc) and it works in a way that is described in some "RFC" documents from the Internet Engineering Task Force. These RFCs achieve "standards track" status after years of discussion and testing by more geniuses. RFCs level the playing field, by saying exactly how Internet software programs must talk to each other. That way anybody can write Internet software and expect it to work pretty well with what's already out there.
The RFCs say an Internet Protocol Address should be given a name and that name should be published in a "Pointer Resource Record" ("PTR Record" for short) in the DNS. The geniuses reserved a special domain for those, in-addr.arpa. I suppose that means something like "inverse addresses on the ARPANET." Then they say the name in the PTR Record must be defined by an Address Record.
Postfix lets you reject email from senders who don't have those two things (a PTR Record and a corresponding Address Record) going for them. The test is called "smtpd_client_restrictions = reject_unknown_client" and it's really productive. There are tens of millions of unnamed cable modems and DSL lines, full of trojaned Microsoft boxes, sending spam, and we reject it all.
The standard book about the DNS, DNS and BIND by Albitz and Liu, mentions the requirement that the PTR name must have a real Address Record. (They also mention that a workaround exists in the Internet Systems Consortium's domain name resolver subroutines, for PTRs that have an alias instead of a real name.) Cisco's book says "PTRs use official names not aliases." IBM's tutorial for setting up DNS on its unix (AIX) servers says "the name in the PTR record should have an actual Address record."
But Microsoft's Knowlege Base says go ahead and use CNAME Aliases for the names in your PTR records! They're telling people to break the rule that helps us reject spam efficiently. Why? Well, Microsoft has an attitude about the Internet standards. They don't like anything that levels the playing field. So their software intentionally misoperates in subtle ways. That way, if you're in an all-Microsoft shop, your stuff will work, inside your shop, and you'll think those weirdos out there who use software from anybody else are using broken software. They're counting on the all-Microsoft users to not know or care about the standards. This attitude and behavior was identified in Microsoft internal memos as a strategy. It's called "embrace, extend, and extinguish."
