Bugfix: cut-and-paste error. Postscreen used pregreet_ttl
instead of dnsbnl_ttl. File: postscreen/postscreen_early.c.
+
+20100920
+
+ Cleanup: minor cleanups and invisible fixes. Files:
+ postscreen/postscreen_misc.c, postscreen/postscreen.h,
+ postscreen/postscreen_tests.c.
I\bIn\bnt\btr\bro\bod\bdu\buc\bct\bti\bio\bon\bn
The Postfix postscreen(8) server performs triage on multiple inbound SMTP
-connections in parallel. While a single postscreen(8) process keeps spambots
+connections in parallel. While a single postscreen(8) process keeps zombies
away from Postfix SMTP server processes, more Postfix SMTP server processes
remain available for legitimate clients.
By doing these checks in a single postscreen(8) process, Postfix can avoid
-wasting one SMTP server process per connection. A side benefit of postscreen
-(8)'s DNSBL lookups is that DNS records are already cached before the Postfix
+wasting one SMTP server process per zombie. A side benefit of postscreen(8)'s
+DNSBL lookups is that DNS records will already be cached before the Postfix
SMTP server looks them up later.
Topics in this document:
T\bTh\bhe\be b\bba\bas\bsi\bic\bc i\bid\bde\bea\ba b\bbe\beh\bhi\bin\bnd\bd p\bpo\bos\bst\bts\bsc\bcr\bre\bee\ben\bn(\b(8\b8)\b)
-Spambots have a limited amount of time to send out spam before they become
-blacklisted. For this reason, spambots make compromises in their SMTP protocol
-implementation to speed up spam deliveries. For example, they speak before
-their turn, or they ignore responses from SMTP servers.
-
-Many spambots avoid spamming the same site repeatedly, in an attempt to fly
-under the radar. Thus, postscreen(8) must make a long-term decision after a
-single measurement. For example, allow a good client to skip the "pregreet"
-test for 24 hours.
-
-To recognize spambots, postscreen(8) measures properties of the client IP
-address and of the client SMTP protocol implementation (the protocol
-compromises that were made to speed up delivery). These properties don't change
-with delivery attempts, and are therefore suitable for making a long-term
-decision after a single measurement.
-
-postscreen(8) does not inspect message content. The reason is that content can
-change with each delivery attempt, especially with legitimate clients. Message
-content is not good for making a long-term decision after a single measurement,
-and that is the problem that postscreen(8) is focused on.
+Most email is spam, and most spam is sent out by zombies (malware on
+compromised end-user computers). Wietse expects that the zombie problem will
+get worse before things improve, if ever. Without a tool like postscreen(8)
+that keeps the zombies away, Postfix would be spending most of its resources
+not receiving email.
+
+The main challenge for postscreen(8) is to make an is-it-a-zombie decision
+based on a single measurement. This is necessary because many zombies avoid
+spamming the same site repeatedly, in an attempt to fly under the radar. Once
+postscreen(8) decides that a client is not-a-zombie, it whitelists the client
+temporarily to avoid further delays for legitimate mail.
+
+Zombies have challenges too: they have only a limited amount of time to deliver
+spam before their IP address becomes blacklisted. To speed up spam deliveries,
+zombies make compromises in their SMTP protocol implementation. For example,
+they speak before their turn, or they ignore responses from SMTP servers and
+continue sending mail even when the server tells them to go away.
+
+postscreen(8) uses a variety of measurements to recognize zombies. First,
+postscreen(8) determines if the remote SMTP client IP address is blacklisted.
+Second, postscreen(8) looks for protocol compromises that are made to speed up
+delivery. The results of such measurements don't change with each delivery
+attempt, and are therefore good for making an is-it-a-zombie decision based on
+a single measurement.
+
+postscreen(8) does not inspect message content. Message content can vary widely
+with each delivery attempt, especially with clients that (also) send legitimate
+email. Content is therefore not good for making an is-it-a-zombie decision
+based on a single measurement, and that is the problem that postscreen(8) is
+focused on.
G\bGe\ben\bne\ber\bra\bal\bl o\bop\bpe\ber\bra\bat\bti\bio\bon\bn
recipient information.
Note: postscreen(8) is not an SMTP proxy; this is intentional. The purpose is
-to keep spambots away from Postfix, with minimal overhead for legitimate
+to keep zombies away from Postfix, with minimal overhead for legitimate
clients.
Q\bQu\bui\bic\bck\bk t\bte\bes\bst\bts\bs b\bbe\bef\bfo\bor\bre\be e\bev\bve\ber\bry\byt\bth\bhi\bin\bng\bg e\bel\bls\bse\be
P\bPr\bre\beg\bgr\bre\bee\bet\bt t\bte\bes\bst\bt
The SMTP protocol is a classic example of a protocol where the server speaks
-before the client. postscreen(8) detects spambots that are in a hurry and that
+before the client. postscreen(8) detects zombies that are in a hurry and that
speak before their turn. This test is enabled by default.
The postscreen_greet_banner parameter specifies the text portion of a "220-
text..." teaser banner (default: $smtpd_banner). Note that this becomes the
first part of a multi-line server greeting. The postscreen(8) daemon sends this
before the postscreen_greet_wait timer is started. The purpose of the teaser
-banner is to confuse spambots so that they speak before their turn. It has no
+banner is to confuse zombies so that they speak before their turn. It has no
effect on SMTP clients that correctly implement the protocol.
To avoid problems with poorly-implemented SMTP engines in network appliances or
is equal to or greater than the postscreen_dnsbl_threshold parameter value,
postscreen(8) logs this as:
-D\bDN\bNS\bSB\bBL\bL r\bra\ban\bnk\bk count f\bfo\bor\br address
+ D\bDN\bNS\bSB\bBL\bL r\bra\ban\bnk\bk count f\bfo\bor\br address
Translation: the SMTP client at address has a combined DNSBL score of count.
are not allowed to send multiple commands. postscreen(8)'s deep protocol test
for this is disabled by default.
-With "postscreen_pipelining_enable = yes", postscreen(8) detects spambots that
+With "postscreen_pipelining_enable = yes", postscreen(8) detects zombies that
send multiple commands, instead of sending one command and waiting for the
server to reply.
equivalent postscreen_forbidden_commands feature to block these clients.
postscreen(8)'s deep protocol test for this is disabled by default.
-With "postscreen_non_smtp_command_enable = yes", postscreen(8) detects spambots
+With "postscreen_non_smtp_command_enable = yes", postscreen(8) detects zombies
that send commands specified with the postscreen_forbidden_commands parameter.
This also detects commands with the syntax of a message header label. The
latter is a symptom that the client is sending message content after ignoring
* "postscreen_greet_action = enforce", to reject clients that talk before
their turn, and to log the helo/sender/recipient information. This stops
over half of all known-to-be illegitimate connections to Wietse's mail
- server. It is backup protection for spambots that haven't yet been
+ server. It is backup protection for zombies that haven't yet been
blacklisted.
* You can also enable "deep protocol tests", but these are more intrusive
Remove this file from the stable release.
- how to prevent postscreen's cache sweeper from deleting
- records that have failed ignored tests?
-
- Update history in manpage/readme for SQLite driver.
-
- header_checks(5): document synopsis and feature subsets.
-
Consistency: in postconf.proto make <dt>..</dt> tags bold.
+ postscreen(8): listen on multiple IP addresses and enforce
+ that the client contacts the primary MX address first (i.e.
+ punish hosts that contact the secondary before the primary).
+ The downside with any approach that relies on temporary
+ punishment is that it does not scale to configurations
+ with multiple equal-preference MX hosts. Such hosts would
+ have to share the postscreen cache, causing an unacceptable
+ performance bottleneck and a single point of failure.
+
According to a paper by Ted Unangst at BSDCON09, kqueue
reports state changes, i.e. kqueue indicates when the socket
becomes readable. Specifically, he writes when kqueue reports
repeats these tests with OpenBSD and NetBSD (and MacOS X
once they fix their kqueue implementation).
- postscreen(8): need some option to wait for DNSBL lookup
- (etc.) completion. For example, postscreen_greet_wait would
- become a lower bound, while postscreen_dnsbl_wait would
- become an upper bound (or should all features use a shared
- postscreen_max_wait upper bound?).
-
Would it help if there were different cleanup_service
parameter names for different message paths? smtpd(8) uses
the same cleanup_service value for receiving remote mail
<p> The Postfix <a href="postscreen.8.html">postscreen(8)</a> server performs triage on multiple
inbound SMTP connections in parallel. While a single <a href="postscreen.8.html">postscreen(8)</a>
-process keeps spambots away from Postfix SMTP server processes,
+process keeps zombies away from Postfix SMTP server processes,
more Postfix SMTP server processes remain available for legitimate
clients. </p>
<p> By doing these checks in a single <a href="postscreen.8.html">postscreen(8)</a> process, Postfix
-can avoid wasting one SMTP server process per connection. A side
-benefit of <a href="postscreen.8.html">postscreen(8)</a>'s DNSBL lookups is that DNS records are
-already cached before the Postfix SMTP server looks them up later.
-</p>
+can avoid wasting one SMTP server process per zombie. A side benefit
+of <a href="postscreen.8.html">postscreen(8)</a>'s DNSBL lookups is that DNS records will already be
+cached before the Postfix SMTP server looks them up later. </p>
<p> Topics in this document: </p>
<h2> <a name="basic">The basic idea behind postscreen(8)</a> </h2>
-<p> Spambots have a limited amount of time to send out spam before
-they become blacklisted. For this reason, spambots make compromises
-in their SMTP protocol implementation to speed up spam deliveries.
-For example, they speak before their turn, or they ignore responses
-from SMTP servers. </p>
-
-<p> Many spambots avoid spamming the same site repeatedly, in an
-attempt to fly under the radar. Thus, <a href="postscreen.8.html">postscreen(8)</a> must make a
-long-term decision after a single measurement. For example, allow
-a good client to skip the "<a href="#pregreet">pregreet</a>" test
-for 24 hours. </p>
-
-<p> To recognize spambots, <a href="postscreen.8.html">postscreen(8)</a> measures properties of the
-client IP address and of the client SMTP protocol implementation
-(the protocol compromises that were made to speed up delivery).
-These properties don't change with delivery attempts, and are
-therefore suitable for making a long-term decision after a single
-measurement. </p>
-
-<p> <a href="postscreen.8.html">postscreen(8)</a> does not inspect message content. The reason is
-that content can change with each delivery attempt, especially with
-legitimate clients. Message content is not good for making a long-term
-decision after a single measurement, and that is the problem that
-<a href="postscreen.8.html">postscreen(8)</a> is focused on. </p>
+<p> Most email is spam, and most spam is sent out by zombies (malware
+on compromised end-user computers). Wietse expects that the zombie
+problem will get worse before things improve, if ever. Without a
+tool like <a href="postscreen.8.html">postscreen(8)</a> that keeps the zombies away, Postfix would be
+spending most of its resources not receiving email. </p>
+
+<p> The main challenge for <a href="postscreen.8.html">postscreen(8)</a> is to make an is-it-a-zombie
+decision based on a single measurement. This is necessary because
+many zombies avoid spamming the same site repeatedly, in an attempt
+to fly under the radar. Once <a href="postscreen.8.html">postscreen(8)</a> decides that a client
+is not-a-zombie, it whitelists the client temporarily to avoid
+further delays for legitimate mail. </p>
+
+<p> Zombies have challenges too: they have only a limited amount
+of time to deliver spam before their IP address becomes blacklisted.
+To speed up spam deliveries, zombies make compromises in their SMTP
+protocol implementation. For example, they speak before their turn,
+or they ignore responses from SMTP servers and continue sending
+mail even when the server tells them to go away. </p>
+
+<p> <a href="postscreen.8.html">postscreen(8)</a> uses a variety of measurements to recognize
+zombies. First, <a href="postscreen.8.html">postscreen(8)</a> determines if the remote SMTP client
+IP address is blacklisted. Second, <a href="postscreen.8.html">postscreen(8)</a> looks for protocol
+compromises that are made to speed up delivery. The results of
+such measurements don't change with each delivery attempt, and are
+therefore good for making an is-it-a-zombie decision based on a
+single measurement. </p>
+
+<p> <a href="postscreen.8.html">postscreen(8)</a> does not inspect message content. Message content
+can vary widely with each delivery attempt, especially with clients
+that (also) send legitimate email. Content is therefore not good
+for making an is-it-a-zombie decision based on a single measurement,
+and that is the problem that <a href="postscreen.8.html">postscreen(8)</a> is focused on. </p>
<h2> <a name="general"> General operation </a> </h2>
logging the helo, sender and recipient information. </p>
<p> Note: <a href="postscreen.8.html">postscreen(8)</a> is not an SMTP proxy; this is intentional.
-The purpose is to keep spambots away from Postfix, with minimal
+The purpose is to keep zombies away from Postfix, with minimal
overhead for legitimate clients. </p>
<h2> <a name="quick">Quick tests before everything else</a> </h2>
<h3> <a name="pregreet"> Pregreet test </a> </h3>
<p> The SMTP protocol is a classic example of a protocol where the
-server speaks before the client. <a href="postscreen.8.html">postscreen(8)</a> detects spambots
+server speaks before the client. <a href="postscreen.8.html">postscreen(8)</a> detects zombies
that are in a hurry and that speak before their turn. This test is
enabled by default. </p>
Note that this becomes the first part of a multi-line server greeting.
The <a href="postscreen.8.html">postscreen(8)</a> daemon sends this before the <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a>
timer is started. The purpose of the teaser banner is to confuse
-spambots so that they speak before their turn. It has no effect on
+zombies so that they speak before their turn. It has no effect on
SMTP clients that correctly implement the protocol. </p>
<p> To avoid problems with poorly-implemented SMTP engines in network
DNSBL score is equal to or greater than the <a href="postconf.5.html#postscreen_dnsbl_threshold">postscreen_dnsbl_threshold</a>
parameter value, <a href="postscreen.8.html">postscreen(8)</a> logs this as: </p>
-<b>DNSBL rank</b> <i>count</i> <b>for</b> <i>address</i>
+<pre>
+ <b>DNSBL rank</b> <i>count</i> <b>for</b> <i>address</i>
+</pre>
<p> Translation: the SMTP client at <i>address</i> has a combined
DNSBL score of <i>count</i>. </p>
protocol test</a> for this is disabled by default. </p>
<p> With "<a href="postconf.5.html#postscreen_pipelining_enable">postscreen_pipelining_enable</a> = yes", <a href="postscreen.8.html">postscreen(8)</a> detects
-spambots that send multiple commands, instead of sending one command
+zombies that send multiple commands, instead of sending one command
and waiting for the server to reply. </p>
<p> This test is opportunistically enabled when <a href="postscreen.8.html">postscreen(8)</a> has
protocol test</a> for this is disabled by default. </p>
<p> With "<a href="postconf.5.html#postscreen_non_smtp_command_enable">postscreen_non_smtp_command_enable</a> = yes", <a href="postscreen.8.html">postscreen(8)</a>
-detects spambots that send commands specified with the
+detects zombies that send commands specified with the
<a href="postconf.5.html#postscreen_forbidden_commands">postscreen_forbidden_commands</a> parameter. This also detects commands
with the syntax of a message header label. The latter is a symptom
that the client is sending message content after ignoring all the
clients that talk before their turn, and to log the helo/sender/recipient
information. This stops over half of all known-to-be illegitimate
connections to Wietse's mail server. It is backup protection for
-spambots that haven't yet been blacklisted. </p>
+zombies that haven't yet been blacklisted. </p>
<li> <p> You can also enable "<a href="#after_220">deep protocol
tests</a>", but these are more intrusive than the pregreet or DNSBL
<p> The Postfix postscreen(8) server performs triage on multiple
inbound SMTP connections in parallel. While a single postscreen(8)
-process keeps spambots away from Postfix SMTP server processes,
+process keeps zombies away from Postfix SMTP server processes,
more Postfix SMTP server processes remain available for legitimate
clients. </p>
<p> By doing these checks in a single postscreen(8) process, Postfix
-can avoid wasting one SMTP server process per connection. A side
-benefit of postscreen(8)'s DNSBL lookups is that DNS records are
-already cached before the Postfix SMTP server looks them up later.
-</p>
+can avoid wasting one SMTP server process per zombie. A side benefit
+of postscreen(8)'s DNSBL lookups is that DNS records will already be
+cached before the Postfix SMTP server looks them up later. </p>
<p> Topics in this document: </p>
<h2> <a name="basic">The basic idea behind postscreen(8)</a> </h2>
-<p> Spambots have a limited amount of time to send out spam before
-they become blacklisted. For this reason, spambots make compromises
-in their SMTP protocol implementation to speed up spam deliveries.
-For example, they speak before their turn, or they ignore responses
-from SMTP servers. </p>
-
-<p> Many spambots avoid spamming the same site repeatedly, in an
-attempt to fly under the radar. Thus, postscreen(8) must make a
-long-term decision after a single measurement. For example, allow
-a good client to skip the "<a href="#pregreet">pregreet</a>" test
-for 24 hours. </p>
-
-<p> To recognize spambots, postscreen(8) measures properties of the
-client IP address and of the client SMTP protocol implementation
-(the protocol compromises that were made to speed up delivery).
-These properties don't change with delivery attempts, and are
-therefore suitable for making a long-term decision after a single
-measurement. </p>
-
-<p> postscreen(8) does not inspect message content. The reason is
-that content can change with each delivery attempt, especially with
-legitimate clients. Message content is not good for making a long-term
-decision after a single measurement, and that is the problem that
-postscreen(8) is focused on. </p>
+<p> Most email is spam, and most spam is sent out by zombies (malware
+on compromised end-user computers). Wietse expects that the zombie
+problem will get worse before things improve, if ever. Without a
+tool like postscreen(8) that keeps the zombies away, Postfix would be
+spending most of its resources not receiving email. </p>
+
+<p> The main challenge for postscreen(8) is to make an is-it-a-zombie
+decision based on a single measurement. This is necessary because
+many zombies avoid spamming the same site repeatedly, in an attempt
+to fly under the radar. Once postscreen(8) decides that a client
+is not-a-zombie, it whitelists the client temporarily to avoid
+further delays for legitimate mail. </p>
+
+<p> Zombies have challenges too: they have only a limited amount
+of time to deliver spam before their IP address becomes blacklisted.
+To speed up spam deliveries, zombies make compromises in their SMTP
+protocol implementation. For example, they speak before their turn,
+or they ignore responses from SMTP servers and continue sending
+mail even when the server tells them to go away. </p>
+
+<p> postscreen(8) uses a variety of measurements to recognize
+zombies. First, postscreen(8) determines if the remote SMTP client
+IP address is blacklisted. Second, postscreen(8) looks for protocol
+compromises that are made to speed up delivery. The results of
+such measurements don't change with each delivery attempt, and are
+therefore good for making an is-it-a-zombie decision based on a
+single measurement. </p>
+
+<p> postscreen(8) does not inspect message content. Message content
+can vary widely with each delivery attempt, especially with clients
+that (also) send legitimate email. Content is therefore not good
+for making an is-it-a-zombie decision based on a single measurement,
+and that is the problem that postscreen(8) is focused on. </p>
<h2> <a name="general"> General operation </a> </h2>
logging the helo, sender and recipient information. </p>
<p> Note: postscreen(8) is not an SMTP proxy; this is intentional.
-The purpose is to keep spambots away from Postfix, with minimal
+The purpose is to keep zombies away from Postfix, with minimal
overhead for legitimate clients. </p>
<h2> <a name="quick">Quick tests before everything else</a> </h2>
<h3> <a name="pregreet"> Pregreet test </a> </h3>
<p> The SMTP protocol is a classic example of a protocol where the
-server speaks before the client. postscreen(8) detects spambots
+server speaks before the client. postscreen(8) detects zombies
that are in a hurry and that speak before their turn. This test is
enabled by default. </p>
Note that this becomes the first part of a multi-line server greeting.
The postscreen(8) daemon sends this before the postscreen_greet_wait
timer is started. The purpose of the teaser banner is to confuse
-spambots so that they speak before their turn. It has no effect on
+zombies so that they speak before their turn. It has no effect on
SMTP clients that correctly implement the protocol. </p>
<p> To avoid problems with poorly-implemented SMTP engines in network
DNSBL score is equal to or greater than the postscreen_dnsbl_threshold
parameter value, postscreen(8) logs this as: </p>
-<b>DNSBL rank</b> <i>count</i> <b>for</b> <i>address</i>
+<pre>
+ <b>DNSBL rank</b> <i>count</i> <b>for</b> <i>address</i>
+</pre>
<p> Translation: the SMTP client at <i>address</i> has a combined
DNSBL score of <i>count</i>. </p>
protocol test</a> for this is disabled by default. </p>
<p> With "postscreen_pipelining_enable = yes", postscreen(8) detects
-spambots that send multiple commands, instead of sending one command
+zombies that send multiple commands, instead of sending one command
and waiting for the server to reply. </p>
<p> This test is opportunistically enabled when postscreen(8) has
protocol test</a> for this is disabled by default. </p>
<p> With "postscreen_non_smtp_command_enable = yes", postscreen(8)
-detects spambots that send commands specified with the
+detects zombies that send commands specified with the
postscreen_forbidden_commands parameter. This also detects commands
with the syntax of a message header label. The latter is a symptom
that the client is sending message content after ignoring all the
clients that talk before their turn, and to log the helo/sender/recipient
information. This stops over half of all known-to-be illegitimate
connections to Wietse's mail server. It is backup protection for
-spambots that haven't yet been blacklisted. </p>
+zombies that haven't yet been blacklisted. </p>
<li> <p> You can also enable "<a href="#after_220">deep protocol
tests</a>", but these are more intrusive than the pregreet or DNSBL
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20100918"
+#define MAIL_RELEASE_DATE "20100923"
#define MAIL_VERSION_NUMBER "2.8"
#ifdef SNAPSHOT
/* Not: PS_PASS_SESSION_STATE. Repeat this test the next time. */
break;
default:
- msg_panic("%s: unknown pregreet action value %d",
+ msg_panic("%s: unknown blacklist action value %d",
myname, ps_blist_action);
}
}
if (msg_verbose)
msg_info("%s: cached + recent flags: %s",
myname, ps_print_state_flags(state->flags, myname));
- if ((state->flags & PS_STATE_FLAG_ANY_TODO) == 0) {
+ if ((state->flags & PS_STATE_FLAG_ANY_TODO_FAIL) == 0) {
msg_info("PASS OLD %s", state->smtp_client_addr);
ps_conclude(state);
return;
#define PS_STATE_FLAG_ANY_TODO \
(PS_STATE_FLAG_EARLY_TODO | PS_STATE_FLAG_SMTPD_TODO)
+#define PS_STATE_FLAG_ANY_TODO_FAIL \
+ (PS_STATE_FLAG_ANY_TODO | PS_STATE_FLAG_ANY_FAIL)
+
+#define PS_STATE_FLAG_ANY_UPDATE \
+ (PS_STATE_FLAG_ANY_PASS)
+
/*
* See log_adhoc.c for discussion.
*/
(dst)->pregr_stamp = PS_TIME_STAMP_INVALID; \
(dst)->dnsbl_stamp = PS_TIME_STAMP_INVALID; \
(dst)->pipel_stamp = PS_TIME_STAMP_INVALID; \
+ (dst)->barlf_stamp = PS_TIME_STAMP_INVALID; \
} while (0)
#define PS_BEGIN_TESTS(state, name) do { \
(state)->test_name = (name); \
/*
* postscreen_misc.c
*/
-extern char *ps_format_delta_time(VSTRING *, struct timeval, int *);
+extern char *ps_format_delta_time(VSTRING *, struct timeval, DELTA_TIME *);
extern void ps_conclude(PS_STATE *);
extern void ps_hangup_event(PS_STATE *);
char read_buf[PS_READ_BUF_SIZE];
int read_count;
int dnsbl_score;
- int elapsed;
+ DELTA_TIME elapsed;
const char *dnsbl_name;
if (msg_verbose > 1)
* EVENT_TIME, instead of calling ps_early_event recursively.
*/
state->flags |= PS_STATE_FLAG_PREGR_DONE;
- if (elapsed >= PS_EFF_GREET_WAIT
+ if (elapsed.dt_sec >= PS_EFF_GREET_WAIT
|| ((state->flags & PS_STATE_FLAG_EARLY_DONE)
== PS_STATE_FLAGS_TODO_TO_DONE(state->flags & PS_STATE_FLAG_EARLY_TODO)))
ps_early_event(EVENT_TIME, context);
else
event_request_timer(ps_early_event, context,
- PS_EFF_GREET_WAIT - elapsed);
+ PS_EFF_GREET_WAIT - elapsed.dt_sec);
return;
}
}
/* char *ps_format_delta_time(buf, tv, delta)
/* VSTRING *buf;
/* struct timeval tv;
-/* int *delta;
+/* DELTA_TIME *delta;
/*
/* void ps_conclude(state)
/* PS_STATE *state;
/* ps_format_delta_time - pretty-formatted delta time */
-char *ps_format_delta_time(VSTRING *buf, struct timeval tv, int *delta)
+char *ps_format_delta_time(VSTRING *buf, struct timeval tv, DELTA_TIME *delta)
{
DELTA_TIME pdelay;
struct timeval now;
PS_CALC_DELTA(pdelay, now, tv);
VSTRING_RESET(buf);
format_tv(buf, pdelay.dt_sec, pdelay.dt_usec, SIG_DIGS, var_delay_max_res);
- *delta = pdelay.dt_sec;
+ *delta = pdelay;
return (STR(buf));
}
* blacklisting. There may still be unfinished tests; those tests will
* need to be completed when the client returns in a later session.
*/
- if ((state->flags & PS_STATE_FLAG_ANY_PASS) != 0
- && (state->flags & PS_STATE_FLAG_ANY_FAIL) == 0) {
-
- /*
- * Log our final blessing when all unfinished tests were completed.
- */
- if ((state->flags & PS_STATE_FLAG_ANY_PASS) ==
- PS_STATE_FLAGS_TODO_TO_PASS(state->flags & PS_STATE_FLAG_ANY_TODO))
- msg_info("PASS %s %s", (state->flags & PS_STATE_FLAG_NEW) == 0 ?
- "OLD" : "NEW", state->smtp_client_addr);
-
- /*
- * Update the postscreen cache. This still supports a scenario where
- * a client gets whitelisted in the course of multiple sessions, as
- * long as that client does not "fail" any test.
- */
- if (ps_cache_map != 0) {
- ps_print_tests(ps_temp, state);
- ps_cache_update(ps_cache_map, state->smtp_client_addr, STR(ps_temp));
- }
+ if (state->flags & PS_STATE_FLAG_ANY_FAIL)
+ state->flags &= ~PS_STATE_FLAG_ANY_PASS;
+
+ /*
+ * Log our final blessing when all unfinished tests were completed.
+ */
+ if ((state->flags & PS_STATE_FLAG_ANY_PASS) ==
+ PS_STATE_FLAGS_TODO_TO_PASS(state->flags & PS_STATE_FLAG_ANY_TODO))
+ msg_info("PASS %s %s", (state->flags & PS_STATE_FLAG_NEW) == 0 ?
+ "OLD" : "NEW", state->smtp_client_addr);
+
+ /*
+ * Update the postscreen cache. This still supports a scenario where a
+ * client gets whitelisted in the course of multiple sessions, as long as
+ * that client does not "fail" any test.
+ */
+ if ((state->flags & PS_STATE_FLAG_ANY_UPDATE) != 0
+ && ps_cache_map != 0) {
+ ps_print_tests(ps_temp, state);
+ ps_cache_update(ps_cache_map, state->smtp_client_addr, STR(ps_temp));
}
/*
if ((state->flags & PS_STATE_FLAG_NOFORWARD) == 0) {
ps_send_socket(state);
} else {
- if ((state->flags & PS_STATE_FLAG_HANGUP) == 0)
+ if ((state->flags & PS_STATE_FLAG_HANGUP) == 0)
(void) ps_send_reply(vstream_fileno(state->smtp_client_stream),
state->smtp_client_addr, state->smtp_client_port,
state->final_reply);
void ps_hangup_event(PS_STATE *state)
{
- int elapsed;
+ DELTA_TIME elapsed;
/*
* Sessions can break at any time, even after the client passes all tests
default:
break;
}
- if ((state->pregr_stamp = pregr_stamp) == PS_TIME_STAMP_NEW
- || (state->dnsbl_stamp = dnsbl_stamp) == PS_TIME_STAMP_NEW
- || (state->pipel_stamp = pipel_stamp) == PS_TIME_STAMP_NEW
- || (state->nsmtp_stamp = nsmtp_stamp) == PS_TIME_STAMP_NEW
- || (state->barlf_stamp = barlf_stamp) == PS_TIME_STAMP_NEW)
+ state->pregr_stamp = pregr_stamp;
+ state->dnsbl_stamp = dnsbl_stamp;
+ state->pipel_stamp = pipel_stamp;
+ state->nsmtp_stamp = nsmtp_stamp;
+ state->barlf_stamp = barlf_stamp;
+
+ if (pregr_stamp == PS_TIME_STAMP_NEW
+ || dnsbl_stamp == PS_TIME_STAMP_NEW
+ || pipel_stamp == PS_TIME_STAMP_NEW
+ || nsmtp_stamp == PS_TIME_STAMP_NEW
+ || barlf_stamp == PS_TIME_STAMP_NEW)
state->flags |= PS_STATE_FLAG_NEW;
/*
/*
* Sanity check.
*/
- if ((state->flags & PS_STATE_FLAG_ANY_PASS) == 0)
- msg_panic("%s: attempt to save a no-pass record", myname);
+ if ((state->flags & PS_STATE_FLAG_ANY_UPDATE) == 0)
+ msg_panic("%s: attempt to save a no-update record", myname);
/*
* Give disabled tests a dummy time stamp so that we don't log a client
projects / thirdparty / postfix.git / commitdiff
