Now you have to have the right reverse-DNS

Topic: 

Update: Several of the spam bounces of this sort that I got were traced to the same anti-spam system, and the operator says it was not intentional, and has been corrected. So it may not be quite as bad as it seemed quite yet.

I have a social list of people I invite to parties. Every time I mail to it, I feel the impact of spam and anti-spam. Always several people have given up on a mailbox. And I run into new spam filters blocking the mail.

Perhaps I'm an old timer, but I run my own mail server. It's in my house. I read my mail on that actual machine, and because of that, mail is wicked-fast for me, as fast as instant messaging for many people. (In fact, I never adopted IM the way some people did because E-mail is as fast.)

They're working to make this harder to do. Many ISPs won't even let you send mail directly, or demand you make a special request to have the mail port open to you. I'm bothered by the first case, less so by the second, because indeed, zombie PCs send much of the spam we're now getting.

Because I send mail from the system, I also web surf from it. And while it's not a serious privacy protection, I decided I would not have a reverse-DNS record for my system. That way people would not see "templetons.com" in their web logs whenever I surfed. It's not that you can't use other techniques to find out that the address is mine, but that requires deliberate thought. Reverse DNS is automatic for many web logs.

Soon more and more sites would not take mail from a system without reverse DNS. Because I get my IP block from a small ISP, he does my reverse DNS, and I asked him to make one. He made one like many ISPs do, built from the IP numbers themselves. As in ip-nn-nn-nn.ispname.com.

But soon I saw bounces that said, "This reverse DNS looks like a dialup user, I won't take your mail." So I had him change it to a different string that doesn't trumpet my name but doesn't look like a standard anonymous reverse DNS.

But now I'm getting bounces just because the reverse DNS doesn't match the name my mail server uses. There is no security in this, any spammer can program their mail server to use the reverse DNS name of the system they have taken over. But I guess some don't, so another wall is thrown up, and those people won't get invites to my parties.

This one is really stupid because it's quite common for a single machine to have many names and serve many domains. To correct an earlier note, it is possible for an IP to have more than one PTR reverse DNS record, though I don't know how many applications deal with that. And that screws these mailers. There is no need to look at reverse DNS at all.

Sigh.

Comments

I have a similar setup: I run my own mail server at home, so email
arrives directly on my computer (actually, a cluster of computers).
In fact, I "feel" an email arriving a few seconds before the broadcast
informing me of new mail because of the characteristic sounds made by
the hard disks.

When I first started out, I noticed that I got some bounces since I
was sending from a "dialup IP address" (it is also dynamic and changes
once a day or so---no problem with short TTL DNS records). The
solution was to send email through an SMTP relay server provided by my
ISP. The cost is minimal. (My dynamic-DNS provider
http://www.dynaccess.com doesn't charge for individual services,
but rather has packages with more and more features. Even if such
a package offers one something one wouldn't use, the rates are still
good compared to other providers and some services are offered only
by this provider, as far as I know.)

At first, I got little spam, due mainly to avoiding having the new
email addresses in the clear on usenet or the web. After a while,
however, I started getting spam. (Much of it was dictionary-attack
spam; there is little that one can do to avoid that, except making
the email address as long as possible, which has some disadvantages).
I set up some anti-spam filtering, such as rejecting email from
senders, IP addresses etc which had spammed me in the past, as well
as dropping the connection immediately if email was sent to a
non-existent user. (This actually had the biggest effect, which ties
in with the suspicion that much of the spam was dictionary-attack
spam.)

A few weeks ago, spam picked up again. It seems that most of this
comes from virus-infested PCs. I suppose there are viruses which
scan PC hard disks for email addresses and use them as spam targets.
There is little one can do to avoid this (unfortunately, hoping
that folks move from PCs to better computers is probably unrealistic).
(It is interesting to see what kind of traffic gets as far as my
router. I drop some connections at the router since these are to
ports used by protocols I don't even run and presumably are the
results of viruses as well. Since no application is listening on
the port, no harm is done on my side, but I might as well drop the
connection at the router to save resources. This might make an
intelligent virus decide to move on rather than trying the IP
address again (possibly for something different).)

