From: Eric Fung (efungshgmail.com)
Date: Mon Dec 20 2004 - 20:32:43 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

*nods* noted. Added debugging levels and reported below

From the top:
Currently have a production server that serves multiple domains and is
a mail gateway. It is in perfect working order and I don't have any
issues with it with it's current configuration.

However, one of hosted domains does not wish to be included in DNSBL
client checking that is active on this server.

To achieve this, I've added a check_recipient_access before the
reject_rbl_client rule in the smtpd_client_restrictions as we're
running with the default delay_reject = yes

After the changes are made and postfix is sent a reload command. The
problem that is occuring is that any SMTP connection that hits the
server connects, but there appears to be no data transfer between the
client and the serving forked smtpd process.

Debug output as below:
Dec 21 13:11:16 dbmail-01 postfix/smtpd[26442]: connect from
dbmail-01.sys.bigblue.net.au[203.166.224.25]
Dec 21 13:11:16 dbmail-01 postfix/smtpd[26442]: >
dbmail-01.sys.bigblue.net.au[203.166.224.25]: 220
dbmail-01.sys.bigblue.net.au ESMTP Postfix
Dec 21 13:11:16 dbmail-01 postfix/smtpd[26442]: watchdog_pat: 0x809f210
Dec 21 13:11:17 dbmail-01 postfix/smtpd[26442]: smtp_get: EOF
Dec 21 13:11:17 dbmail-01 postfix/smtpd[26442]: lost connection after
CONNECT from dbmail-01.sys.bigblue.net.au[203.166.224.25]
Dec 21 13:11:17 dbmail-01 postfix/smtpd[26442]: disconnect from
dbmail-01.sys.bigblue.net.au[203.166.224.25]

The funny thing is, the smtpd process appears to be sending out the
welcome banner and is awaiting input, just the client doesn't recieve
it, nor is any of the client's input being recieved by the smtpd
process. The EOF, I believe, pertains to the TCP connection being
torn down.

Anyway, I'll list all of my restriction rules here on the working configuration:

smtpd_client_restrictions = permit_mynetworks,
permit_sasl_authenticated, check_client_access
hash:/etc/postfix/client-access, reject_rbl_client t1.dnsbl.net.au,
permit
smtpd_helo_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_invalid_hostname, check_helo_access
hash:/etc/postfix/helo-access, reject_non_fqdn_hostname, permit
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_multi_recipient_bounce, permit
smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender,
permit_sasl_authenticated, check_sender_access
hash:/etc/postfix/sender-access, reject_rhsbl_sender
rddb.dnsbl.net.au, reject_rhsbl_sender endn.dnsbl.net.au,
reject_unknown_sender_domain, permit

This is the modified client_restrictions rule that is breaking the config.
smtpd_client_restrictions = permit_mynetworks,
permit_sasl_authenticated, check_client_access
hash:/etc/postfix/client-access, check_recipient_access
hash:/etc/postfix/dnsbl_whitelist, reject_rbl_client t1.dnsbl.net.au,
permit

I have also tried moving the check_recipient_access and
reject_rbl_client rules, as a pair, to the recipient restrictions but
the same issue occurs.

Additional note: After loading with the above config. If I revert
back to the original rule, I must perform a stop, then a start for the
server to start responding again. It's as if the new
client_restrictions rule breaks something in the master process that
stops the passing of the socket to the forked smtpd process (or
however it works)

I hope I haven't missed anything.

Eric

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]