#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
exec /usr/local/bin/softlimit -m 8000000 \
/usr/local/bin/tcpserver -v -H -R -l 0 \
-x /home/vpopmail/etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp rblsmtpd \
-r xxxxx \
-r xxxxx \
/var/qmail/bin/qmail-smtpd \
/home/vpopmail/bin/vchkpw /bin/true 2>&1
Thanks for the clue. I see we're using the 'H' option which prevents
reverse DNS lookups. This configuration setup (with the exception of our
rblsmtpd entries) is a stock Shupp Toaster - so I guess the question is why
the stock toaster is configured not to do reverse DNS lookups when doing so
triggers the spamassassin 'RDNS_NONE' flag.
Any comments? Would rDNS lookups totally slow down a production server?
At 02:09 AM 12/30/2008, you wrote:
What switches are you using to call tcpserver with for your qmail-smtpd
process?
t
----- Original Message -----
From: Jeff Koch <jeffk...@intersessions.com>
To: toaster@shupp.org <toaster@shupp.org>
Sent: Mon Dec 29 23:05:30 2008
Subject: Re: [toaster] Why - Received: from unknown
The receiving mailserver can do reverse DNS perfectly - just doesn't seem
to want to do it during qmail smtp connections. I checked the
/etc/nsswitch.conf file and changed it from:
hosts: files mdns4_minimal [NOTFOUND=return] dns
to:
hosts: dns files
That didn't seem to help either. Do you think a reboot or a service restart
is necessary after making this change?
At 11:49 PM 12/29/2008, you wrote:
>Jeff Koch wrote:
>>Hi:
>>Does anyone happen to know why all emails received by qmail are reported
>>as 'Received: from unknown' even though the sending mailserver clearly
>>identifies itself and has reverve DNS setup?
>>Here's a good example from an email I just recieved:
>>Received: from unknown (HELO lists.sourceforge.net) (216.34.181.88)
>
>That suggests the reverse dns lookups are failing on that server. Have you
>tried some lookups manually to see if they are working? I had an issue
>similar to this just recently with a new server and it took a while to
>realise that I had made a mistake in the nssswitch.conf file and it was
>trying to resolve everything via ldap instead of via dns.
>
>Shane
Best Regards,
Jeff Koch, Intersessions
Best Regards,
Jeff Koch, Intersessions