I am thus considering, as a next step, blocking email from
dialup IP addresses. Since sending email through a trusted
SMTP relay server is a small cost compared to all the other
computer-related costs one has, I doubt that much real email is
sent directly from dynmic IP addresses and even if someone gets
blocked, I think that my reasoning would convince him to send his
email through a trusted server, especially since I'm probably not
the only one blocking.

Note that I would not bother with reverse DNS at all. As you point
out, there are legitimate reasons for one IP address having several
CNAMEs or even A-records, though at most one of these will be
the result of the reverse-DNS lookup on the IP addresses. Also, I
would block stuff sent (directly) from dialup IP addresses.

Do you think that much legitimate email is being sent directly
from dialup IP addresses?

I'm surprised you are not having problems by people just
blocking email from you since it is from a dynamic-IP address,
regardless of what is in the DNS.

Note that some email servers want SMTP-authentication. However,
there is another solution, as implemented by my dynamic-DNS provider:
accept email from current active customers (he knows my current IP
address already, of course). There is also no charge per email; it's
a flat rate. (However, if someone sends more than a "normal" amount
of email, transmission will be blocked so that the problem can be
sorted out. The provider wants to avoid his server from becoming
blacklisted. If one has legitimate mass emails (e.g. if you are
running a list server or something), then one can register these
special addresses. So, no hassle, everything works, costs are minimal
and if everyone did this there might still be a lot of spam, but
no-one would see it.

Email me privately if you have any experience with or thoughts
on tarpits. (For obvious reasons, discussion of this topic might
not be good to have in public.)

My IP address is not dynamic, it is static. I could relay via the ISP but as a general principle that provides one more thing to go wrong, one more point of intercept etc.

And it provides another big risk. If a spammer joins your ISP and gets spam through that mail server, it can get blacklisted. Yes, sometimes your whole ISP's network can be blacklisted by the worst of the crazed anti-spammers, but that's less common.

Of course, they want you to route your mail through the ISP just so that they can blacklist more easily. They want to have somebody who will feel the pain if they are blacklisted.

Since the basic problem is "dialup" vs. "normal" IP address,
the issue of static or dynamic doesn't really enter. Your IP
address is blocked and you want to solve the problem.

Yes, an SMTP server at the ISP (or, in my case, the dynamic-DNS
provider, who is not the same as the ISP) is one more thing to go
wrong, and at first I didn't like the idea since everything else
is in my house. However, the SMTP server has less downtime than
I do (and I have very little) and it is a "set it up and forget it"
type of thing. It's a lot less hassle than having, say, web pages
on another machine.

Any responsible SMTP relay server will not relay spam. My provider
will drop the connection if more than a normal amount of email
tries to be sent within a given time. This forces people to
correct the problem. (Presumably, when it happens, it is due to
a virus-infested PC.)

Despite my hatred of them, I doubt that spammers care if other people
get blacklisted when they do. They want their email to get out,
and though this bothers many people, they're not into bothering people
per se; it's just a side effec of spamming.

"Any responsible SMTP relay server will not relay spam." - I respectfully take issue with this rather basic statement.

I consider our network to be 'responsible' but when our hosting clients blindly forward all email from an account with us to their AOL account (for instance), it causes problems that are broken down here-

1) client sets up forwarding for an account we give him to his AOL account

2) client receives spam; it is automatically forwarded to his AOL account.

3) client sees the spam at his AOL account and marks it as such, and AOL ends up penalizing US, because we are the last mail server to send this message, even though we aren't the spammer.

So it can happen to 'responsible' providers, too.

The main idea behind reverse-dns for mailservers is that a 'reputable' server would have an admin that would spend the time setting up a reverse-dns entry for the IP, but a hacked box or temporary spam site wouldn't. While this simple logic on the surface makes sense, this is obviously not a working model.

