[Mimedefang] OT: DNS sanity check

[John Rudd]

Les Mikesell wrote:
> John Rudd wrote:
> 
>>> The ones that will fail are the  connections to businesses where the 
>>> delegations are made to servers that don't bother to maintain a 
>>> meaningless name for this association and for one reason or another 
>>> the meaningful name is changed or never set up to match.
>>
>> In other words, lazy sysadmins and/or ignorant management above the 
>> sysadmins that keeps the sysadmins from doing the right thing. 
> 
> Yes, something I'd expect at a lot of businesses whose primary business 
> is not being an ISP, but where a large amount of legitimate email will 
> originate.

Business which do this are the equivalent of business whose primary 
marquis or sign is written in crayon on cardboard.

Do you buy your server equipment from businesses which look/act that 
unprofessional?

Do you engage in multi-million-dollar transactions with businesses that 
look/act that unprofessional?

I'm certainly not interested in dealing with rinky-dink operations like 
that.

And, luckily, they're a minority.  It's not "a lot of businesses", it's 
fairly small in the greater scope of things.  Because most businesses 
need to display a professional appearance, and take care of these 
things.  And the ones that don't will take note of it when you point it 
out to them.  Most of the few false positives I did come across were 
fixed relatively quickly after I mentioned it to them on both the 
technical and professional level.


>> Bringing in to question what other inadequate practices they have, 
>> such as things that might allow them to be an open relay, or 
>> compromised entirely to be used as some other form of inappropriate 
>> traffic.
> 
> That's not so much the question as whether you are interested in the 
> mail from the individuals at these locations.

I'm not interested in any kind of traffic from poorly managed sites. 
So, yes, the question I asked is the right question for me (since you 
specified whether I am interested in the mail).

There are a handful that, on the work side of things, I have to deal 
with anyway, but I do things to encourage them to fix their stupidity.


>>> Yes, I guess that's correct for this particular situation.  And 
>>> easily handled by the delegated server for the IP range if he is 
>>> willing to match it up with a meaningless name in a forward domain 
>>> that he also controls - without any regard to the actual use of the 
>>> address or real domain of the host(s) involved.  A real spammer would 
>>> be sure to get this right...
>>>
>>
>> A real spammer doesn't have control over this when it comes to 
>> botnets, which are the hosts that are in question:
> 
> A real spammer will have thousands of bots at his disposal and the 
> ability to send rejected attempts through a different source.

Most of which have:

a) poorly managed DNS, or

b) DNS that indicates an end client of some kind (IP address in host 
name, client-words in host name (such as "dhcp", "dsl", "ppp", "client", 
etc.).

Those are the two things my code looks for, with a few exception cases. 
  And, like I said, tiny rate of false positives.

Yes, there are other hosts that are botnets that my code doesn't catch. 
  But, the bulk of them are caught by those two hurdles.


>> a) hosts that aren't being properly managed, and thus are likely 
>> targets for exploits such as spambots and virusbots, or
> 
> But these are most likely on ISP managed connections.

I'm not sure what relevance that comment has.  It doesn't matter to me 
whether it's an ISP managed address, a government managed address, an 
edu managed address, a large business managed address, etc.  What 
matters is whether or not it's poorly managed, and thus a predictor for 
being exploitable, and thus a predictor of having been exploited.

_Who_ is poorly managing it is pretty much a non-issue.


>> b) hosts that aren't supposed to be sending email out of their own 
>> domain at all (the hosts that don't have PTR records, or matching PTR 
>> and DNS records, and aren't in the mismanaged category, probably 
>> weren't intended to be talking to the outside world at all).
> 
> And these will be NATed at an ISP-managed gateway.

If that were true, I wouldn't be getting the results I get.