On Sun, Jun 05, 2011 at 10:21:38AM -0400, Wietse Venema wrote:
> /dev/rob0:
> > Jun 5 01:50:46 cardinal postfix/postscreen[15628]: CONNECT from
> > [174.37.3.121]:33695 to [216.23.247.74]:25
> > Jun 5 01:50:52 cardinal postfix/postscreen[15628]: PASS OLD
> > [174.37.3.121]:33695
> > Jun 5 01:50:52 cardinal postfix/smtpd[15816]: connect from
> > 174.37.3.121-static.reverse.softlayer.com[174.37.3.121]
>
> Host connects 01:50:46, postscreen logs "PASS OLD" at 01:50:52 and
> hands off the connection to smtpd. The six-second pause suggests
> that postscreen_greet_ttl (1d) expired (according to "postconf -n"
> your postscreen_mumble_ttl settings haven't changed).
Given the cron job flush finding in my previous post on this thread,
it's making sense why these TTL settings are expiring at around the
same time, and even between primary/secondary attempts.
To partly hijack my own thread (with a wink and a nod to my friend
and colleague Jeroen), I'd like to stop this. The sender domain,
which in the OP was not munged, is NXDOMAIN:
rob0@cardinal:~$ host -tany forums.playdom.com.
Host forums.playdom.com. not found: 3(NXDOMAIN)
Lacking what I would call a "complete" understanding of RFC 5321 and
predecessors, I have never tried setting unknown_address_reject_code
to 550. Having seen this post from Viktor:
http://permalink.gmane.org/gmane.mail.postfix.user/133564
I did that, and then turned this one away:
Jun 5 21:54:03 cardinal postfix/postscreen[3582]: CONNECT from
[174.37.3.121]:35549 to [216.23.247.74]:25
Jun 5 21:54:03 cardinal postfix/postscreen[3582]: PASS OLD
[174.37.3.121]:35549
Jun 5 21:54:03 cardinal postfix/smtpd[3808]: connect from
174.37.3.121-static.reverse.softlayer.com[174.37.3.121]
Jun 5 21:54:03 cardinal postfix/smtpd[3808]: setting up TLS
connection from
174.37.3.121-static.reverse.softlayer.com[174.37.3.121]
Jun 5 21:54:04 cardinal postfix/smtpd[3808]: Anonymous TLS
connection established from
174.37.3.121-static.reverse.softlayer.com[174.37.3.121]: TLSv1
with cipher DHE-RSA-AES256-SHA (256/256 bits)
Jun 5 21:54:04 cardinal postfix/smtpd[3808]: NOQUEUE: reject: RCPT
from 174.37.3.121-static.reverse.softlayer.com[174.37.3.121]: 550
5.1.8 <apa...@forums.playdom.com>: Sender address rejected: Domain
not found; from=<apa...@forums.playdom.com> to=<f...@q.example.us>
proto=ESMTP helo=<tomcat205.playdom.com>
Jun 5 21:54:04 cardinal postfix/smtpd[3808]: disconnect from
174.37.3.121-static.reverse.softlayer.com[174.37.3.121]
And there was no followup on [216.23.247.78]:25. Looking again just
now, I see no further attempts. Good riddance!
I'll take the opportunity at this point to suggest softening the
postconf.5.html#unknown_address_reject_code warning: "Do not change
this unless you have a complete understanding of RFC 2821." There's
nothing wrong, and it seems to me, a lot *right*, about rejecting
NXDOMAIN addresses with 550.
> > Jun 5 01:50:53 cardinal postfix/postscreen[15628]: CONNECT from
> > [174.37.3.121]:52927 to [216.23.247.78]:25
> > Jun 5 01:50:53 cardinal postfix/postscreen[15628]: WHITELIST VETO
> > [174.37.3.121]:52927
>
> > It was whitelisted 7 seconds ago. Could that have expired?
>
> What 7 seconds? the "PASS OLD" action was logged 01:50:52. The
> new connection is made 01:50:53.
>
> Each postscreen test has its own TTL. Different tests have different
> costs (for sender and receiver), and therefore different tests
> expire at different times.
>
> You have the following time-dependent tests enabled:
>
> postscreen_bare_newline_action = enforce
> postscreen_dnsbl_action = enforce
> postscreen_greet_action = enforce
>
> Their expiration times are:
>
> postscreen_bare_newline_ttl = 30d
> postscreen_dnsbl_ttl = 1h
> postscreen_greet_ttl = 1d
>
> Clearly, they don't expire at the same time.
Right, I understood this, but had never thought about how the
staggered expirations interact with one another. Since the
postscreen_cache_map is shared for all tests, I guess that means
"PASS NEW" is logged only if the client is not in the map at all.
> The Postfix verify(8) daemon avoids client-visible delays by sending
> a new probe before a result expires (it has separate _refresh and
> _expire timing parameters).
>
> That trick does not work with postscreen. postscreen does not have
> separate _refresh and _expire settings because many postscreen
> tests are client-visible. For example, postscreen_greet is visible
> (6 seconds delay), postscreen_dnsbl almost invisible (less than 1
> second, usually) and postscreen_bare_newline means the client gets
> 4XX replies if it passes the test. So, in the majority of tests it
> is not possible to refresh a test without client-visible delays.
In this case it looks like we had an expired postscreen_greet_ttl for
the first (primary MX) attempt, and an expired postscreen_dnsbl_ttl
for the second (WHITELIST VETO) attempt. Interesting.
> When a test has expired, postscreen could refresh all unexpired
> tests that will expire soon. For example, all tests that will
> expire within one TTL of the expired test, or all tests that will
> expire within one hour. This will not necessarily reduce the amount
> of client-visible delays, but it will reduce the WHITELIST VETO
> logs.
Thanks for the detailed explanation. I don't think any change is
necessary, because this is an edge case hinging on the gross
misconfiguration of the client at 174.37.3.121. The expirations as
designed work well with clients who are delivering good mail, and now
that I've changed unknown_address_reject_code, it should work well
enough with this client, if it should happen to return with another
bogus sender address.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