And while smaller ISP's are starting to adopt this policy, you can thank the largest providers for instituting this. The lamest thing is that spam has gotten so much worse over the years, yet they still cling to this practice as being a preventive measure-- but given the increase in spam I'm not sure they could prove it's really been that effective.

A question- would it really hurt to have the reverse-dns entry elucidate that the host is, in fact, a mail server? I know the basic idea is that you don't want to volunteer information, but from what I can tell, it's not only not the only way to identify a host as a mail server, but it's also not the preferred way... are we basically holding onto obscurity for nothing? When can we tell the emperor he's naked?

Two points. First, what you are describing is, from the point
of view of AOL, not really spam. While I agree that unsolicited
commercial email is spam, normally the problem is sending a huge
amount of identical messages within a short time. You aren't doing
that (unless a lot of your users are all getting the same spam message
at the same time.)

Second, and more important here, it should be obvious from the
headers what is going on and AOL shouldn't be penalising you.
I normally receive my email at home but, if there are problems,
someone trying to send me email will end up sending it to one of
the backup MX servers, which will then later forward it on to me.
The last link in the chain is then this backup MX server, but I would
be wrong to complain that it is sending me spam.

I don't really see the point of your customers having an email address
with you if they just forward the stuff to their AOL account. Why
don't they just have stuff sent to the AOL account?

"Why don't they just have stuff sent to the AOL account?"

Hallelujah! I have no idea why they continue to do this... and we tell them as well when this happens. Yet they continue to do this (usually not the same customers over and over again, but sometimes.)

And AOL shouldn't penalize us, but they do... I'll find out more from our mail admin, but I think they really don't go over the headers unless we address the issue...

AOL has horrible practices for E-Mail.

Not only have we been blocked for people who were forwarding E-Mail to their AOL E-Mail accounts from their hosted E-Mail Addresses but we have also been blocked by AOL for bouncing messages back to them!

To fix both we filled out and had ourselves added to AOLs White List.

But now there's another problem from AOL. Not only must the IP Address of the server the E-Mail is coming from match the IP Address shown in the DNS for the same server name, but now that reverse address must map to the server name shown from the E-Mail Server as well! Not only that but there was NO WARNING that they would be making such a major change.

I've recently started using policyd-weight, which nicely handles this sort of case (and mostly mitigates the impact of single bofh rbl mis-listings.) It performs basic sanity checks on incoming connections but still works OK with dynamic IPs (and other non-matching reverse lookups) unless you are listed in multiple RBLs.

It trimmed my inbound spam volume ~90% (reducing the load on my dspam filter accordingly.) If you're a postfix user, check it out http://www.policyd-weight.org/


But now I’m getting bounces just because the reverse DNS doesn’t match the name my mail server uses. There is no security in this, any spammer can program their mail server to use the reverse DNS name of the system they have taken over. But I guess some don’t, so another wall is thrown up, and those people won’t get invites to my parties.

Doesn't matter what they program the name to show. Servers that require rDNS also do a forward lookup on the domain name and match the IP address. So this only applies to a computer that's been taken over. At that point, other rules will take over like connections per IP and such.

This one is really stupid because it’s quite common for a single machine to have many names and serve many domains. However, it can only have one reverse-dns for each IP address it has. And that screws these mailers.

1) A machine only has one name it uses in the HELO command, the actual machine name. That is the one that must have rDNS.

2) You can have multiple reverse DNS for a single IP:

; <<>> DiG 9.2.1 <<>> -x 206.125.209.104
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16414
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;104.209.125.206.in-addr.arpa. IN PTR

;; ANSWER SECTION:
104.209.125.206.in-addr.arpa. 86400 IN PTR ecc.net.in.
104.209.125.206.in-addr.arpa. 86400 IN PTR mistral.co.in.
104.209.125.206.in-addr.arpa. 86400 IN PTR mistralsolutions.com.

You can have more than one PTR record. As noted, PTR records must be re-verified with a lookup. However, they actually serve no purpose. When you get your HELO/EHLO, you should just look up that address and see if it gives you the same IP you're receiving the connection from. No need to look at the reverse DNS.

Add new comment