Are PTR Records Important? 138
erfmuffin asks: "I work for a medium-sized regional ISP. Recently we configured our email gateway to refuse connections to IP addresses that do not resolve (ie no reverse DNS). I am amazed at how many legitimate domains use mail servers with no PTR record! At the same time, we have avoided a great deal of junk mail in one swoop. Wouldn't it be better for mankind if all mail servers refused mail from non-resolvable IPs? Should all legitimate mail servers have valid PTR records or has the world become too lazy to make email delivery, easier?"
Well (Score:2, Funny)
Have you sent a memo?
Re:Well (Score:1)
aren't putting coversheets on their TPS reports... Its easy to forget but necessary to do
Yes and no. (Score:5, Informative)
The fact that mail systems that require PTR records before accepting mail significantly reduces spam is reason enough that PTR records should be required. I too experience a great deal of mail problems due to a lack of PTR records but, it is worth the effort to stick to this policy. If you don't have a PTR record, you can't send me mail!
Re:Yes and no. (Score:3, Insightful)
Hang on a second, I'm dizzy. Woo. That's one hell of a circular argument you've got there. I'm still trying to sort it out, but it seems like you might have actually made two full circuits of the argument in that one sentence. Wow.
The implicit assumption behind all of that, though, is that stopping some spam is more important than delivering all legitim
Re:Yes and no. (Score:2)
Re:Yes and no. (Score:4, Informative)
I gues that you are entitled to your opinion but, I feel that the action is correct. The fact is that this policy works very well for me. The mail does go through, eventually.
Here's how it works. A user tries to send a message to someone inside my company. The message fails, of course, because my mail server rejects the connection due to the lack of a PTR. After a few attempts the sender either calls their admin or the intended recipient, who then calls me. Either way, the admin and I talk. He/she says your mail server is broken. I say no, it isn't, yours is misconfigured. Try sending a message from your Yahoo account and you will find that it is delivered. He/she then says, so why can't I send any mails to your domain. I respond that it is because your DNS is misconfigured. Call your ISP and ask them to add a PTR record for your mail server and the mail will flow.
Sometimes there is question about this along the lines of; well why can I send to these other domains? I explain that some administrators are willing to accept mail from misconfigured systems because there are so many of them and it makes the administrator's life easier. I then say; Trust me, call your ISP. It only takes a couple of minutes and you will never have to deal with this problem again.
Typically, I get a thanks via email the next day. If they refuse to make the changes I point out to my user that they are receiving mail from everywhere else just fine and they can even send to this broken domain. Thus, our mail system is working correctly and the problem is at the far end. Done.
Re:Yes and no. (Score:1, Insightful)
See? That's the part where the system is broken. You shouldn't have to do an end-run around ONE method of communication by using ANOTHER. If your email is broken, then your email is broken, and I (as the sender) shouldn't have to be bothered with it.
Typically, I get a thanks via email the next day.
Heh. I find that very hard to believe. If you get a "thanks" I'd be willing to bet it's just dripping wit
Re:Yes and no. (Score:1)
Re:Yes and no. (Score:2)
Re:Yes and no. (Score:1)
Re:Yes and no. - Think of it this way. (Score:1)
PTRs should not be required (Score:3, Insightful)
And this is a short-term fix which produces long-term issues. You reduce spam for eighteen months, spammers start just going through PTR-listed servers, and you're back to square one...except now you're using a broken mail system. Or spammers buy a throwaway domain -- they buy throwaway accounts, and a throwaway domain is no more trouble.
I personally
Re:PTRs should not be required (Score:4, Informative)
Requiring a reverse DNS record isn't forcing you to go out and buy a domain, just to bitch at your ISP to give you a valid reverse DNS. It can be in your domain, or in theirs, it just has to exist.
--Dan
Re:PTRs should not be required (Score:1)
Re:PTRs should not be required (Score:2)
Or it can be same domain used for reverse lookups. You can make the PTR record for 1.2.3.4 this: 4.3.2.1.in-addr.arpa
You're full of it. (Score:2)
The topic was about PTR records not domain names but, you gleefully offer up that you use your own personal mail system without even a domain name. You are one 1337 h4x0r. Are you using UUCP? Because I can't figure out how you are doing it with SMTP.
I can understand how you can send mail without a domain, although according to RFC 821 and its successor RFC 2821 you are required to enter a valid and r
Re:You're full of it. (Score:1)
Then you're ignorant. Although no MTA will do this by default, it's trivial to make it accept mail addressed to an IP. In the case of my MTA, Postfix, it's a simple matter of setting the mydestination parameter. Postfix will also deliver to user@ip.add.re.ss. The Unix mail command and mutt are both MUA's that will happily allow addressing to user@ip.add.re.ss.
I've found that rather than requiring a reverse DNS lookup o
Re:You're full of it. (Score:1)
I very much doubt this works over IPv6, though.
Re:PTRs should not be required (Score:1)
The answer's pretty simple... (Score:2, Insightful)
No it wouldnt be better (Score:4, Insightful)
I host maybe 7 domains, an email server, and several other things from my dynamic-ip DSL connection. Have been maintaining it for over a year with reasonable uptimes. I cant have PTR records or reverse resolution to my domain... but I dont send spam.
Many cottage-industry websites will be closed and not everyone can afford professional hosting services that use Jboss, postgresql, php4, ldap etc. Least fan sites that can make no money, and homepages.
Re:No it wouldnt be better (Score:4, Informative)
If your ISP doesn't do this, might I suggest shopping around for a new one?
I was under the impression the original question referred to completely nonexistent PTR records (that resolve to NXDOMAIN or similar).
Re:No it wouldnt be better (Score:1)
Original poster said "I can't do business because my ISP has no (X)".
My response was "go someplace that provides (X)".
Your response appears to be "Everyone should go out of their way to not need (X) anymo
Re:No it wouldnt be better (Score:1, Interesting)
Yes, that's mostly right. But rather than saying, "everyone should go out of his way not to need X any more," I'm saying, "no one should go out of his way to require X." See the difference?
No one should be required to change ISP's because somebody else set up a mail relay in such a way that it arbitrarily rejects messages based on PTR records.
Re:No it wouldnt be better (Score:5, Funny)
Hell, people who want their ISP to support PPP or IPv4 are just being bitchy. Nobody needs more then IPX over SLIP anyway.
--Dan
IPX over SLIP (Score:2)
Re:No it wouldnt be better (Score:2)
Or were you just trolling?
Re:No it wouldnt be better (Score:1)
I suspect more and more ISPs are going to follow what AOL did and reject mail from DSL addresses, so you are going to face problems in the future with this sort of setup.
silly (Score:1)
Thats all well and fine (Score:2)
I know there are tricks, one can play but i have yet to see one that works acceptably...or am I not reading the right HOWTO's...
My domain is hosted on the single IP I get from my cable modem. My DNS/WEB/Mail/etc are all hosted on the box connected to that cable modem...
so if a reverse DNS is required to get mail from me, I guess its impossible for me to send mail to such a system, because I have yet to get the DN
You're definitely reading the HOWTOs wrong. (Score:2)
Your server or network sits behind a cable modem so I will assume NAT is being used but, it doesn't matter.
Your server 10.0.0.3 or maybe multiple servers 10.0.0.3, 10.0.0.4, 10.0.0.5 are all NATted to 88.88.88.88, for arguments sake. Therefore you should have DNS records, on your ISP's DNS server, that read like this.
@ IN MX 10 mail.yourdomain.com
mail IN A 88.88.88.88
www IN CANME mail.
ftp IN CNAME mail.
88 IN PTR mail.
Your answer is definitely wrong. (Score:2)
Second, the guy stated he has a cable modem, and thus he has no access to the inverse zone files for his IP. The cable ISP does not *want* him to have his own domain name, so they will *not* delegate any of the inverse namespace (which they own) to him. They want to force all his mail through their unreliable, virus-plagued, incompetently administered mailservers and not allow him to run his own.
I recommend y
Re:You're definitely reading the HOWTOs wrong. (Score:2)
But there's the problem... with a cable modem and standard service, most users can't get the ISP to put records in for their DNS. My PTR is a long simple name ( foo-bar-baz.nycap.rr.com or something ) but my domains are registered with another registry. Anyone looking for my domain gets word fro
Re:You're definitely reading the HOWTOs wrong. (Score:2)
So why not simply change your HELO to "foo-bar-baz.nycap.rr.com"? (which, technically, it should be anyway, as that would be the canonical name for your IP address.)
Re:You're definitely reading the HOWTOs wrong. (Score:1)
Re:You're definitely reading the HOWTOs wrong. (Score:2)
Re:Thats all well and fine (Score:2)
I say IPv6 to the rescue. A broadband ISP that did that (used IPv6 and gave out lots of IP addresses with each DSL line) would have a distinctive market opportunity.
Discussion on spam, reverse DNS, etc. (Score:3, Informative)
There are a LOT of places though that don't set these records, and filtering out these sites will drop a LOT of emails that actually might be valid.
Re:Discussion on spam, reverse DNS, etc. (Score:2)
Yes, but our point is that those servers are misconfigured. It's not MY job to configure YOUR mailserver properly. Mine works and will continue to work properly. If _YOUR_ mailserver can not get YOUR email out, who's problem is it?
I suppose I should quit using the open relay/open proxy blacklists as well, since someone might really send email from one of
Re:Discussion on spam, reverse DNS, etc. (Score:2)
In my case, it's my problem, and my ISP's fault. My ISP doesn't provide reverse DNS. I've heard all sorts of excuses like "no one else has ever asked for it", etc. I've tried several people, on several occasions, and no one's willing to do the work to get me reverse DNS. Hey, it's a telco monopoly.
So I guess you'll never get mail from pretty much anyone in my country...
Well, (Score:2)
be bothered to set their forward and reverse DNS
properly. Chances are it's joe cablemodem user
with his Win2k server. I'd say it's more important
to do the checking for things like mail, http,
https, etc. and less important for things like
gaming servers and p2p file sharing.
Re:Well, (Score:1)
I think you are trolling here with that comment, but I'll respond anyway. Win2K DNS has a simple check box that makes the PTR record for you. I'd bet $20 that most of incorrectly set up DNS machines are people running old versions of BIND.
Re:Well, (Score:2)
And if you don't remember to set the simple-minded check box on from its default off state EVERY GODDAMN TIME you end up with an inconsistent set of records. I used to have a reminder set monthly to go clean up our win2k DNS (until we got some competent admins who knew what PTR records were).
More Importantly..... (Score:2)
click all the boxes he wants, but still won't
have control over his reverse DNS most of the time.
So clicking the little box will accomplish
absolutely nothing. You have to be authoritative for
your forward and reverse to muck with it. As for
running old versions of bind, I have about as much
respect for a so-called company that can't be
bothered to set their reverse DNS, as I do for one
that can't be bothered to hire a DNS admin smart
enough to keep a current version o
The answer is "no" (Score:5, Interesting)
No. Why? Let's look at this philosophically.
The purpose of email is to facilitate communication. That's it. One person sends an email to another with the intention that the message be received and read. The sender implicitly assumes that the message will, in fact, be received by the recipient, because the email system is based around that assumption. If the system works correctly, your mail will be delivered.
Any failure to deliver mail is a failure of the system. Period. The system exists to put mail in mailboxes, not to selectively put mail in mailboxes.
Now, spam. Spam is a problem, sure. It's not nearly as big a problem as a few people seem to think it is, but it's a problem. But the correct solution to the problem of nuisance mail is not to break the implied contract between the sender and the mail system as a whole. "Your mail will be delivered to its recipient." That's the implied contract. (I'm speaking metaphorically. There's no actual contract here, of course.) Anything that bolts on an "except" or "unless" to that implied contract is a bug, not a feature.
Now, in my opinion the correct way to deal with spam is to filter it on the receiving end. All mail should be delivered, but the recipient's automation may choose to flag some messages based on their content or their envelope or whatever. Some carriers don't like this idea because it requires them to deal with mail that people don't generally want to read, but choosing not to deal with certain pieces of mail is far worse.
That's the abstract argument. Here's the concrete one. If I send a piece of mail, I generally have no control whatsoever over, or even knowledge of, the bits and pieces that make up the delivery chain. My message leaves my computer and goes to an upstream server which then delivers it to another server, which then delivers it to the recipient. If that delivery process should fail because of the way the machines in the middle are configured, then that's going to be a problem for me. A very serious problem, over which I have absolutely no control.
Look at it this way. Let's say the postal service institutes a new regulation that no letters will be delivered if they're picked up by a mail carrier in brown shoes. Okay? Only white-shoe-wearing mail carriers are authorized to pick up mail. The mailman who serves my neighborhood forgets to wear his white shoes tomorrow when he picks up my outgoing mail. He gets to the post office and is told, summarily, that none of the letters in his bag will be accepted for processing because he's wearing the wrong color shoes.
How would I feel under those circumstances? Annoyed. Really annoyed. And so would all the other people on my block.
People who manage email servers really need to adopt the mailman's philosophy: we don't care what the mail is. We deliver it. No matter what, if it's got adequate postage on it (which doesn't apply to email), we deliver it. Neither rain, nor sleet, nor dark of night... and so on.
Re:The answer is "no" (Score:4, Insightful)
The same was once thought of having open relays, too. See how we changed out behavior with those?
Re:The answer is "no" (Score:1, Interesting)
Yes, and I think that's a giant step backwards. I'll give you an example. A coworker of mine used to carry a laptop. While at home, he would dial in to the Internet through Earthlink and send and receive email. In those cases, he had to send email through the Earthlink SMTP server, because outgoing SMTP connections from Earthlink were blocked. He couldn't connect to the company's SMTP server at all from his h
Re:The answer is "no" (Score:1)
Re:The answer is "no" (Score:1)
I don't understand why more sites don't use this, I just commented that workarounds for the problem you're facing DO exist.
Re:The answer is "dumbass" (Score:2)
Perhaps you don't think spam is a problem. You, however, are wrong. When 80% of my incoming mail was spam, I'm spending 5 TIMES what I should be to deliver legitimate email. With that incredible volume, people's filters were failing and their inboxes were full of horsefucking herbal viagra peddlers. (Now with 95% more teen webcams!)
By saying "fuckoff" to spammers, open relays, open proxies and general idiots, my users can actually USE their email, and the mailserver can get the leg
Re:The answer is "dumbass" (Score:2)
Correct. I only accept mail from properly configured mailservers. The USPS dosn't pick up letters lying on the hood of my car and deliver them, they only take mail from approved mailboxes.
Obviously, they're part of the problem!
If you don't think spam is a problem,
Re:The answer is "dumbass" (Score:3, Interesting)
You're right, I just pulled this [faqs.org] right out of my ass as well. Nobody would bother to draft a best-current-practices about spam. And besides, it's only a reques
Re:The answer is "no" (Score:2)
The problem with filtering at the receiving end is that you have an entire transit infrastructure that has to be radically upsized for mail that is simply not going to be read in the end. That works for a postal system where transmission has costs associated with it but here we have a system where sending is essentially free
Re:The answer is "no" (Score:2)
People don't mind carrying legitimate mail for free because legitimate stuff actually doesn't cost enough that the costs outweigh the non-monetary benefits. If you say to large networks that they're just going to have to eat a never-ending cost black hole of more and
Re:The answer is "no" (Score:1)
Spoken like someone who doesn't get much spam, and doesn't pay for traffic.
Your analogy is flawed (Score:2)
A better analogy would be:
"What if the post office refused to deliver any mail that did not have a correct return address on it."
And guess what? In this post-911, post-anthrax mail, THEY WILL! You don't put a return address on the mail, they drop it - the Post Office I use has that sign right over the drop box.
Re:Your analogy is flawed (Score:1, Interesting)
If we were talking about valid return addresses, that would be fine. But we're not. We're talking about IP-address-to-name mappings, a feature of the IP system that computers themselves were never intended to make any real use of in the first place.
Now, to extend the analogy to the breaking point, the post office does not verify that your return address is actually correct when it accepts your mail. It
Re:Your analogy is flawed (Score:1)
Almost all mail I send doesn't have a return address on it. I haven't had a piece of mail lost in over 15 years, and I send and receive a lot of mail.
Re:The answer is "no" (Score:2)
Apply that paragraph to the postal mail service. So, if someone sends you anthrax, or a rod of plutonium, then the po
what about the price that the receiver has to pay? (Score:1)
Right now I'm in the US and I pay a flat rate for my cable modem, but not too long ago I lived in France and had to pay per-minute charges to the phone company for my dialup. My ISP charged a fla
Re:what about the price that the receiver has to p (Score:2)
Cutting off legitimate mail servers because they lack PTR records is not an acceptable solution...
Tell me why a legitimate mail server can't have a PTR record? There's no reason why someone running a legitimate mail server can't have the PTR record set up correctly. And that's the reason why it's so strange when they don't set it up properly. Why would someone act like a spammer (fail to set up PTR records) when
Re:The answer is "no" (Score:1)
Wow, apparently you don't run a mail server that gets 2.5 million messages a day. You can upgrade your mail servers all year round as an exercise in futility, it's fun. Add a new CPU and more memory, and your relays will be happy for a few hours, then end up where you have been for the past year... with 40,000 messages queued up waiting for delivery. You have just built a more power
Re:The answer is "no" (Score:1)
By your rationale, shouldn't RBLs and the like quit blacklisting an entire
Just curious.
-sid
Re:The answer is "no" (Score:1)
I agree also. One of my clients managed to get a /28 within the same /24 with a 'spammer.' I posted this info and a request for an update to the mail-abuse section of groups.google.com and got an earful of reasons why my client should be penalized for their 'neighbors' actions. And good luck getting removed from the blacklist in any reasonable amount of time.... the o
Re:The answer is "no" (Score:2)
Very true. And spam hinders that. I'm getting 2:1 spam vs real mail these days, and it's only getting worse. If I can get rid of a bunch of spam, that will improve email's power to facilitate communication by some factor; let's call it x. Now if that action also impedes communication for some users and we call that y, then using your theory, we should take that action in the cases where x > y.
In my experience, rejecting mail from poorly ma
Re:The answer is "no" (Score:2)
DUCK! QUICKLY (Score:5, Interesting)
FOR THE LOVE OF $DEITY MAN, DUCK AND COVER!
You are about to be flamed by all the "How DARE you limit me! I have the $deity-given right to send email from ANYTHING, and YOU are wanting to RESTRICT IT! YOU BASTARD FACIST COMMIE!" types.
Personally, I would want my mail server configured to do something like this:
Get Host's name as given in EHLO.
Look that name up.
if (IP address from DNS != IP address talking to me)
Bugger off spammer
endif
reverse look up IP address talking to me
if (name from DNS != name from EHLO)
Look up name from DNS
if (ip address from lookup != IP address talking to me)
Bugger off spammer
endif
endif
Accept mail.
(It is assumed the "bugger off spammer" state is a terminal state).
This way, even if your box's reverse lookup is foo.bar.baz.adsl.example.com rather than mybox.example.com, so long as foo.bar.baz.adsl.example.com resolves to your IP address you wouldn't be rejected.
Re:DUCK! QUICKLY (Score:1)
Does anybody know how to configure postfix to behave like that pseudo code.
TIA.
Yes, it has (Score:5, Informative)
I don't know of any specific RFC that requires reverse DNS for SMTP but the RFCs do require that the HELO/EHLO be 1) fully qualified and 2) resolvable.
I strongly recommend enforcing that rule even though you will be amazed at the number of mailservers that are not configured properly to follow this basic requirement of RFC2821.
Naturally it's not a bad idea to then look up the EHLO domain and make sure it resolves back to the connecting IP. Something like 25% of the mail I reject is rejected for greeting me with my own IP or hostname.
Re:Yes, it has (Score:1)
Re: (Score:1)
Re:Odd that you ask... (Score:1)
Are you assigning a separate IP address to each of your domain names? That's crazy expensive, given the cost of IP space. If not, you've created multiple PTR records for the same address, which is not valid. (While names can sensibly have multiple addresses, it doesn't make a lot of sense for an address to resolve to multiple names.)
The '@' is a, um, macro or variable (I forget what the offical name for it is) that is the name of the zone (i.e., the domain). You can use this mechanism to use one or a
Re: (Score:1)
Legitimate mail from unknown IPs (Score:2)
I love it when slashdot has a story related to a problem I'm having at that very instant. How often does that happen?
Here's the thing: we're moving a site to a new server with it's own shiny IP address. There are many things on this site that send mail. None of these things will successfully get mail through in this circumstance because this IP doesn't have a DNS entry for it until the site goes live on the new server. Reverse lookups point to the current IP, not the shiny new one. Mail rejected as spam. A
Re:Legitimate mail from unknown IPs (Score:3, Informative)
By this I mean:
1) your company is called company.com and sends mail from either your old mailserver 4.5.6.7 or your new mailserver 1.2.3.4
2) your shiny new mailserver's ip address may reverse lookup from 1.2.3.4 to t1-65.gateway4.myisp.com.
Your ISP probably does this for you already.
3) you could have t1-65.gateway4.myisp.com resolve to 1.2.3.4.
I don't even know if 3 matching 2 is nec
Re:Legitimate mail from unknown IPs (Score:1)
Ah, thanks...we requested number 2 yesterday, which is theoretically take care of. Number 3 may or may not be an issue - guess I'll find out.
Really, I'm just a web guy who knows enough TLAs that people sometimes think I know what I'm talking about. You've given me a good starting point for initiating the conversation, at least. Thanks!
Re:Legitimate mail from unknown IPs (Score:2)
But if you can't get that going for some reason or other, just forward all mail from the new mailserver through the old mailserver.
For example, if you are using sendmail, you set up the new mailserver to use the old one as a "smart hub" and explicitly list the new mailserver's address in the old mailservers access.db as being allowed to relay mail.
I can get more detailed if you want, but on
Re:Legitimate mail from unknown IPs (Score:1)
Don't I know it! Unfortunately, it's an existing site on a (crappy) host that we're moving to a dedicated server. There's going to be disruptions (lots of data to sync), but as much as possible we're trying to keep it up and available. Also, unfortunately, we don't have access to the config files on the old server, so we can't do fun routing things.
Thanks for the offer of more details, but
I agree in theory. (Score:5, Interesting)
Both have valid points.
I once tried this restriction with my employer's email server (we host a handful of university domains). It was a complete failure. Not because it didn't stop spam (I was finding several thousand spams per day rejected -- a 75% reduction of mail let through!), but because there were so damned many legit domains that didn't play by these common sense rules which you seek to enforce.
The overheard of me fielding complaints from my users was just too much. You'd think that the bloody sender would get the clue that it was a problem at his end (due to the bounce messages provided by postfix), but that just wasn't the case.
So I turned off the rules. I did come up with a compromize (I use postfix, btw). For major domains that should know better, and are in fact configured correctly (aol, hotmail, msn, etc.), I add a line like "earthlink.com reject_unknown_client" in my file pointed to by the check_sender_access line in my main.cf file.
Also, when I receive a piece of spam that gets through, I add the forged From: domain to that list if the connecting client was "unknown". I then add the "reject_unknown_client" restriction to the offending class-C in my check_client_access file in main.cf.
This method catches quite a few (maybe 50%). I use a few free RBLs to catch maybe 45% more spams. That other 5% gets through, but I haven't had a single complaint from my users since beginning this practice. So we're all smiles here now.
If and when I ever run my own email domains (business and personal), I will use all the rules postfix can enforce.
Setting up postfix to do this? (Score:1)
Re:Setting up postfix to do this? (Score:3, Informative)
Also, the sample configs provided in the postfix distribution are a great resource. I haven't found a good definitive list of all postfix parameters and what they do in an easy-to-browse form. For now, we're stuck with trudging through the postfix documentation.
Re:Setting up postfix to do this? (Score:2)
It's Ralf Hildebrandt, and his most useful homepage can be found here [tu-bs.de].
My apologies, Ralf.
Re:Setting up postfix to do this? (Score:1)
Re:I agree in theory. (Score:1)
-sid
Not a big problem? (Score:1)
Spam is a problem, sure. It's not nearly as big a problem as a few people seem to think it is, but it's a problem.
I bet you don't work for an ISP. If you did, you would probably be aware of the incredible financial burden that ISPs have to carry in the wake of junk mass mailings. The bottom line is that the spammers are putting the livelyhoods of Mom & Pop ISPs in serious jeapordy. Adherence to the RFCs seems pretty fair if it means saving jobs.
Speaking pragmaticly, however, I wouldn't block mail
ISPs are mostly the problem. (Score:2, Insightful)
I could knock out every nimda and code red on comcast.net in 48 hours using their existing equipment. A little gawk, netcat, and snort and the manual for their switches is all I'd need.
Similarly, the 100+ virii and spam I receive every weekend are mostly coming from AOL. I can detect them with MailScanner and SpamAssassin, using a P-133 computer running linux - I suspect AOL could do it too.
But the big ISPs a
Re:ISPs are mostly the problem. (Score:1)
Re:Not a big problem? (Score:1)
So yeah, I doubt my "large" ISP (services like 4 provinces) runs spam filtering. Well, I know for a fact they don't.
So, if they just filtered the spam, it would save them a ton of bandwidth delivering it to the user.
Yes. (Score:2)
I've found many ISPs are lazy about adding reverse DNS records. I've also had a hell of a time getting them to delegate the zone to my server when they won't handle it themselves. Still, there's lots and lots of spam that's not showing up. And earthlink, AOL, roadrunner and yahoo! have valid
Quite (Score:2)
Here's an even BETTER idea! (Score:5, Funny)
I have analyzed the vast body of spam (for Bayes purposes) that has come through my mailservers over the last year or so, and I find that a lot of spam is sourced from IP addresses that include this number.
Sometimes it's x.x.68.x, sometimes it's x.n68.x.x, but that evil little 68 just keeps popping up!
According to my numbers, a greater amount of spam comes from IPs containing 68 or 24 than comes from domains with inconsistent PTRs.
So, using your own logic, I should just ban all IPs with 68 in them, and tell people with legitimate Email needs that they will have to find a new ISP.
To paraphrase a previous poster [slashdot.org], "The fact that discarding mail from addresses containing the number 68 significantly reduces spam is reason enough that everyone should do so. I too will have to stop using a bunch of numbers I own but, it is worth the effort to stick to this policy. If you have a 68 in your IP, you can't send me mail!"
Note to moderators: Irony is not the same thing as flamebait...
This for that (Score:2, Insightful)
1) DNS management is often delegated to the ISP. If that ISP develops such bad habits as ignoring customers' reverse DNS when making updates to forwards, they have a fleet of Internet users with no reverse DNS.
2) IT personnel often don't have DNS authority for their IP addresses because its not worth the hassle for ISPs to give their customers reverse authority for on
RFC1912 - 2.1 (Score:2)
Re:RFC1912 - 2.1 (Score:2)
I would do they same, but I believe this causes problems for people with only 1 ip address.
Re:RFC1912 - 2.1 (Score:2)
Re:RFC1912 - 2.1 (Score:2)
Thank again, I could be wrong and misunderstood what I read.
Re:RFC1912 - 2.1 (Score:2)
This record/entry can be changed by your ISP if you request it, so instead of cablemodemxxx-xxx-xxx-xxx.isp.net they could point it to something like machine.yourowndomain.com. There are several ISP'
Points to consider (Score:2)
First I found that being unable to resolve a PTR record is sometimes not an indication of a lack of a PTR. Depending on what DNS server your mail agent uses to do the reverse lookups, as well as the TTL (time to live) setting of the records, you might find mail gets rejected from legitimate sources. Several clients have had downtime on their DNS servers for their IP space, so PTR records wouldn't resolve. We reje
My solution: The mail toaster (Score:2)
Together, these have reduced about 90% of the spam my users were receiving.
The toaster (basically qmail with tarpitting, secure remote access and apache/mysql for a webmail component) is secure, free and supported by an active mail list. You might want to