On Tue, Jan 12, 2010 at 03:02:37PM -0500, Frank Cusack wrote:
> My postfix-2.6.5 is rejecting mail from a host which has a large
Not according to what we see below. "Lost connection" does not mean
you rejected them.
> PTR RRset -- 44 entries and large enough to require TCP.
> host/dig/nslookup actually dumps core on my solaris box (looks like
> the bug was fixed in BIND just a few months ago). I don't know for
> sure that it is the PTR records that are causing the problem
> because all I get in the log is
Coincidence, I would guess. Possibly tangentially related in that
this site's administrator might have tried something else that's as
silly as the multiple PTRs. :) This is almost surely something at
layer 2 or 3.
> Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info]
> connect from unknown[1.2.3.4]
> Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info]
> lost connection after CONNECT from unknown[1.2.3.4]
> Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info]
> disconnect from unknown[1.2.3.4]
>
> I'm not sure what part of my postfix config to even look at since
> the log message is fairly uninformative. Or more importantly, how
> to whitelist their MX host. (I haven't yet reviewed Victor's
> recent mail on that.)
Whitelisting won't keep the connection from dropping.
> I tried putting then in sender_access but apparently postfix
> doesn't get that far. Here are the significant parts of postconf
You're using sender_access as a check_sender_access lookup (good, the
name and function are related.) However, you would want to use a
check_client_access lookup to whitelist a client. But see above, that
won't address the issue at hand.
> smtpd_data_restrictions = reject_multi_recipient_bounce permit
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks
> reject_unauth_pipelining reject_invalid_helo_hostname
reject_unauth_pipelining won't work here, only in
smtpd_data_restrictions
> reject_non_fqdn_helo_hostname
> smtpd_recipient_restrictions = reject_non_fqdn_sender
> reject_unknown_sender_domain reject_non_fqdn_recipient
> reject_unknown_recipient_domain permit_mynetworks
> check_sender_access dbm:/etc/postfix/sender_access
check_sender_access looks up the MAIL FROM address (or the domain, or
the localpart), see SMTPD_ACCESS_README.html and access.5.html for
details.
> reject_unauth_destination reject_non_fqdn_hostname
> reject_invalid_hostname check_sender_mx_access
> cidr:/etc/postfix/bogus_mx reject_rhsbl_sender
> dsn.rfc-ignorant.org reject_rhsbl_sender bogusmx.rfc-ignorant.org
> reject_rhsbl_sender zen.spamhaus.org
> reject_rhsbl_sender bl.spamcop.net permit
Zen and spamcop are not RHSBL services. You're bugging them with
queries that will never match anything. I would suggest that you
consider "reject_rbl_client zen.spamhaus.org", however.
Since you munged the name/IP of the peer with which you were having
problems, there's not anything more we can do here.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
