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
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
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
invoking tcprules check. then, tcprulescheck
will tell you what will happen to a connection from the ip in
$TCPREMOTEIP.
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
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
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.
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
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
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
Chris Johnson wrote:
It looks like you might be using an older version of tcprulescheck. Try this
and see what happens:
tcprulescheck /etc/tcp.smtp.cdb 203.34.190.170
Same thing as before, I'm afraid.
tcpserver, tcprules and tcprulescheck were all installed from
ucspi-tcp-0.88.
Cheers
On Thu, Jul 13, 2000 at 03:52:14PM +0930, Andrew Hill wrote:
Chris Johnson wrote:
It looks like you might be using an older version of tcprulescheck. Try this
and see what happens:
tcprulescheck /etc/tcp.smtp.cdb 203.34.190.170
Same thing as before, I'm afraid.
tcpserver, tcprules
"Brian D. Winters" wrote:
It looks like Chris Johnson is using an old version of
tcprulescheck. ;) A careful read of
http://cr.yp.to/ucspi-tcp/tcprulescheck.html gives the correct
semantics for version 0.88. Try this:
TCPREMOTEIP=203.34.190.170 tcprulescheck /etc/tcp.smtp.
On Thu, Jul 13, 2000 at 04:52:27PM +0930, Andrew Hill wrote:
Well, I don't know what parts you are carefully reading that indicate
that you should use the above command, becuase to me, the page says to
This part:
tcprulescheck says what tcpserver will do with a connection from
IP
Andrew Hill writes:
"Brian D. Winters" wrote:
TCPREMOTEIP=203.34.190.170 tcprulescheck /etc/tcp.smtp.cdb
Well, I don't know what parts you are carefully reading that indicate
that you should use the above command, becuase to me, the page says to
use the command:
tcprulesche
"Brian D. Winters" wrote:
heading does not constitute a careful reading. :) If you bother to
keep going, the paragraph explains that tcprulescheck uses the
contents of the environment variables TCPREMOTEIP, TCPREMOTEHOST, and
TCPREMOTEINFO to determine which entry in the cdb
# /usr/local/bin/tcprulescheck /etc/tcp.smtp.cdb
default:
allow connection
Did I get that right? I'm hope that's what $TCPREMOTEHOST and
$TCPREMOTEINFO should be.
You appear to be running things correctly, but I can't say if that's
the right result. Does /etc/tcp.smtp say
"Brian D. Winters" wrote:
You appear to be running things correctly, but I can't say if that's
the right result. Does /etc/tcp.smtp say that 203.34.190.170 should
be allowed to connect? Does /etc/tcp.smtp contain any rules at all?
Have you recreated /etc/tcp.smtp.cdb since you added rules
/tcp.smtp I have:
203.34.190.129-254:allow,RELAYCLIENT=""
127.0.0.:allow,RELAYCLIENT=""
I've run:
tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp /etc/tcp.smtp
However, when I check the rules using:
tcprulescheck /etc/tcp.smtp.cdb
I get:
default:
allow connection
I've run:
tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp /etc/tcp.smtp
However, when I check the rules using:
tcprulescheck /etc/tcp.smtp.cdb
I get:
default:
allow connection
Should I be seeing something else here that indicates
that RELAYCLIENT has been set
Chris Johnson wrote:
Read http://cr.yp.to/ucspi-tcp/tcprulescheck.html
Thanks Chris,
I've read the above, (and your helpful page at
http://www.palomine.net/qmail/selectiverelay.html) but it still doesn't
tell me what I should expect to see when testing with tcprulescheck.
The only thing
expect to see when testing with tcprulescheck.
The only thing that I didn't try before was setting the $TCPREMOTEIP
environment variable (I assume that's what the page you suggested
means). However, setting that variable to 203.34.190.170 (an IP in the
range I've set as to allow relaying
22 matches
Mail list logo
