Slashdot Mirror
Are PTR Records Important?
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?"
They are certainly just as important as TPS reports, if not more so.
Have you sent a memo?
"I only speak the truth"
Karma: null(Mostly affected by an unassigned variable)
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!
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?
"America has done some terrible things. But I know that Americans don't cheer when innocents die." -Dave Barry
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.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
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 DNS server to reverse map me correctly...I've tried...
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
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.
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.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
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.
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.
www.eFax.com are spammers
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.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
...considering I just finished setting up PTR records for all 172 of our domain names. It's not at all difficult, and it doesn't exactly take up a lot of time.
Actually, I didn't even know they were "optional" (if not in the standard then in practice). Oh, well... I guess that makes me a responsible net. admin.?
While I'm talking about DNS, since this is my first go at it, what is this "@" sign that I see in example db.domain files?
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.
www.eFax.com are spammers
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. And there's going to be a lag where some will get through and some won't as the DNS propogates.
Now, I can make sure that all the right things are happening, but everyone would feel 100% better if mail could get out to, say, the Chairman of the Board and he could say "ah, I got the test message, all is well." And the lag while the DNS updates is more worrisome.
It's entirely possible I'm missing some obvious way around this (google is my friend today), but this situation can't be uncommon, and I'm sure there are many similar situations in which entirely legitimate mail is being sent from an IP that can't be resolved in a reverse lookup.
This is the voice of World Control. I bring you Peace.
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.
Method of processing duck feet
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 ONLY because the PTR record is bunk. Plug this into SpamAssassin and MAYBE you've got a workable solution. Do this for 24 months ot so, and only then starting blocking the suckers with bad PTRs.
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.
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 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.
People requiring PTR records are running broken name servers. Most people that like this mindset -- restrict users for a short term gain -- have in my experience been fairly technically incompetent admins. Block everything except 80 TCP outbound, plop transparent proxies all over, try to convince people to use webmail, block mailservers...they see a short term gain. They aren't engineers, so to them, they've just "solved the problem". Then they wait a year, run into problems (people tunneling everything over 80 or setting up their own VPNs to get reasonable functionality, FTP to a similarly crippled site not working, etc), and try to find a policy-based, rather than a technical, solution. For the rest of the world, they're jerks with a bit of administrative power to abuse. IT people like this are easy to find -- they're the ones that the users resent, the ones that are making tasks more of a pain in the ass for core users, rather than easier.
Just my two cents.
May we never see th
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.
A solution to the problem with music today
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 reverse DNS records, so I only get the occasional complaint.
--Dan
If you got rid of PTR, that would hang your PL and MRY records out to dry.
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
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, "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...
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 you read Cricket Liu's book "DNS and Bind in a Nutshell" before you start giving people DNS advice.
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 legit email out in a reasonable amount of time.
By the same token, the USPS is doing it's job by not accepting bombs in the mail. Despite "The mail must go through!" motto, some things don't qualify.
--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 resolvable domain at the helo/ehlo. But, the really big question is: How do you then receive email without a gateway or a domain? How do your buds send email to you? Do they enter to: 1337@65.31.97.241?
I'm not aware of ANY MUA or MTA that will accept an IP address in the To: field. If your response is going to be that, you set the Reply to: field to your Yahoo account, then you are the type of person who's mail I am intentionally trying to avoid.
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 flat rate, but the French have to pay for all calls, even local ones. This ment that it was money out of my pocket to download and trash spam. That sucks big time, and it is unfair. Part of the implied social contract is that only things of interest should be sent. I understand that there are grey areas, but basically anything that has no chance of interesting me is abusive when it is on my nickel. How would you like to pay for the pleasure of getting telemarkerters? People outside the US often pay for the joy of spam, and that is pure bullshit.
Equally unfair is the companies that have to buy more resorces (bandwidth, storage, etc) to manage the flow of spam. Why should they have to spend a single cent for someone to send spam?
- doug
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 only a few IPs in a subnet. ISPs have varying degrees of friendliness for managing reverse DNS through customer support personnel or a website. For organizations that update DNS often, sometimes it isn't worth the hassle of dealing with the ISP at all.
3) People are lazy and stupid, and reverse DNS doesn't typically affect our daily lives. Most yahoos barely understand DNS beyond pointing and clicking in the Microsoft DNS Server Console (which, ironically, will automatically update PTRs when you make changes to forwards if you so desire). These would be the same schmucks who list CNAMEs as mail exchangers.
The moral of the story is: The number of legitimate email providers with invalid reverse DNS far outnumbers the number of spammers. This is ample reason to NOT refuse to accept mail that has inconsistent forward and reverse mappings.
Consider your business customers; are they going to care about fighting spam when they can't receive email from contacts at other companies? Are they going to want to hear, 'Well tell the person that's trying to email you to fix their server'? I think not.
It would be much different if you weren't an ISP, but I don't feel that the annoyance presented by spam is sufficient reason to effectively tell your customers that they can no longer receive email from a fair percentage of Internet hosts because there's a small chance that they might be spammers. There are effective ways to fight spam that don't inhibit the users' ability to receive legitimate email.
-Nick
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 are the problem. They will NOT cut off a paying customer's access regardless of how obviously the customer is abusing that access - instead, they are tracking down people running private websites and NNTP nodes, because they want to be content providers and they don't like competition.
I get 6-700 worm attacks a week on my cable modem at home - all identified by snort and stopped by iptables. All cable modem addresses are VLANS. The cable company can easily monitor them from a central point, and these are mostly KNOWN, EASILY IDENTIFIED worm spoor.
The big ISPs are the biggest part of the problem because:
#1 - they don't care about quality of service as long as they get their money
#2 - they have regional monopolies
#3 - they refuse to co-ordinate with each other
Solve these problems and the Internet will start working properly again.
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. One less headache for me.
Obviously, they're part of the problem!
If you don't think spam is a problem, you're one of four things:
- Too new to have your email harvested.
- Someone with damm good email filtering.
- An idiot.
- A spammer.
Try carrying out a conversation where the person you are talking to is speaking at 1/5th the volume of the used-car salesman with a megaphone. Freedom of speech also means being able to listen to the person you want to and not have him drowned out.And as problem/solution goes, the thousand odd people I provide email accounts for are quite happy with the improvement of the quality of their service. If you wish to try to tell them how wrong they are, feel free to buy an email list and spam them. They pay me to make sure that your attempts fail.
Yesterday was slow: 66637 connections rejected for being spam. Generally that's about 10-15 emails each (judging from the logs of the ones that did get in) By the same token, there were 15574 emails delivered successfully, quite a few of which were spam that got through the filter.
This means that over 81% of all email traffic going to me was spam. Still not a problem?
--Dan
This isn't the wild west. You don't just pick an IP address out of your ass, and twiddle random bits in packets and say "Hi! I'm sending email you must accept it because I'm so COOL!". There's a number of things you have to do, and it's all about being a responsible member of the internet community. As times change, so do the accepted best practices. This is why we don't relay mail for anyone anymore, because it's considered rude to let thugs use your house as a base to rob others.
No, you're someone who dosn't even respect his own position enough to commit his name to it. This just stinks of spammers, who hardly ever use their real name. The only reason I'm even replying is that you have some grasp of the english language, which most ACs do not. Not really. It's the difference between being allowed to talk to yourself in a closet and stand on common ground and tell other people what you believe. If we said "you can say anything you want, as long as nobody can hear you." how free is that? Either way, it's a side issue. The government isn't involved in this (yet).I get what you're saying, it's just wrong. See, most spam comes from open relays or proxies. People who run those servers are directly contributing to spam. Why should I accept mail from a willing spammer accomplice? It's not THAT hard to lock down open relays. I've even got a box on my network that has to exist that has no anti-relay capabilities (UGH).... So I divert all inbound 25 traffic through a sendmail box first.
If someone isn't willing to do their part to keep email a viable medium for communications, I'm not willing to listen to them. Is it such a hard concept?
As for valid email from proxies/relays: No email should be coming out of a proxy server, open or otherwise. It's a hardware box, no mail queue, designed to cache webpages. Any email coming out of it is spam, period. For relays: While someone may be using the mailserver for legit mail, trust me. Once the spammers find it that box is so slammed with spam it crashes and takes out any real email that would be going through it.
You're amazing. Truly amazing. Your tenacity for not giving up your ideas is phenominal.
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 they're not?
A) They're lazy
B) they don't know about PTR records, which means they probably don't know enough to run a mail server
C) They're thickheaded like you and think that when their friends (other friendly mail server admins) ask them nicely to behave civilly (set up PTR records) they're being forced to do something against their will, and they won't have any of that!
You seem to fall into the C) category. And this is your problem: Even though we're giving you good advice, you're ignoring it cause it's not your own.
I sincerely hope you don't run a mail server of any consequence.
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 rejected mail we shouldn't have because their TTLs were short enough that cached records were expired.
We also noticed that many spammers use either improperly configured mail servers, trojaned/hacked dynamic hosts, or temporary accounts (increasingly rare). This accounts for about 95% of spam we receive, and most of it is from hosts with PTRs - cable modems, DSL customers, and mail servers for real users. The other 5% is easily blacklisted.
We found that a more effective solution was to reject mail based on the From sender's domain rather than PTR record. If the domain is unresolvable, it gets rejected. If you run sendmail, making sure that FEATURE(`accept_unresolvable_domains') is commented out is sufficient to do this. This can suffer from the problem with failed lookups as well.
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 of BIND, djdns,
etc. up and running. Also, from extensive industry
experience, it's been my observation that most
shops running Microsoft DNS are small, don't set
their reverse correctly, and don't care because
they aren't doing anything that important or
they'd use a better platform. No trolling
intended at all. It's how things pan out when you
have a Microsoft person attempt to manage a
traditional UNIX service.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
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 give it a look.
"It was a summer's tale: Just a boy, his Linux, and a head full of dreams..."
Actually, IPX _doesn't_ run over SLIP.
I want to delete my account but Slashdot doesn't allow it.
Pain is merely failure leaving the body