Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Duane Hill (d.hillyournetplus.com)
Date: Wed Jan 23 2008 - 23:36:00 CST
On Wed, 23 Jan 2008 23:47:54 -0500
Victor Duchovni <Victor.DuchovniMorganStanley.com> wrote:
> On Thu, Jan 24, 2008 at 04:30:07AM +0000, Duane Hill wrote:
> > A customer of ours received a rejection message to a valid email
> > account. I can't quite figure out why. I'm guessing a map may have
> > been getting rebuilt when the rejection was happening. This is the
> > first time this has happened since the initial install of this
> > filter server. Here is the log for the message that was rejected:
> > Jan 24 03:03:46 smtpgate postfix/smtpd: NOQUEUE: reject: RCPT
> > from vds-dacp2.vispnoc.net[188.8.131.52]: 550 5.1.1
> > <7corkeyschristianliving.net>: Recipient address rejected:
> > undeliverable address: host 184.108.40.206[220.127.116.11] said: 550
> > 7corkeyschristianliving.net unknown user account (in reply to RCPT
> > TO command); from=<shannonagnat.net>
> > to=<7corkeyschristianliving.net> proto=ESMTP
> > helo=<vds-dacp2.vispnoc.net>
> The host 18.104.22.168, which does not appear to be running Postfix,
> rejected this recipient. The string "unknown user account" does not
> appear in the Postfix source code, the response lacks DSN information
> and does not enclose the recipient address in <>.
> To find the reason, debug the non-Postfix software running on
It is running Postfix v2.4.6 on FreeBSD v5.5.
> > Here is the results of 'postconf -n':
> > smtpd_recipient_restrictions = permit_mynetworks,
> > check_client_access
> > cidr:/usr/local/etc/postfix/client_access_wite,
> > reject_unknown_reverse_client_hostname, check_helo_access
> > hash:/usr/local/etc/postfix/helo_allow,
> This makes you an open relay to anyone who knows the secret
> whitelisted helo names. Move "reject_unauth_destination" directly
> under the client white list (2 lines above this).
> > reject_non_fqdn_helo_hostname,
> > check_helo_access cidr:/usr/local/etc/postfix/ip_helo_access,
> This is silly, helo names are never IP addresses.
Gotcha. Because of reject_non_fqdn_helo_hostname a HELO/EHLO of an IP
Will never be accepted.
> > check_helo_access hash:/usr/local/etc/postfix/cgate_helo_access,
> > check_helo_access cdb:/usr/local/etc/postfix/imail_helo_access,
> > check_helo_access pcre:/usr/local/etc/postfix/helo_access,
> > reject_non_fqdn_sender,
> > reject_unknown_sender_domain,
> > check_sender_mx_access
> > cidr:/usr/local/etc/postfix/sender_mx_access,
> > reject_non_fqdn_recipient, reject_unauth_destination,
> > check_recipient_access hash:/usr/local/etc/postfix/spam_lovers,
> > reject_rbl_client zen.spamhaus.org,
> > reject_rbl_client bl.spamcop.net,
> > reject_rbl_client list.dsbl.org,
> > reject_unverified_recipient,
> There you are.
> > check_policy_service unix:private/YnPolicy2,
> > reject_multi_recipient_bounce,
> This belongs in "smtpd_data_restrictions", unless you want to
> allow just the first "bounce" recipient and reject the rest.
This has been moved.
> > reject_unauth_pipelining,
> This is much more effective in "smtpd_data_restrictions", where
> it applies even to sessions where PIPELINING is legal during the
> recipient command.
This has been moved.
> > permit
> By the way why are you using both "hash:" and "cdb:" tables? If you
> have CDB, I would avoid "hash:" tables. Also why so many helo_acces
> checks before "reject_unauth_destination", not generally safe.
I am in the process of converting hash to cdb. I have removed the pcre
helo_access as reject_non_fqdn_helo_hostname catches what was in the
map. The other two reject if a HELO/EHLO is one of the domains we host.