From: Duane Hill (d.hillyournetplus.com)
Date: Wed Jan 23 2008 - 23:36:00 CST

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

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[60887]: NOQUEUE: reject: RCPT
> > from vds-dacp2.vispnoc.net[209.163.188.148]: 550 5.1.1
> > <7corkeyschristianliving.net>: Recipient address rejected:
> > undeliverable address: host 162.42.148.120[162.42.148.120] 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 162.42.148.120, 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
> 162.42.148.120.

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).

Done.

> > 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.

-------
  _|_
 (_| |

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