Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Spam

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?"
This discussion has been archived. No new comments can be posted.

Are PTR Records Important?

Comments Filter:
  • Well (Score:2, Funny)

    They are certainly just as important as TPS reports, if not more so.

    Have you sent a memo?
    • This is very much on-topic. erfmuffin is complaining because people
      aren't putting coversheets on their TPS reports... Its easy to forget but necessary to do
  • Yes and no. (Score:5, Informative)

    by FreeLinux ( 555387 ) on Wednesday May 07, 2003 @01:38PM (#5902785)
    PTR records are not necessary. They are not required for the internet to work acceptably. But, PTR records do add considerable convenience to network operation and they are a part of the DNS standard specification so, they should be used.

    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)

      by Anonymous Coward
      The fact that mail systems that require PTR records before accepting mail significantly reduces spam is reason enough that PTR records should be required.

      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
      • This depends a lot on how much spam you get. Over the past year I've been averaging over 50 a day (I should really graph this to see which direction it's going in). Spamassassin generally stops somewhere around 95% of this, though it's lower at the moment. That's about 4 times the amount of legitimate mail I get. Without spamassassin, I'd be finding email almost entirely useless, and at that point I'd be happy to bounce (but not drop) some legitimate mail in order to reduce the spam load.
      • Re:Yes and no. (Score:4, Informative)

        by FreeLinux ( 555387 ) on Wednesday May 07, 2003 @02:18PM (#5903255)
        That's completely wrongheaded. Mail should be delivered.

        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)

          by Anonymous Coward
          After a few attempts the sender either calls their admin or the intended recipient, who then calls me.

          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
        • And you still have a job?

      • I completly agree, just because a reverse lookup doesn't work doesn't mean that possibly valid mail shouldn't be let through. I've frequently looked at spam and very often the @name.com doesn't even exist!!! I mean the URL is not valid. BUT why has nobody tried enforcing forward lookups? My IP officially is dynamic and the reverse lookup is basically MYIP.MYISP.com BUT my forward lookup WILL resolve to my current IP. I would prefer that mail servers if spam is such a problem, check the forward lookup, it wo
      • I live in Canada and, on several occasions over the last few years, I've put the wrong amount of postage on my mail.

        The reason was that the postal rate for basic lettermail had gone up, typically by 1 or 2 cents, never more than that.
        So, what action did they take? If, as is my habit, my return address was on the letter, they return it to me. If I've not put a return address, it becomes, I imagine, undeliverable.
        Now, this cannot be the most economical or customer friendly way to deal with it but that's t

    • The fact that mail systems that require PTR records before accepting mail significantly reduces spam is reason enough that PTR records should be required.

      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
      • by Harik ( 4023 ) <Harik@chaos.ao.net> on Wednesday May 07, 2003 @02:53PM (#5903619)
        I personally run a mail server on my computer, and don't gateway mail it sends. That's the way email was designed to work, and still the way it works best. I think that's pretty legitimate. I get an immediate response when mail delivery fails, can set how long I want resends to be done, and don't have to remember to change my gateway when I move from home to college and back. I have no reason to run out and buy a domain -- I don't have any reason to present a domain to the world.
        With all due respect, you're an idiot.

        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

      • I have no reason to run out and buy a domain -- I don't have any reason to present a domain to the world.

        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
        • I'm not aware of ANY MUA or MTA that will accept an IP address in the To: field.

          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

        • Atleast postfix is configurable to accept IP's, however, the correct form for the TO address then becomes user@[xxx.xxx.xxx.xxx]

          I very much doubt this works over IPv6, though.
      • Although I do mostly agree with your lament regarding admins taking the iron-fisted quick-fix approach, I do have to point out an inaccuracy. Email, SMTP specifically, was concocted with relaying mail as an integral *feature*. It was designed so that anyone on the network in the chain from the sender to the recipient (including any sporadically connected hosts) could spool the mail. Many Internet protocols are based on the idea of keeping everythign working by exploiting the benefit that it's all running
  • If you refuse to accept mail without a valid PTR record, and that lowers your user's spam... I'd say PTR records are important. I know most systems I set up check that PTR and A/CNAME records match each other as a first step in determining whether the connection is trustworthy or not. Of course, if everyone did this we might see spammers/crackers setting up technically valid but wholly useless PTR records. At which point, who knows?
  • by mnmn ( 145599 ) on Wednesday May 07, 2003 @01:39PM (#5902794) Homepage

    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.
    • by Zeriel ( 670422 ) <<gro.ainotrehta> <ta> <selohs>> on Wednesday May 07, 2003 @01:45PM (#5902876) Homepage Journal
      Doesn't your ISP have PTR records anyway, though? Even if it resolves to something like modem212-yourstate-yrcty.adelphia.com like my cable modem does, it's still a valid PTR record.

      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).
    • Then your solution would be to send your outgoing mail through your ISPs mail server.

      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.
  • I should be allowed to send mail from my own connection and not have to worry about my isp crapping out on me (which happens, from time to time). if I run it from my own place, I know whether the mail server is fscked up or not.
  • ...except its nearly impoosible to set one up when you only have a single IP for your domain...
    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
    • It most definitely works. Here's how.

      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.
      • First off, you can't put inverse zone records (PTRs) in the same zone files as A and MX records.

        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
      • 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.

        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

        • My PTR is a long simple name ( foo-bar-baz.nycap.rr.com or something ) but my domains are registered with another registry.

          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.)
          • But the mail system sitting behind NAT may have no way of knowing what that is... many of the reverse names are foo-12.xx.yy.zz.nycap.rr.com or something along those lines. If the NAT box gets assigned a new IP, the name changes and the mailer may have no way of getting that information.
            • Okay, but you've already got a script which watches for IP changes to update the non-canonical hostname, right? So add a few lines to the script to get the canonical hostname for the new IP, write it into the postfix.conf file (or whatever its called) then kill -HUP postfix. I bet this is even a problem someone else has already solved but there's a good chance that writing your own is easier than finding someone else's.
    • If you got 256 addresses with your broadband connection, how much more would that be worth?

      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.
  • You can find a small discussion of the topic on the Missouri Linux Users group - See this for a sample [missouri.edu] and just look for the "More spam" subject messages.

    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.

    • 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.

      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

      • If _YOUR_ mailserver can not get YOUR email out, who's problem is it?

        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...

  • by Sevn ( 12012 )
    I know I've never taken anyone seriously that can't
    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. :)
    • Chances are it's joe cablemodem user with his Win2k server

      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.

      • Win2K DNS has a simple check box

        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).

      • Joe cablemodem user can set up a dns server and
        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)

    by Anonymous Coward on Wednesday May 07, 2003 @01:48PM (#5902907)
    Wouldn't it be better for mankind if all mail servers refused mail from non-resolvable IPs?

    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.
    • by Deagol ( 323173 ) on Wednesday May 07, 2003 @01:58PM (#5903019) Homepage
      The purpose of email is to facilitate communication. That's it.

      The same was once thought of having open relays, too. See how we changed out behavior with those?

      • by Anonymous Coward
        The same was once thought of having open relays, too. See how we changed out behavior with those?

        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
        • Most e-mail clients I use provide the ability to use multiple sets of e-mail settings...Eudora 5.x (which I use) and IIRC Outlook both do this.
        • Both Mac OS X and Mac OS classic provide locations which do, in fact, take care of this issue. Make a new location, swap one setting, and all your network settings change between sets.

          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
    • Now, in my opinion the correct way to deal with spam is to filter it on the receiving end.

      Spoken like someone who doesn't get much spam, and doesn't pay for traffic.

    • Your analogy of email to postal mail is flawed.

      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.
      • by Anonymous Coward
        "What if the post office refused to deliver any mail that did not have a correct return address on it."

        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
      • If this is true, which I don't believe it is, then please provide the location of the post office doing this. I will happily report it to the postmaster general for you.

        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.
    • 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.

      Apply that paragraph to the postal mail service. So, if someone sends you anthrax, or a rod of plutonium, then the po
    • While I agree with what you are saying philosophically, I try to keep my feet planted in the real world. Spam generates costs that innocent people have to pay, and any scheme where the victims have to pay for the crimes of the guity is broken. To me that has a higher value than the goal of perfect communication.

      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
    • Now, in my opinion the correct way to deal with spam is to filter it on the receiving end. All mail should be delivered,

      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
    • I might not understand your point correctly, but... if I do, then:

      By your rationale, shouldn't RBLs and the like quit blacklisting an entire /24 when only a /28 or /29 is offending us with spam? I can think of a few who do.

      Just curious. :-)

      -sid
    • The purpose of email is to facilitate communication. That's it.

      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
    • Your examples are very arbitrary. The idea behind only accepting correctly resolving mail is that it makes it much more difficult to pretend to be from, say, hotmail when you're not. You have to have access to both forward and reverse mapping to fake it.

  • DUCK! QUICKLY (Score:5, Interesting)

    by wowbagger ( 69688 ) * on Wednesday May 07, 2003 @01:55PM (#5902982) Homepage Journal
    You have suggested limiting Mr. 31337's ability to send any email he wants from his ub3rb0x3n without doing any real setup, like getting a proper reverse lookup established.

    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.
  • Yes, it has (Score:5, Informative)

    by linuxwrangler ( 582055 ) on Wednesday May 07, 2003 @01:56PM (#5903004)
    ...has the world become too lazy to make email delivery, easier?

    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.

  • Comment removed based on user account deletion
    • 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

  • 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

    • I think you just have to make sure the ptr record resolves to SOMETHING, not necessarily the same thing as the A record.

      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
      • 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!

    • Generally, it's considered desireable to have the DNS functional before getting the rest of the site up and running.

      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
      • Generally, it's considered desireable to have the DNS functional before getting the rest of the site up and running.

        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)

    by Deagol ( 323173 ) on Wednesday May 07, 2003 @02:16PM (#5903229) Homepage
    This topic has sparked much heated debate in the postfix mailing list. Two camps exist. The first is the stop-spam-at-all-costs group, and then there's the you-evil-bastard-that's-not-mandated-by-rfc crowd.

    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.

    • Do you or anyone know of tutorials on setting up basic rules like this in postfix? I'm using postfix for my personal mail server (hosted on a static IP, but with reverse lookup pointing to the ISP, not my domain), but it's been so long since I set it up I don't remember how the configuration file works. I recall it took forever to read through the standard docs, so I was wondering if there's a refresher tutorial just for setting up DNS-based restrictions like these.
      • I don't have the link, but search for the homepage of Ralph Hillendrandt (possible mis-spelling). He's a postfix guru who frequently posts to the postfix list. His homepage is chock full of sample configs.

        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.

    • Any chance you have details on your efforts posted somewhere? I'd appreciate seeing them. Thanks in advance.

      -sid
  • 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

    • Spam and worms are so commonplace because of the greed and incompetence of the really big ISPs.

      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
      • You're completely correct. The real victims here are the smallish ISPs, where the founder is still the chief tech, and the company has like 20 employees total. That's why I'm a proud cape.com [cape.com] subscriber. Not the cheapest on Cape Cod, but the service is worth it and they're an all open-source shop to boot. I much prefer giving my money to cape.com than Verizon or Earthlink.
    • Most ISPs really don't block spam, only a few say they do. If they do, I don't know where they do *looks at his Hotmail email box with 400 spams*, and I get an average of 50-90 spam's a day on my ISP's email.

      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.
  • by Harik ( 4023 )
    Any site sending me mail without reverse DNS gets a temporary failure error message. Further, any claimed 'From' address with a non-resolvable domain (A or MX) such as 'adfgsadgh@asdkabm.com' gets bounced as well.

    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

  • If you got rid of PTR, that would hang your PL and MRY records out to dry.
  • by Ashurbanipal ( 578639 ) on Wednesday May 07, 2003 @03:18PM (#5903934)
    Why not just refuse all messages that come from IP addresses that include the number 68?

    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)

    by n1k0 ( 553546 )
    This isn't an all-inclusive list of reasons for people's DNS habits, but in my experience these factors seem to be among the most prominent.

    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
  • You should have a reverse DNS PTR entry for all your mail servers. You don't have to follow the RFC but then you wouldn't be following standard behavior. In this case it's a good standard behavior to follow so I don't see why people don't follow it. My mail servers will not accept mail if there is no reverse DNS entry, if I can't hold the admin of that mailserver responsible for sending me UCE or for any other problems that might cause me time and headache why bother accepting the mail in the first place. O
    • I understand why you do this and completely agree.

      I would do they same, but I believe this causes problems for people with only 1 ip address.
      • That doesn't matter.. even dynamic ip's have ptr records assigned by ISP for whatever block. I didn't say I block mail based on isp just if it doesnt' have a reverse pointer so I don't know what 1 ip address really has to do with it. 1,2,200 it doesn't matter.
        • I am no expert(not even close), but I thought one couldn't create the reverse config file, DNS wasn't designed to do that. I am thinking of a person running a dns server off a cable modem and such.

          Thank again, I could be wrong and misunderstood what I read.
          • Lets say you have your cable modem and you enter and execute the command "host xxx.xxx.xxx.xxx" where the xxx octects are filled with your ip number. What is returned is the PTR to that ip which would be your domain name assigned to that ip, which probably looks something like cablemodemxxx-xxx-xxx-xxx.isp.net.

            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'
  • I run a mail server for several domains, and several dozen users. Here is what I've learned:

    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
  • I know this isn't a debate over various mail servers, but Matt Simerson's qmail-based "mail toaster" [simerson.net] just added checks against several a bunch of open-relay blacklists and reverse-DNS lookup against the sender's "From" field as options in the build script.

    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

BLISS is ignorance.

Working...