Re: Reverse DNS lookups
FYI, my ISP did add the reverse PTR records last night. I appreciate the suggestion from Andreas to get RIPE involved. I think it was my email to RIPE, cc'ing my ISP, that was the key to making this happen. I am really under ARIN, not RIPE. However, my ISP is expanding into Europe, so I thought my ISP would be sensitive to RIPE. Thanks for all of the feedback. >From: Andreas Grip <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Reverse DNS lookups >Date: Tue, 10 Jul 2001 15:44:36 +0200 > >I had problems to get my ISP to setup reverse DNS on my IP:s but then I >turned to RIPE and they sended an e-mail to my ISP. The day after that >the reverse was working :-) > >So maybe you should try go through RIPE... > >Andreas _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Reverse DNS lookups
This was the best advice! I emailed RIPE and cc'd my ISP, then called my ISP to make sure they saw my email to RIPE. My ISP just emailed me to say that my PTR records would be put on their DNS servers tonight at midnight. I don't know if RIPE emailed them, but I think my ISP didn't want to risk being on any possible "nonconforming ISP" lists. Before I sent the email to RIPE, I also called the Internic, but they told me that I would have to change to an Internic sponsored ISP to get PTR records. I'll see if my ISP actually did it tomorrow, but it was terrific to have an authority like RIPE on my side. After all, I did pay for that IP address block. The least they can do is put both A and PTR records in their DNS servers. >From: Andreas Grip <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Reverse DNS lookups >Date: Tue, 10 Jul 2001 15:44:36 +0200 > >I had problems to get my ISP to setup reverse DNS on my IP:s but then I >turned to RIPE and they sended an e-mail to my ISP. The day after that >the reverse was working :-) > >So maybe you should try go through RIPE... > >Andreas _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Reverse DNS lookups
I had problems to get my ISP to setup reverse DNS on my IP:s but then I turned to RIPE and they sended an e-mail to my ISP. The day after that the reverse was working :-) So maybe you should try go through RIPE... Andreas
Re: Reverse DNS lookups
You're right, I knew I was overlooking something. My IP addresses are part of the ISP address range. >From: Frank Tegtmeyer <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Reverse DNS lookups >Date: 10 Jul 2000 08:45:56 +0200 > >"pop corn" <[EMAIL PROTECTED]> writes: > > > 2) If they don't add reverse PTR records for my virtual domains, I've > > been debating telling the Internic to change my DNS servers for the > > virtual domains to the base address of my own dedicated server. It's > > not as if my virtual domains are subdomains of my ISP's domain. The > > problem is that I only have the one dedicated machine. > >No, that's not the problem. The in-addr.arpa zones for your addresses >are delegated to your ISP. *You* never get the chance to provide data >for them until your ISP > >a) provides the date itself or >b) delegates the zones for your addresses to you > >Regards, Frank _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Reverse DNS lookups
Wrong mailing list, my apologies, I meant to send this to [EMAIL PROTECTED] >From: "pop corn" <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Reverse DNS lookups >Date: Tue, 10 Jul 2001 06:07:59 - > >I'm dealing with a new ISP that has been pretty much ok until this problem. >I realized that they didn't set up the reverse PTR records for my eight IP >addresses on a dedicated server. (I will be creating 8 virtual domains - >one >per IP address). > >Their staff initially said 1) reverse PTR records were never necessary; 2) >delegating my DNS info to my machine are out of the question (they won't >admit they don't know how and they won't accept info). They are using BIND >and insist that nslookup is never capable of returning the domain name for >a >given IP address. > >I've been pounding on them since last week, and just got an email saying >that a PTR record is only necessary for the base IP address of the 8 >addresses (the hostname is set to this base IP address) and they are going >to update their DNS server tonight and promptly closed out the trouble >ticket. > >I've been setting up DNS (classic BIND) for years and simply never heard of >setting up A records without the associated PTR record for reverse address >mapping. > >1) I'm about to open up another trouble ticket to ask them to add PTR >records for the remaining seven IP addresses. Am I not correct in telling >the ISP that all my virtual domains require reverse DNS resolution? > >2) If they don't add reverse PTR records for my virtual domains, I've been >debating telling the Internic to change my DNS servers for the virtual >domains to the base address of my own dedicated server. It's not as if my >virtual domains are subdomains of my ISP's domain. The problem is that I >only have the one dedicated machine. The Internic wants two DNS servers per >domain. If I leave the existing DNS servers from my ISP, and add my own >dedicated server as a third DNS server, will the reverse address search go >through all three of my DNS servers until it has success? > >My hostname is a subdomain of my ISP's domain, so the PTR record for my >base >address will have to be served by my ISP's dns server and they are in fact >doing that for me tonight. > >My virtual domains are independent domains immediately under .com and >registered to the Internic. I'll use the exact same IP addresses that my >ISP >was serving on their DNS servers, just add the reverse DNS info. My ISP's >info about my virtual domains will just be ignored once the Internic makes >the change, right? I've been resisting this route because I don't want to >create a loop of some kind. > >3) If I proceed with step 2, I could use dnscache on 127.0.0.1, tinydns on >one IP, and walldns on another IP, right? It doesn't matter which external >IP, just so long as they are different IPs because dnscache, tinydns, and >walldns are all looking at port 53, right? > >There is no firewall with this solution in 2) and 3), but these virtual >domains don't have any national secrets anyway. However, I will be serving >qmail to these domains, so it won't be the safest environment for the >email. > >I'm sorry this post is so long, it's hard for me to verbalize these DNS >issues succinctly. > > >_ >Get your FREE download of MSN Explorer at http://explorer.msn.com > _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Reverse DNS lookups
On Tue, Jul 10, 2001 at 06:07:59AM -, pop corn wrote: > Their staff initially said 1) reverse PTR records were never necessary; Hell. Did you really say they call themselves an ISP? Uh-oh. -- * Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de * * Roedingsmarkt 14, 20459 Hamburg, Germany * Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: Reverse DNS lookups
"pop corn" <[EMAIL PROTECTED]> writes: > 2) If they don't add reverse PTR records for my virtual domains, I've > been debating telling the Internic to change my DNS servers for the > virtual domains to the base address of my own dedicated server. It's > not as if my virtual domains are subdomains of my ISP's domain. The > problem is that I only have the one dedicated machine. No, that's not the problem. The in-addr.arpa zones for your addresses are delegated to your ISP. *You* never get the chance to provide data for them until your ISP a) provides the date itself or b) delegates the zones for your addresses to you Regards, Frank
Reverse DNS lookups
I'm dealing with a new ISP that has been pretty much ok until this problem. I realized that they didn't set up the reverse PTR records for my eight IP addresses on a dedicated server. (I will be creating 8 virtual domains - one per IP address). Their staff initially said 1) reverse PTR records were never necessary; 2) delegating my DNS info to my machine are out of the question (they won't admit they don't know how and they won't accept info). They are using BIND and insist that nslookup is never capable of returning the domain name for a given IP address. I've been pounding on them since last week, and just got an email saying that a PTR record is only necessary for the base IP address of the 8 addresses (the hostname is set to this base IP address) and they are going to update their DNS server tonight and promptly closed out the trouble ticket. I've been setting up DNS (classic BIND) for years and simply never heard of setting up A records without the associated PTR record for reverse address mapping. 1) I'm about to open up another trouble ticket to ask them to add PTR records for the remaining seven IP addresses. Am I not correct in telling the ISP that all my virtual domains require reverse DNS resolution? 2) If they don't add reverse PTR records for my virtual domains, I've been debating telling the Internic to change my DNS servers for the virtual domains to the base address of my own dedicated server. It's not as if my virtual domains are subdomains of my ISP's domain. The problem is that I only have the one dedicated machine. The Internic wants two DNS servers per domain. If I leave the existing DNS servers from my ISP, and add my own dedicated server as a third DNS server, will the reverse address search go through all three of my DNS servers until it has success? My hostname is a subdomain of my ISP's domain, so the PTR record for my base address will have to be served by my ISP's dns server and they are in fact doing that for me tonight. My virtual domains are independent domains immediately under .com and registered to the Internic. I'll use the exact same IP addresses that my ISP was serving on their DNS servers, just add the reverse DNS info. My ISP's info about my virtual domains will just be ignored once the Internic makes the change, right? I've been resisting this route because I don't want to create a loop of some kind. 3) If I proceed with step 2, I could use dnscache on 127.0.0.1, tinydns on one IP, and walldns on another IP, right? It doesn't matter which external IP, just so long as they are different IPs because dnscache, tinydns, and walldns are all looking at port 53, right? There is no firewall with this solution in 2) and 3), but these virtual domains don't have any national secrets anyway. However, I will be serving qmail to these domains, so it won't be the safest environment for the email. I'm sorry this post is so long, it's hard for me to verbalize these DNS issues succinctly. _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: reverse DNS?
On Thu, Mar 08, 2001 at 08:52:27AM -0600, Charles Cazabon wrote: [snip] > > It would be a violation of RFC 1123, which states: > [...] > > The HELO receiver MAY verify that the HELO parameter really > > corresponds to the IP address of the sender. However, the > > receiver MUST NOT refuse to accept a message, even if the > > sender's HELO command fails verification. > > Interesting; I have never agreed with refusing email based on the DNS > of the HELO or envelope sender, but didn't realize that (at least for HELO) > it was actually verboten. > > In real life, of course, there are thousands of domains which do this every > day. I actually had fights (over e-mail, luckily) with someone using a VAX/VMS mailer with lots of anality knobs. He had several complaints about my qmail boxes. I convinced him to turn off all knobs that rang alarms whenever one of my boxes mailed him. The HELO was indeed one of these. Greetz, Peter.
Re: reverse DNS?
Jenny Holmberg <[EMAIL PROTECTED]> wrote: > > > As a matter of policy, is it reasonable to reject messages that fail a > > > reverse DNS lookup on HELO's FQDN/authentication? > > > > Very political question. As long as you don't reject envelope senders of > > <> and <#@[]>, you won't be violating any RFCs. > > It would be a violation of RFC 1123, which states: [...] > The HELO receiver MAY verify that the HELO parameter really > corresponds to the IP address of the sender. However, the > receiver MUST NOT refuse to accept a message, even if the > sender's HELO command fails verification. Interesting; I have never agreed with refusing email based on the DNS of the HELO or envelope sender, but didn't realize that (at least for HELO) it was actually verboten. In real life, of course, there are thousands of domains which do this every day. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: reverse DNS?
Charles Cazabon <[EMAIL PROTECTED]> writes: > John Conover <[EMAIL PROTECTED]> wrote: > > As a matter of policy, is it reasonable to reject messages that fail a > > reverse DNS lookup on HELO's FQDN/authentication? > > Very political question. As long as you don't reject envelope senders of > <> and <#@[]>, you won't be violating any RFCs. It would be a violation of RFC 1123, which states: 5.2.5 HELO Command: RFC-821 Section 3.5 The sender-SMTP MUST ensure that the parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter. The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification. It's still OK to deny a non-syntactically-correct HELO, though. -- "I live in the heart of the machine. We are one."
Re: reverse DNS?
Erwin Hoffmann <[EMAIL PROTECTED]> writes: > Hi, > > I dont know, whether the HELO/EHLO from the MTA-Client means anything and > whether it can be used for a reverse DNS lookup. > > However, it makes sense to do DNS lookup für the MAIL FROM: address. > > This is alrady feasable by some qmail patches, including my SPAMCONTROL. > Have a look at: > > http://www.fehcom.de/qmail_en.html It's not unreasonable to insist that that address be valid (including <> and such). I dont' think it's particularly *useful* for spam control either, though; most spam comes with forged by "valid" return addresses. By insisting that spammers do that, all we're doing is forcing them to pick some unlucky sysadmin to get the torrent of abuse and bounces. So the spam doesn't get blocked, *and* some innocent victim is hurt. No profit there! -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: reverse DNS?
So, in my request for opinions, pls., some/most/many admins would like to refuse messages from non-local machines that do not have a valid RDNS for the HELO FQDN, but feel such a policy is inappropriate from the user's POV. I have a lot of users that have a common ~/.procmailrc, (mostly spam, MS/Outlook frailties, stuff-its an ln -s from my ~/.procmailrc,) and many of them agreed to participate in letting me put a header record "Sending-Machine: unknown" in such messages-as opposed to refusing to process the message. We'll see how it goes for a month, or so, and see how many messages would have been refused by such a policy, vs. how many should have been refused. Thanks to all for the opinions, John Erwin Hoffmann writes: > Hi, > > At 09:49 7.3.2001 +, James R Grinter wrote: > >Erwin Hoffmann <[EMAIL PROTECTED]> writes: > >> However, it makes sense to do DNS lookup f=FCr the MAIL FROM: address.=20 > > > >If you have reliable DNS services - I've been on the other end of > >that, a site permanently rejecting each mail (a 5xx code) because they > >were having problems resolving the sending domain. Delegation and the > >nameservers were fine, as it was the second address I tried (which > >also failed with a 5xx code) > > > >Very messy, and not very good for their customers. > > > >James. > > In particular to cope with this, my implementation lets you define for > which Domains you dont want DNS Reverse Lookup: /var/qmail/control/nodnscheck. > SPAMCONTROL does a logging on that, thus you easily can figure out, which > Domains cause the problem. > > > cheers. > eh. > > +---+ > | fffhh http://www.fehcom.deDr. Erwin Hoffmann | > | ff hh| > | ffeee ccc ooomm mm mm Wiener Weg 8 | > | fff ee ee hh hh cc oo oo mmm mm mm 50858 Koeln| > | ff ee eee hh hh cc oo oo mm mm mm| > | ff eee hh hh cc oo oo mm mm mm Tel 0221 484 4923 | > | ff hh hhccc ooomm mm mm Fax 0221 484 4924 | > +---+ -- John ConoverTel. 408.370.2688 [EMAIL PROTECTED] 631 Lamont Ct. Cel. 408.772.7733 http://www.johncon.com/ Campbell, CA 95008 Fax. 408.379.9602
Re: reverse DNS?
Hi, At 09:49 7.3.2001 +, James R Grinter wrote: >Erwin Hoffmann <[EMAIL PROTECTED]> writes: >> However, it makes sense to do DNS lookup f=FCr the MAIL FROM: address.=20 > >If you have reliable DNS services - I've been on the other end of >that, a site permanently rejecting each mail (a 5xx code) because they >were having problems resolving the sending domain. Delegation and the >nameservers were fine, as it was the second address I tried (which >also failed with a 5xx code) > >Very messy, and not very good for their customers. > >James. In particular to cope with this, my implementation lets you define for which Domains you dont want DNS Reverse Lookup: /var/qmail/control/nodnscheck. SPAMCONTROL does a logging on that, thus you easily can figure out, which Domains cause the problem. cheers. eh. +---+ | fffhh http://www.fehcom.deDr. Erwin Hoffmann | | ff hh| | ffeee ccc ooomm mm mm Wiener Weg 8 | | fff ee ee hh hh cc oo oo mmm mm mm 50858 Koeln| | ff ee eee hh hh cc oo oo mm mm mm| | ff eee hh hh cc oo oo mm mm mm Tel 0221 484 4923 | | ff hh hhccc ooomm mm mm Fax 0221 484 4924 | +---+
Re: reverse DNS?
Erwin Hoffmann <[EMAIL PROTECTED]> writes: > However, it makes sense to do DNS lookup f=FCr the MAIL FROM: address.=20 If you have reliable DNS services - I've been on the other end of that, a site permanently rejecting each mail (a 5xx code) because they were having problems resolving the sending domain. Delegation and the nameservers were fine, as it was the second address I tried (which also failed with a 5xx code) Very messy, and not very good for their customers. James.
Re: reverse DNS?
Hi, I dont know, whether the HELO/EHLO from the MTA-Client means anything and whether it can be used for a reverse DNS lookup. However, it makes sense to do DNS lookup für the MAIL FROM: address. This is alrady feasable by some qmail patches, including my SPAMCONTROL. Have a look at: http://www.fehcom.de/qmail_en.html cheers. eh. At 01:29 7.3.2001 -0500, Peter Cavender wrote: >> At 10:07 AM 06-03-2001 -, John Conover wrote: >> >As a matter of policy, is it reasonable to reject messages that fail a >> >reverse DNS lookup on HELO's FQDN/authentication? >> >> Well two of our service providers haven't arranged reverse DNS lookups for >> our Internet visible subnets. Our DNS servers are ready, but they either >> don't want to do it or don't know how to do it. So you can't look up names >> from our IPs. And it's been more than a year already. >> >> So I'm biased and I'd say it's not reasonable ;). >> >> Why would you want to do that anyway? > >Spam prevention. Have had the same problem myself. It is indeed sad that >we have to jump through these hoops because a few folks insisting on >emailing everyone about their inkjet refills or lower mortgage rates >necessitate this. > >> Cheerio, >> Link. > > > +---+ | fffhh http://www.fehcom.deDr. Erwin Hoffmann | | ff hh| | ffeee ccc ooomm mm mm Wiener Weg 8 | | fff ee ee hh hh cc oo oo mmm mm mm 50858 Koeln| | ff ee eee hh hh cc oo oo mm mm mm| | ff eee hh hh cc oo oo mm mm mm Tel 0221 484 4923 | | ff hh hhccc ooomm mm mm Fax 0221 484 4924 | +---+
Re: reverse DNS?
> At 10:07 AM 06-03-2001 -, John Conover wrote: > >As a matter of policy, is it reasonable to reject messages that fail a > >reverse DNS lookup on HELO's FQDN/authentication? > > Well two of our service providers haven't arranged reverse DNS lookups for > our Internet visible subnets. Our DNS servers are ready, but they either > don't want to do it or don't know how to do it. So you can't look up names > from our IPs. And it's been more than a year already. > > So I'm biased and I'd say it's not reasonable ;). > > Why would you want to do that anyway? Spam prevention. Have had the same problem myself. It is indeed sad that we have to jump through these hoops because a few folks insisting on emailing everyone about their inkjet refills or lower mortgage rates necessitate this. > Cheerio, > Link.
Re: reverse DNS?
At 10:07 AM 06-03-2001 -, John Conover wrote: >As a matter of policy, is it reasonable to reject messages that fail a >reverse DNS lookup on HELO's FQDN/authentication? Well two of our service providers haven't arranged reverse DNS lookups for our Internet visible subnets. Our DNS servers are ready, but they either don't want to do it or don't know how to do it. So you can't look up names from our IPs. And it's been more than a year already. So I'm biased and I'd say it's not reasonable ;). Why would you want to do that anyway? Cheerio, Link.
Re: reverse DNS?
> John Conover writes: > > As a matter of policy, is it reasonable to reject messages that fail a > > reverse DNS lookup on HELO's FQDN/authentication? > > No. Indeed. Nevertheless, I think some elaboration will make the following answers easier to understand to less experienced mail managers. > Neither is it reasonable to reject messages from a host whose reverse > DNS hostname lacks an MX record. For instance, if a sending machine is only known to an organization's internal name servers, but somehow its hostname is used in outgoing messages, is it reasonable to block it? I would like to :>, but in fairness, I can't :( > > Neither is it reasonable to reject messages from a host which isn't > running an SMTP server. Some organizations run incoming mail server(s) and outgoing mail server(s). The later often do not run SMTP. But they do send out messages. Can you block them, no. > > Although I've been sorely tempted to implement both of these. 8-) Likewise. I wish I could, it would make spam filtering a much easier (if less fun :> job to do. Chin Fang [EMAIL PROTECTED] > -- > -russ nelson <[EMAIL PROTECTED]> http://russnelson.com > Crynwr sells support for free software | PGPok | Watch out! He's got an > 521 Pleasant Valley Rd. | +1 315 268 1925 voice | opinion, and he's not > Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | afraid to share it! >
Re: reverse DNS?
John Conover writes: > As a matter of policy, is it reasonable to reject messages that fail a > reverse DNS lookup on HELO's FQDN/authentication? No. Neither is it reasonable to reject messages from a host whose reverse DNS hostname lacks an MX record. Neither is it reasonable to reject messages from a host which isn't running an SMTP server. Although I've been sorely tempted to implement both of these. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Watch out! He's got an 521 Pleasant Valley Rd. | +1 315 268 1925 voice | opinion, and he's not Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | afraid to share it!
Re: reverse DNS?
John Conover <[EMAIL PROTECTED]> writes: > As a matter of policy, is it reasonable to reject messages that fail a > reverse DNS lookup on HELO's FQDN/authentication? > > Good idea? > > Fascist idea? > > Opinions pls. Do you relay for users running POP clients who send their outbound through you via smtp? Do you control the reverse DNS on the IPs they come in from? If "yes" and "no", then it's definitely a bad idea. (I'm assuming you're considering requiring only *some* reverse DNS, not one that matches what they HELO as?) -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: reverse DNS?
On Tue, Mar 06, 2001 at 10:07:46AM -, John Conover <[EMAIL PROTECTED]> wrote: > As a matter of policy, is it reasonable to reject messages that fail a > reverse DNS lookup on HELO's FQDN/authentication? I don't think this buys you much in the way of spam protection and can block legitimate email. Many dialup and dsl connections will have a reverse DNS entry in the service providers domain space. If you want to block dialups, you are probably better off using the DUL list to do it.
Re: reverse DNS?
John Conover <[EMAIL PROTECTED]> wrote: > As a matter of policy, is it reasonable to reject messages that fail a > reverse DNS lookup on HELO's FQDN/authentication? Very political question. As long as you don't reject envelope senders of <> and <#@[]>, you won't be violating any RFCs. However, you could reject legitimate mail due to temporary problems with connectivity of your machine or other organizations' DNS servers. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
reverse DNS?
As a matter of policy, is it reasonable to reject messages that fail a reverse DNS lookup on HELO's FQDN/authentication? Good idea? Fascist idea? Opinions pls. John -- John ConoverTel. 408.370.2688 [EMAIL PROTECTED] 631 Lamont Ct. Cel. 408.772.7733 http://www.johncon.com/ Campbell, CA 95008 Fax. 408.379.9602
Re: How to do a reverse DNS lookup in Qmail ?
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > If you use tcpserver (ucspi package), simply add the -p parameter to > tcpserver command line. This will force the "paranoid" mode and > tcpserver will do a reverse DNS check. This will force tcpserver to make sure the A and PTR records are a match. tcpserver does reverse lookups by default -- the -h and -H switches control this. In addition, setting -p only tells tcpserver to set a particular environment variable if the connection is deemed "paranoid." You need another switch to actually get it to reject the connection outright. This wasn't what he was asking about. He wants to reject connections, if I understand his english properly, that come from IP addresses that don't resolve to a name (reverse dns lookup). I think that's a bad idea. You didn't quote or attribute the message to which you were replying. Tisk -- this is a mailing list, after all. I'd be able to show better that you answered without understanding exactly what he meant. Aaron
Re: How to do a reverse DNS lookup in Qmail ?
Hy ! If you use tcpserver (ucspi package), simply add the -p parameter to tcpserver command line. This will force the "paranoid" mode and tcpserver will do a reverse DNS check. Regards, Chris.
Re: How to do a reverse DNS lookup in Qmail ?
Hi, you can use the MFCHECK patch from QMAIL's home page or my SPAMCONTROL patch which includes it. http://www.fehcom.de/qmail_en.html cheers eh. At 16:43 28.6.2000 +0545, Shashi Dahal wrote: >Dear All, > >Sorry for this question, but whenever my server accepts an incomming >connection, how do I set qmail to do a reverse dns lookup and reject the >mail if the sender domian does not exist. > > > >Thanks >Shashi Dahal. > > +---+ | fffhh http://www.fehcom.deDr. Erwin Hoffmann | | ff hh| | ffeee ccc ooomm mm mm Wiener Weg 8 | | fff ee ee hh hh cc oo oo mmm mm mm 50858 Koeln| | ff ee eee hh hh cc oo oo mm mm mm| | ff eee hh hh cc oo oo mm mm mm Tel 0221 484 4923 | | ff hh hhccc ooomm mm mm Fax 0221 484 4924 | +---+
How to do a reverse DNS lookup in Qmail ?
Dear All, Sorry for this question, but whenever my server accepts an incomming connection, how do I set qmail to do a reverse dns lookup and reject the mail if the sender domian does not exist. Thanks Shashi Dahal.
Re: Bouncing mail w/ no reverse DNS
On the qmail list [EMAIL PROTECTED] wrote: >Ah, but just because it comes from an open relay with a valid DNS entry >doesn't mean the "From:" address is valid. That's what the patch at >qmail.org checks, so it can bounce it to the original sender if it needs to. Ah OK. That's a pretty unassailable requirement. "In accepting a piece of mail I accept the RFC 821 "MUST" obligation to send an error message to the error address if for some reason I can't deliver it. I cannot resolve the error address; I cannot therefore at this time send an error message to the error address, and there is no reason to believe I will be able to do so in the future; I therefore cannot accept the obligation to send a message to that address in case of problems; therefore, I cannot accept your mail."
Re: Bouncing mail w/ no reverse DNS
Hi, I included the MAILFROM DNS check in my SPAMCONTROL patch. You can give it a try http://www.fehcom.de/qmail_en.html cheers. eh. At 15:13 14.6.2000 -0500, Sgt Chains wrote: >Forgive me if this is somewhere in the Docs, I can't find it. > >I would like to bounce inbound mail that comes in that can't resolve >reverse DNS. > >A lot of net admins out there have started to not setup DNS entries for >their dial-up accounts believing that this is a better approach than >registering w/ the MAPS/DUL list. > >Personally I don't agree... but I'm getting a lot of trespass spam via >non resolved DNS. > >Any ideas? > >--Larry >mailto:[EMAIL PROTECTED] > +---+ | fffhh http://www.fehcom.deDr. Erwin Hoffmann | | ff hh| | ffeee ccc ooomm mm mm Wiener Weg 8 | | fff ee ee hh hh cc oo oo mmm mm mm 50858 Koeln| | ff ee eee hh hh cc oo oo mm mm mm| | ff eee hh hh cc oo oo mm mm mm Tel 0221 484 4923 | | ff hh hhccc ooomm mm mm Fax 0221 484 4924 | +---+
RE: Bouncing mail w/ no reverse DNS
Ah, but just because it comes from an open relay with a valid DNS entry doesn't mean the "From:" address is valid. That's what the patch at qmail.org checks, so it can bounce it to the original sender if it needs to. The problem I was running into was that we'd get so much SPAM with an unresolvable From: header that was trying to be delivered to non-existant users on our system, that it would sit in the queue for a week while it was trying to bounce it back to that non-existant domain. Then after a week that would puke out and flood the MAILER-DAEMON or postmaster boxes with "but the bounce bounced!" messages. I pretty much got sick of it, and applied the patch, and I haven't been sorry. :) As long as everyone has their "From:" address configured correctly with their mail reader, there shouldn't be any problems. If people don't have that configured correctly, well, they SHOULD. :) -D >-Original Message- >From: Michael Boyiazis [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, June 14, 2000 3:54 PM >To: [EMAIL PROTECTED] >Subject: RE: Bouncing mail w/ no reverse DNS > > > > Forgive me if this is somewhere in the Docs, I can't find it. >> >> I would like to bounce inbound mail that comes in that can't resolve >> reverse DNS. >> >> A lot of net admins out there have started to not setup DNS >> entries for >> their dial-up accounts believing that this is a better approach than >> registering w/ the MAPS/DUL list. >> >> Personally I don't agree... but I'm getting a lot of trespass spam via >> non resolved DNS. >> >> Any ideas? > >I tried it for about two days. I had sales people complaining that >they couldn't get mail from their contacts; I had tech(!) firms' mail >bouncing back to them; etc. > >While some spam comes from these unlisted people, most >comes from hijacked servers used for relay, which have perfectly >set up DNS entries. > >Michael Boyiazis - >[EMAIL PROTECTED] > >NetZero >Mail/Sys/Network Admin > > >_ >NetZero - Defenders of the Free World >Click here for FREE Internet Access and Email >http://www.netzero.net/download/index.html >
RE: Bouncing mail w/ no reverse DNS
You can use the patch at http://www.qmail.org/qmail-1.03-mfcheck.3.patch to do this. I have used it, and love it. We were seeing MUCH more spam from nonexistant domains than legitimate ones, so this helped out a ton. Call me old school, but I think every return address should have a valid, resolvable DNS entry, so I don't shed too many tears when emails with bad DNS information don't get through. -D >-Original Message- >From: Sgt Chains [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, June 14, 2000 3:13 PM >To: [EMAIL PROTECTED] >Subject: Bouncing mail w/ no reverse DNS > > >Forgive me if this is somewhere in the Docs, I can't find it. > >I would like to bounce inbound mail that comes in that can't resolve >reverse DNS. > >A lot of net admins out there have started to not setup DNS entries for >their dial-up accounts believing that this is a better approach than >registering w/ the MAPS/DUL list. > >Personally I don't agree... but I'm getting a lot of trespass spam via >non resolved DNS. > >Any ideas? > >--Larry >mailto:[EMAIL PROTECTED] >
RE: Bouncing mail w/ no reverse DNS
> Forgive me if this is somewhere in the Docs, I can't find it. > > I would like to bounce inbound mail that comes in that can't resolve > reverse DNS. > > A lot of net admins out there have started to not setup DNS > entries for > their dial-up accounts believing that this is a better approach than > registering w/ the MAPS/DUL list. > > Personally I don't agree... but I'm getting a lot of trespass spam via > non resolved DNS. > > Any ideas? I tried it for about two days. I had sales people complaining that they couldn't get mail from their contacts; I had tech(!) firms' mail bouncing back to them; etc. While some spam comes from these unlisted people, most comes from hijacked servers used for relay, which have perfectly set up DNS entries. Michael Boyiazis - [EMAIL PROTECTED] NetZero Mail/Sys/Network Admin _ NetZero - Defenders of the Free World Click here for FREE Internet Access and Email http://www.netzero.net/download/index.html
Bouncing mail w/ no reverse DNS
Forgive me if this is somewhere in the Docs, I can't find it. I would like to bounce inbound mail that comes in that can't resolve reverse DNS. A lot of net admins out there have started to not setup DNS entries for their dial-up accounts believing that this is a better approach than registering w/ the MAPS/DUL list. Personally I don't agree... but I'm getting a lot of trespass spam via non resolved DNS. Any ideas? --Larry mailto:[EMAIL PROTECTED]
Re: bypassing relaydomains (reverse DNS issues)
> Dinesh Punjabi (Fri 12.0500-08:16): > Again, how can I modify tcpserver or qmail or > relaydomains in order to ignore domain based > relay checks. did you think of opening up the server temporarily to relieve your customers until you are set? while open-relaying you should give tcpserver the -x flag and set up the "noconnects" database according to rbl standards. i think there are dns implementations that do the neccessary lookups (dns implemetation of [EMAIL PROTECTED]?). -- clemens [EMAIL PROTECTED]
bypassing relaydomains (reverse DNS issues)
I am using qmail under tcpserver. We have users that are coming in from IPs that have no reverse DNS resolution. As a result, it takes forever for them to send email via smtp connections. I want to disable reverse lookups using the -HR flag on tcpserver, but appear to run into a problem with /var/qmail/control/relaydomains, i.e. users that are listed in relaydomains are now disallowed since I disabled reverse lookups. Is there an easy way to temporarily disable relaydomains, and control relaying purely based on relayclients. I do realize that tcpserver itself provides an IP based relaying mechanism, but I currently cannot update qmail due to some other issues (since I already have patched qmail with relayclient/domains patch). Again, how can I modify tcpserver or qmail or relaydomains in order to ignore domain based relay checks. Thanks for your help! __ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Re: reverse DNS
On Mon, Jan 24, 2000 at 03:32:51PM -0500, Justin Bell wrote: > How many servers really reject mail based on reverse? mail.com does. I have see others. I don't know why they to that. It must slow things down quite a bit. Spammers can easily defeat it. Neil
Re: reverse DNS
Never thought that it was a problem. I used to use a ml.org dynamic IP host for a temporary mailserver. I never had a problem, receiving or sending. At 03:32 PM 1/24/00 -0500, you wrote: >What does not having reverse DNS really mean when it comes to a mail server? > >We are moving our server from a machine WITH reverse DNS at our old ISP, to a >machine in house that reverse DNS cant be set right now due to a messup at >ARIN. > >How many servers really reject mail based on reverse? > >This is a mailing list host. > >Thanks, >Justin >-- >[EMAIL PROTECTED] Justin Bell > Pearson PTC >Get money back when shopping online Programmer >http://www.ebates.com/index.jhtml?referrer=jaymz > >Get $20 FREE! >https://preview.x.com/new_account.asp?[EMAIL PROTECTED] > >Get $10 FREE >https://secure.paypal.com/refer/pal=justin%40iquest.net > >Get paid to surf the web >http://www.alladvantage.com/go.asp?refid=FBH998
reverse DNS
What does not having reverse DNS really mean when it comes to a mail server? We are moving our server from a machine WITH reverse DNS at our old ISP, to a machine in house that reverse DNS cant be set right now due to a messup at ARIN. How many servers really reject mail based on reverse? This is a mailing list host. Thanks, Justin -- [EMAIL PROTECTED] Justin Bell Pearson PTC Get money back when shopping online Programmer http://www.ebates.com/index.jhtml?referrer=jaymz Get $20 FREE! https://preview.x.com/new_account.asp?[EMAIL PROTECTED] Get $10 FREE https://secure.paypal.com/refer/pal=justin%40iquest.net Get paid to surf the web http://www.alladvantage.com/go.asp?refid=FBH998
Re: reverse DNS
Russell Nelson <[EMAIL PROTECTED]> writes: > Michael Boyiazis writes: >> I went through qmail-smtpd and added a bit of code to do a >> gethostbyaddr. If I don't get a value, I refuse the mail due to no >> reverse DNS. Now looking over some comments in this list and with a >> little closer look at the setup routine in qmail-smtpd.c it appears if >> the name cannot be resolved, remoteip and/or remotehost get set to >> 'unknown'. Would it make sense to deny mail if either of these is >> 'unknown'. and/or set tcpserver option -p? > Yes and no. You get too many false positives. Then again, AOL seems > to get away with it. This practice is so widespread that I think it's reaching the point where it's pointless. The spammers use valid addresses now because they know people do this, and the legitimate folks have been forced to fix their DNS. I still see some rejections from our mail servers that do this (mostly spam), but it's slowing a lot. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>
Re: reverse DNS
Michael Boyiazis writes: > I went through qmail-smtpd and added a bit of code to > do a gethostbyaddr. If I don't get a value, I refuse the > mail due to no reverse DNS. Now looking over some > comments in this list and with a little closer look at the > setup routine in qmail-smtpd.c it appears if the name > cannot be resolved, remoteip and/or remotehost get > set to 'unknown'. Would it make sense to deny mail if > either of these is 'unknown'. and/or set tcpserver > option -p? Yes and no. You get too many false positives. Then again, AOL seems to get away with it. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
RE: reverse DNS
Title: RE: reverse DNS This happens in corporate situations with firewalled networks a lot. I speak from unfortunate experience :) > -Original Message- > From: Sam [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 24, 1999 10:41 PM > Cc: [EMAIL PROTECTED] > Subject: Re: reverse DNS > > > Michael Boyiazis writes: > > > I went through qmail-smtpd and added a bit of code to > > do a gethostbyaddr. > > Why? > > Tcpserver already does it for you. > > > set to 'unknown'. Would it make sense to deny mail if > > either of these is 'unknown'. and/or set tcpserver > > option -p? > > My personal experience is that the likelyhood of a given mail server > lacking a proper functioning forward and reverse IP address > resolution is > directly proportional to the likelyhood of you receiving > nothing but spam > or mailbombs from that server. > > Chances are that if someone's not smart enough to implement > DNS properly, > they're not smart enough to configure their mail server as > well. YMMV. > > -- > Sam > >
Re: reverse DNS
Michael Boyiazis writes: > I went through qmail-smtpd and added a bit of code to > do a gethostbyaddr. Why? Tcpserver already does it for you. > set to 'unknown'. Would it make sense to deny mail if > either of these is 'unknown'. and/or set tcpserver > option -p? My personal experience is that the likelyhood of a given mail server lacking a proper functioning forward and reverse IP address resolution is directly proportional to the likelyhood of you receiving nothing but spam or mailbombs from that server. Chances are that if someone's not smart enough to implement DNS properly, they're not smart enough to configure their mail server as well. YMMV. -- Sam
reverse DNS
I went through qmail-smtpd and added a bit of code to do a gethostbyaddr. If I don't get a value, I refuse the mail due to no reverse DNS. Now looking over some comments in this list and with a little closer look at the setup routine in qmail-smtpd.c it appears if the name cannot be resolved, remoteip and/or remotehost get set to 'unknown'. Would it make sense to deny mail if either of these is 'unknown'. and/or set tcpserver option -p? Thanks, mike. NetZero - We believe in a FREE Internet. Shouldn't you? Get your FREE Internet Access and Email at http://www.netzero.net/download/index.html
