On 6 Jun 2016, at 0:34, Yuval Levy wrote:
Hello Postfix-Users. First time poster here, looking for help to
understand what is wrong with my Postfix configuration that has
delivered a message from a blacklisted server.
Log Excerpt
===========
Jun 5 09:58:37 x2 postfix/smtpd[8440]: connect from
unknown[157.52.162.99]
Jun 5 09:58:37 x2 postfix/smtpd[8440]: NOQUEUE: reject: RCPT from
unknown[157.52.162.99]: 454 4.7.1 Service unavailable; Client host
[157.52.162.99] blocked using zen.spamhaus.org;
NOTE THAT 454 REPLY!
from=<newslet...@vacque.com> to=<XXX@XXX> proto=ESMTP
helo=<mr99.dgnmkt.com>
Jun 5 09:58:37 x2 postfix/smtpd[8440]: disconnect from
unknown[157.52.162.99]
Jun 5 10:01:57 x2 postfix/anvil[8394]: statistics: max connection
rate
1/60s for (smtp:198.2.130.200) at Jun 5 09:51:57
Jun 5 10:01:57 x2 postfix/anvil[8394]: statistics: max connection
count
1 for (smtp:198.2.130.200) at Jun 5 09:51:57
Jun 5 10:01:57 x2 postfix/anvil[8394]: statistics: max cache size 2
at
Jun 5 09:55:18
Jun 5 10:06:39 x2 postfix/smtpd[8507]: connect from
unknown[157.52.162.99]
Jun 5 10:06:40 x2 policyd-spf[8513]: None; identity=helo;
client-ip=157.52.162.99; helo=mr99.dgnmkt.com;
envelope-from=newslet...@vacque.com; receiver=XXX@XXX
Jun 5 10:06:40 x2 policyd-spf[8513]: Pass; identity=mailfrom;
client-ip=157.52.162.99; helo=mr99.dgnmkt.com;
envelope-from=newslet...@vacque.com; receiver=XXX@XXX
Jun 5 10:06:40 x2 postfix/smtpd[8507]: 49D01C1EDE:
client=unknown[157.52.162.99]
Jun 5 10:06:40 x2 postfix/cleanup[8514]: 49D01C1EDE:
message-id=messageid-3-M3w1NDIzfDU4fDM3ODk3OTR8eWxlYmF5Y2EwNEBzZmluYS5jb218U2F0LCAwNCBKdW4gMjAxNiAwNToxNDowNyAtMDcwMA==
Jun 5 10:06:40 x2 opendkim[1220]: 49D01C1EDE: [157.52.162.99]
[157.52.162.99] not internal
Jun 5 10:06:40 x2 opendkim[1220]: 49D01C1EDE: not authenticated
Jun 5 10:06:43 x2 opendkim[1220]: 49D01C1EDE: no signature data
Jun 5 10:06:43 x2 postfix/qmgr[1337]: 49D01C1EDE:
from=<newslet...@vacque.com>, size=91945, nrcpt=1 (queue active)
Jun 5 10:06:43 x2 postfix/smtpd[8507]: disconnect from
unknown[157.52.162.99]
Jun 5 10:06:43 x2 dovecot: lmtp(8516): Connect from local
Jun 5 10:06:43 x2 dovecot: lmtp(8516, YYY@XXX):
nhVjEfMxVFdEIQAAzX/GXw:
msgid=messageid-3-M3w1NDIzfDU4fDM3ODk3OTR8eWxlYmF5Y2EwNEBzZmluYS5jb218U2F0LCAwNCBKdW4gMjAxNiAwNToxNDowNyAtMDcwMA==:
saved mail to INBOX
Jun 5 10:06:43 x2 postfix/lmtp[8515]: 49D01C1EDE: to=<YYY@XXX>,
orig_to=<XXX@XXX>, relay=XXX[private/dovecot-lmtp], delay=3.6,
delays=3.5/0.01/0.02/0.05, dsn=2.0.0, status=sent (250 2.0.0 <YYY@XXX>
nhVjEfMxVFdEIQAAzX/GXw Saved)
Jun 5 10:06:43 x2 dovecot: lmtp(8516): Disconnect from local:
Successful quit
Jun 5 10:06:43 x2 postfix/qmgr[1337]: 49D01C1EDE: removed
Notes about the log
===================
@XXX is my server
XXX@XXX is an alias
YYY@XXX is a mailbox
My understanding is that the bad sender [157.52.162.99] has been
blocked
at 9:58:37 based on zen.spamhaus.org, but 8 minutes later it
reconnected
and delivered successfully what should have not passed through.
At the moment, the Zen listing for that address is specifically a CSS
listing with a 60 second TTL, so it is no longer in your cache 8 minutes
after the first check. Due to how the CSS works, it is not uncommon for
addresses to "flicker" in and out of the CSS, which targets "snowshoe"
spammers who cycle their IP sources around a range of addresses to make
detection harder. CSS is fairly good at hitting its targets, but by
their nature they work harder than other sorts of spammers to figure out
how to get addresses listed in CSS for the shortest possible period.
Given what I've seen of that game playing out in the mail systems I run,
I believe Spamhaus has been working to counter the snowshoers' tactics,
but it is an ongoing arms race.
Headers of the mail that should have been rejected
==================================================
Return-Path: <newslet...@vacque.com>
Delivered-To: <YYY@XXX>
Received: from XXX
by XXX (Dovecot) with LMTP id nhVjEfMxVFdEIQAAzX/GXw
for <YYY@XXX>; Sun, 05 Jun 2016 10:06:43 -0400
Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
client-ip=157.52.162.99; helo=mr99.dgnmkt.com;
envelope-from=newslet...@vacque.com; receiver=XXX@XXX
Received: from mr99.dgnmkt.com (unknown [157.52.162.99])
by XXX (Postfix) with ESMTP id 49D01C1EDE
for <XXX@XXX>; Sun, 5 Jun 2016 10:06:39 -0400 (EDT)
Received: from stormmta (unknown [157.52.162.99])
by mr99.dgnmkt.com (Postfix) with ESMTP id DD84AE61F8A
for <XXX@XXX>; Sun, 5 Jun 2016 08:16:33 -0700 (PDT)
From:=?UTF-8?B?VG1hcnQuY29t?=<newslet...@e.ailander.com>
To:XXX@XXX
Relevant main.cf options
If you don't know why something isn't working as expected, you can't
really say what setting are or are not relevant. That is why the
DEBUG_README file for Postfix says to include postconf -n output here
rather than main.cf snippets.
One possible contributor to your problem is that you have apparently set
something that causes you to send a '454' temporary failure code for a
DNSBL listing instead of the default 554. This could be the result of
setting the unfortunately-named "maps_rbl_reject_code" directly or (I
*think*) setting defer_if_reject (I've never used that setting myself so
I may misunderstand it...) It is also possible that you are using a
modified package of Postfix which has maps_rbl_reject_code=454 or
defer_if_reject in its defaults. Whatever the cause, a 4xx response code
is an invitation to the sender to try the same message again later.
========================
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
reject_invalid_hostname
reject_non_fqdn_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_sender_domain
reject_unknown_recipient_domain
check_recipient_access hash:/etc/postfix/recipients
# used to have Postgrey here
# check_policy_service inet:127.0.0.1:10023
reject_rbl_client zen.spamhaus.org
check_policy_service unix:private/policy-spf
permit
smtpd_restriction_classes =
ebay
ebay =
check_reverse_client_hostname_mx_access pcre:/etc/postfix/ebay.pcre
/etc/postfix/recipients
=======================
XXX@XXX ebay
ebay.pcre
=========
/.ebay.com$/ DUNNO
/(.*)/ REJECT Not allowed to relay from $1. Please use eBay's
contact
form if you have legit communication for this email address.
Comments/Background
===================
I assign aliases to isolate sources of mail. One such alias is
assigned
to eBay. eBay leaks buyer's email address to merchants. Not all
merchant respects buyers' communication preferences. My solution is
to
restrict the email accepted on the eBay alias to email from eBay and
reject all noise.
First, I thought that this email should have been rejected by:
check_recipient_access hash:/etc/postfix/recipients
because following /etc/postfix/recipients the ebay restriction apply
and
ebay.pcre would have caught it on the second line.
check_reverse_client_hostname_mx_access requires that there be some
reverse client hostname, i.e. a PTR record in DNS for the connecting IP
address. Your headers and log entries indicate that 157.52.162.99 had no
such record at that time and it has none now. This means there is no
inpt value available for check_reverse_client_hostname_mx_access.
Second, I thought that this email should have been rejected by:
reject_rbl_client zen.spamhaus.org
like the attempt a few minutes earlier.
Obviously what I expected did not happen. Why?
See above.
And how can I fix it?
1. Stop inviting spammers to come back later when their DNSBL listing
has expired. Fix whatever is causing you to send a 454 reply instead of
the default 554 for Zen listings.
2. Stop accepting mail AT ALL from IPs that have no PTR records by
adding reject_unknown_reverse_client_hostname to
smtpd_recipient_restrictions AFTER permit_mynetworks and
permit_sasl_authenticated. reject_unknown_reverse_client_hostname is
extremely safe, requires no additional DNS lookups, and stops a
substantial amount of spam.
