Selective Relaying and tcprulescheck
Greetings All, I have reinstalled qmail EXACTLY via the documentation in LWQ EXCEPT for installation of the daemontools. I am using daemontools 0.76 and I used the referenced Web page in the README to install. I have tried all manner of run files supplied by members of the list - and thank you Robin and others who sent their run files to me. Still, I cannot get selective relay to work. qmail is either promiscuous or a virgin but their ain't no inbetween when it comes to relaying. I did notice in my search of the Web that people were reporting detailed output from running tcprulescheck /etc/tcp.smtp.cdb. Here's the contents of my tcp.smtp file (cut and pasted): 127.:allow,RELAYCLIENT= 192.168.10.:allow,RELAYCLIENT= Yet, when I run tcprulescheck, I get this: [root@cilinux /etc]# tcprulescheck /etc/tcp.smtp.cdb default: allow connection [root@cilinux /etc]# If I run tcprulescheck /etc/tcp.smtp.cdb 192.168.10. I get the same output as above. I have compiled my rules by both invoking tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp /etc/tcp.smtp enter and qmailctl cdb enter Is the minimal output I am seeing from tcprulescheck normal or do I have a problem there? And if it's a problem - what do I do to fix it? Thanks, Scott Zielsdorf Senior Technical Support Consultant Computer Instruments IVR Solutions Support Group Voice: 913.492.1888 x8862 Fax: 913.492.1483
Re: Selective Relaying and tcprulescheck
Hi Scott, you have to set and probably export (someone correct me if i am wrong here) $TCPREMOTEIP before invoking tcprules check. then, tcprulescheck will tell you what will happen to a connection from the ip in $TCPREMOTEIP. for example if your tcp.smtp file is: 127.:allow,RELAYCLIENT= 192.168.10.:allow,RELAYCLIENT= :deny (- default) and you put 192.168.10.5 in $TCPREMOTEIP then it well tell you rule : allow connection if you put 63.195.102.4 i.e, then it will tell you: rule : deny connection hope that helps you. check the refernce page for tcprulescheck: http://cr.yp.to/ucspi-tcp/tcprulescheck.html Regards, Philipp Scott Zielsdorf writes: 127.:allow,RELAYCLIENT= 192.168.10.:allow,RELAYCLIENT= Yet, when I run tcprulescheck, I get this: [root@cilinux /etc]# tcprulescheck /etc/tcp.smtp.cdb default: allow connection [root@cilinux /etc]# If I run tcprulescheck /etc/tcp.smtp.cdb 192.168.10. I get the same output as above. I have compiled my rules by both invoking tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp /etc/tcp.smtp enter and qmailctl cdb enter Is the minimal output I am seeing from tcprulescheck normal or do I have a problem there? And if it's a problem - what do I do to fix it? Thanks, Scott Zielsdorf Senior Technical Support Consultant Computer Instruments IVR Solutions Support Group Voice: 913.492.1888 x8862 Fax: 913.492.1483 Philipp Steinkrüger Technik Oberberg Online Tel.: +49 2261 814240 Fax: +49 2261 814919 www.oberberg.net [EMAIL PROTECTED]
Re: Selective Relaying and tcprulescheck
Scott Zielsdorf [EMAIL PROTECTED] wrote: I did notice in my search of the Web that people were reporting detailed output from running tcprulescheck /etc/tcp.smtp.cdb. Here's the contents of my tcp.smtp file (cut and pasted): 127.:allow,RELAYCLIENT= 192.168.10.:allow,RELAYCLIENT= Which implies :allow . Yet, when I run tcprulescheck, I get this: [root@cilinux /etc]# tcprulescheck /etc/tcp.smtp.cdb default: allow connection [root@cilinux /etc]# If I run tcprulescheck /etc/tcp.smtp.cdb 192.168.10. I get the same output as above. How are you calling tcprulescheck? It needs the environment variable. Try the following: TCPREMOTEIP=192.168.10.4 tcprulescheck /etc/tcp.smtp.cdb Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
RE: Selective Relaying and tcprulescheck
Thanks Philipp and Charles for the help on this. Once I set the TCPREMOTEIP variable I did see the rule which now leads me to the discovery that my Windows workstations - which are DHCP clients - do not have entries in my DNS. So when qmail does the reverse look up, it can't resolve the IP. Short of going off DHCP and putting all my workstations in my DNS, is there any way to fix this? Thanks. -Original Message- From: Philipp Steinkrüger Sent: Wednesday, August 01, 2001 10:33 AM you have to set and probably export (someone correct me if i am wrong here) $TCPREMOTEIP before invoking tcprules check. then, tcprulescheck will tell you what will happen to a connection from the ip in $TCPREMOTEIP.
RE: Selective Relaying and tcprulescheck
At 11:14 01.08.2001 -0500, Scott Zielsdorf wrote: Once I set the TCPREMOTEIP variable I did see the rule which now leads me to the discovery that my Windows workstations - which are DHCP clients - do not have entries in my DNS. so far, so good. but tell me, what does the TCPREMOTEIP Variable have to with DNS ? So when qmail does the reverse look up, it can't resolve the IP. yes, but where's the problem ? Short of going off DHCP and putting all my workstations in my DNS, is there any way to fix this? fix what ? everything will work, even without ptr records... -- --/-/-- Lukas Beeler [EMAIL PROTECTED] ---\-\-- \ \ My HomePage: URL:http://www.projectdream.org / /
Re: Selective Relaying and tcprulescheck
Scott Zielsdorf [EMAIL PROTECTED] wrote: Once I set the TCPREMOTEIP variable I did see the rule which now leads me to the discovery that my Windows workstations - which are DHCP clients - do not have entries in my DNS. So when qmail does the reverse look up, it can't resolve the IP. This shouldn't be a problem if you're setting RELAYCLIENT by IP address instead of by hostname/domainname. Even if you're operating tcpserver in paranoid mode, it only unsets TCPREMOTEHOST if forward and reverse lookups don't match. Short of going off DHCP and putting all my workstations in my DNS, is there any way to fix this? You can stay on DHCP; simply add PTR records for the IP addresses the DHCP server hands out. Is it possible that your workstations are being NATed so that the IP address the mail server sees is not one of the ones you've configured for relaying? Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Re: Selective Relaying and tcprulescheck
On Wed, Aug 01, 2001 at 11:14:43AM -0500, Scott Zielsdorf wrote: Thanks Philipp and Charles for the help on this. Once I set the TCPREMOTEIP variable I did see the rule which now leads me to the discovery that my Windows workstations - which are DHCP clients - do not have entries in my DNS. So when qmail does the reverse look up, it can't resolve the IP. Short of going off DHCP and putting all my workstations in my DNS, is there any way to fix this? Thanks. What, precisely, needs 'fixing'? Reverse lookup is not a requirement. Reverse lookup does not 'resolve IPs' -- it gives a PTR to an A record for the host. TCPREMOTEIP is set based on the connection -- the address is known, not looked up. What problem are you trying to solve? GW
RE: Selective Relaying and tcprulescheck
At 11:37 01.08.2001 -0500, Lukas Beeler wrote: At 11:14 01.08.2001 -0500, Scott Zielsdorf wrote: Once I set the TCPREMOTEIP variable I did see the rule which now leads me to the discovery that my Windows workstations - which are DHCP clients - do not have entries in my DNS. so far, so good. but tell me, what does the TCPREMOTEIP Variable have to with DNS ? Ummm...nothing, at this stage, I would guess. So when qmail does the reverse look up, it can't resolve the IP. yes, but where's the problem ? The problem is RELAYCLIENT doesn't get set and therefore the relaying rules in tcp.smtp.cdb do not get invoked - apparently. The headers in testing show the dialogue between any workstation on my net with qmail smtp as HELO (machine name) (unknown) So, I am *assuming* that even though I have -H (Do Not Look Up Remote Host Name) set in the run file invoking smtp that somesort of lookup is being done and when it can't resolve I get the Sorry...you're not in my rcpthosts file message. Short of going off DHCP and putting all my workstations in my DNS, is there any way to fix this? fix what ? everything will work, even without ptr records... Alas, NOTHING works with respect to selective relaying. Is it maybe a Linux net configuration issue? And to re-iterate from an earlier post, I have followed installation to the letter from LWQ. Thanks, Scott
RE: Selective Relaying and tcprulescheck
At 12:00 01.08.2001 -0500, Scott Zielsdorf wrote: At 11:37 01.08.2001 -0500, Lukas Beeler wrote: So when qmail does the reverse look up, it can't resolve the IP. yes, but where's the problem ? The problem is RELAYCLIENT doesn't get set and therefore the relaying rules in tcp.smtp.cdb do not get invoked - apparently. the rules in tcp.smtp have to be set for ip adresses and not for domain names so if you set them correctly they WILL get invoked.. The headers in testing show the dialogue between any workstation on my net with qmail smtp as HELO (machine name) (unknown) yes, because the machine doesnt have a PTR record, but that shouldnt make a problem So, I am *assuming* that even though I have -H (Do Not Look Up Remote Host Name) set in the run file invoking smtp that somesort of lookup is being done and when it can't resolve I get the Sorry...you're not in my rcpthosts file message. it looks like your tcp.smtp file is set up incorrectly. tcpserver gets the remote ip adress from the connection handshake, and thats not any kind of look up Short of going off DHCP and putting all my workstations in my DNS, is there any way to fix this? fix what ? everything will work, even without ptr records... Alas, NOTHING works with respect to selective relaying. Is it maybe a Linux net configuration issue? And to re-iterate from an earlier post, I have followed installation to the letter from LWQ. selective relaying does not need reverse lookups, it i IP based. i have an private lan running [10.10.1.x adresses] whitout any server that is authoritive for 10.10.in-addr.arpa, and it still works, of course. i have the following line in tcp.smtp 10.10.:allow,RELAYCLIENT= as you see, we have ip adresses there, and they have nothing to do with PTR records.. -- --/-/-- Lukas Beeler [EMAIL PROTECTED] ---\-\-- \ \ My HomePage: URL:http://www.projectdream.org / /
Re: Selective Relaying and tcprulescheck
Scott Zielsdorf writes: Thanks Philipp and Charles for the help on this. Once I set the TCPREMOTEIP variable I did see the rule which now leads me to the discovery that my Windows workstations - which are DHCP clients - do not have entries in my DNS. So when qmail does the reverse look up, it can't resolve the IP. Short of going off DHCP and putting all my workstations in my DNS, is there any way to fix this? reverse lookop is not the problem. you habe IPs in your tcp.smtp file. you can add a export NODNSCHECK= in the qmail-startup file before invoking the smtpd, but thats not the problem. what about charles idea about NAT ? did you telnet to port 25 from one of the clients and watch the qmail logfile ? can you cut and paste a logged try ? regards, philipp Philipp Steinkrüger Technik Oberberg Online Tel.: +49 2261 814240 Fax: +49 2261 814919 www.oberberg.net [EMAIL PROTECTED]
