bouncing mail to alias) alias owner lookup. Problem reported
by William Ono. Files: local/command.c, local/mailbox.c,
local/unknown.c, local/bounce_workaround.c.
+
+20110516
+
+ Update the warning when permit_naked_ip_address is used,
+ and add permit_sasl_authenticated to the list of suggested
+ alternatives. File: smtpd/smtpd_check.c.
+
+20110601
+
+ Bugfix (introduced Postfix 2.6 with master_service_disable)
+ loop control error when parsing a malformed master.cf file.
+ Found by Coverity. File: master/master_ent.c.
+
+20110602
+
+ Bugfix (introduced: Postfix 2.7): "sendmail -t" reported
+ "protocol error" after queue file write error. File:
+ postdrop/postdrop.c.
+
+20110605
+
+ Cleanup: removed the PSC_STATE_FLAG_CACHE_EXPIRED flag.
+ Nothing uses this anymore. Files: postscreen/postscreen.h,
+ postscreen/postscreen_state.c, postscreen/postscreen_tests.c.
postscreen(8) should not be used on SMTP ports that receive mail from end-user
clients (MUAs). In a typical deployment, postscreen(8) is used on the "port 25"
-service, while MUA clients submit mail via the submission service.
+service, while MUA clients submit mail via the submission service (port 587)
+which normally requires client authentication.
postscreen(8) is part of a multi-layer defense.
applications.
Each layer reduces the spam volume. The general strategy is to use the less
-expensive defenses first, and to use the more expensive defenses for the spam
-that remains.
+expensive defenses first, and to use the more expensive defenses only for the
+spam that remains.
Topics in this document:
M\bMX\bX P\bPo\bol\bli\bic\bcy\by t\bte\bes\bst\bt
When the remote SMTP client is not on the static access list or temporary
-whitelist, postscreen(8) can implement a number of whitelist tests before it
-grants the client a temporary whitelist status to talk to a Postfix SMTP server
-process.
+whitelist, postscreen(8) can implement a number of whitelist tests, before it
+grants the client a temporary whitelist status that allows it to talk to a
+Postfix SMTP server process.
By listening on both primary and backup MX addresses, postscreen(8) can deny
the temporary whitelist status to clients that connect only to backup MX hosts
-(an old trick to take advantage of backup MX hosts with weaker anti-spam
-policies).
-
-Note 1: The status of this feature is still experimental, and implementation
-details are likely to change.
-
-Note 2: MX policy enforcement is currently supported only for domains with one
-Postfix MTA. Support for domains with multiple Postfix MTAs will have to wait
-until Postfix has a database client that can update a shared postscreen(8)
-database.
+(an old spammer trick to take advantage of backup MX hosts with weaker anti-
+spam policies than primary MX hosts).
* First, configure the host to listen on both primary and backup MX
addresses. Use the appropriate ifconfig command for the local operating
Make the rules for how to use close-on-exec more explicit.
+ Trick from amavisd: save listen socket/fifo/etc state, clear
+ their close-on-exec flags, exec the same program file to
+ re-initialize (with saved socket state on command line or
+ in environment), then restore the listen socket/fifo/etc
+ close-on-exec flags. This could be a way to mitigate the
+ impact of memory/file leaks, and to implement "postfix
+ reload" support for master(8) features that currently don't
+ support this.
+
+ postscreen: wait for DNS completion after early HANGUP
+ and log DNSBL.
+
+ Some Sendmail configurations trigger sub-optimal behavior
+ when the postscreen_whitelist_interfaces parameter lists
+ primary MX addresses only. When postscreen's "deep protocol
+ tests" are successful on the primary MX address (i.e. they
+ result in 4XX responses to RCPT TO), some Sendmail
+ configurations keep the primary MX connection open until
+ AFTER they finish talking to the backup MX address. The
+ problem is that the backup connection runs into a WHITELIST
+ VETO condition because the whitelisting database has not
+ yet been updated with the PASS NEW result for the primary
+ MX connection. Unfortunately postscreen can't update the
+ whitelisting database before the primary MX connection is
+ closed, because a client may still make a mistake.
+
+
Don't forget Apple's code donation for fetching mail from
IMAP server.
<p> <a href="postscreen.8.html">postscreen(8)</a> should not be used on SMTP ports that receive
mail from end-user clients (MUAs). In a typical deployment,
<a href="postscreen.8.html">postscreen(8)</a> is used on the "port 25" service, while MUA clients
-submit mail via the submission service. </p>
+submit mail via the submission service (port 587) which normally
+requires client authentication. </p>
<p> <a href="postscreen.8.html">postscreen(8)</a> is part of a multi-layer defense. <p>
<p> Each layer reduces the spam volume. The general strategy is to
use the less expensive defenses first, and to use the more expensive
-defenses for the spam that remains. </p>
+defenses only for the spam that remains. </p>
<p> Topics in this document: </p>
<p> When the remote SMTP client is not on the static access list
or temporary whitelist, <a href="postscreen.8.html">postscreen(8)</a> can implement a number of
-whitelist tests before it grants the client a temporary whitelist
-status to talk to a Postfix SMTP server process. </p>
+whitelist tests, before it grants the client a temporary whitelist
+status that allows it to talk to a Postfix SMTP server process. </p>
<p> By listening on both primary and backup MX addresses, <a href="postscreen.8.html">postscreen(8)</a>
can deny the temporary whitelist status to clients that connect
-only to backup MX hosts (an old trick to take advantage of backup
-MX hosts with weaker anti-spam policies). </p>
-
-<p> Note 1: The status of this feature is still experimental, and
-implementation details are likely to change. </p>
-
-<p> Note 2: MX policy enforcement is currently supported only for
-domains with one Postfix MTA. Support for domains with multiple
-Postfix MTAs will have to wait until Postfix has a database client
-that can update a shared <a href="postscreen.8.html">postscreen(8)</a> database. </p>
+only to backup MX hosts (an old spammer trick to take advantage of
+backup MX hosts with weaker anti-spam policies than primary MX
+hosts). </p>
<ul>
<p> A list of local <a href="postscreen.8.html">postscreen(8)</a> server IP addresses where a
non-whitelisted SMTP client can obtain <a href="postscreen.8.html">postscreen(8)</a>'s temporary
-whitelist status to talk to a Postfix SMTP server process. By
-default, a client can pass <a href="postscreen.8.html">postscreen(8)</a>'s whitelist tests on any
-local <a href="postscreen.8.html">postscreen(8)</a> server IP address. </p>
+whitelist status. This status is required before the client can
+talk to a Postfix SMTP server process. By default, a client can
+obtain <a href="postscreen.8.html">postscreen(8)</a>'s whitelist status on any local <a href="postscreen.8.html">postscreen(8)</a>
+server IP address. </p>
<p> When <a href="postscreen.8.html">postscreen(8)</a> listens on both primary and backup MX
addresses, the <a href="postconf.5.html#postscreen_whitelist_interfaces">postscreen_whitelist_interfaces</a> parameter can be
-used to disable whitelisting on backup MX addresses. With this
-configuration, <a href="postscreen.8.html">postscreen(8)</a> denies whitelisting status to clients
-that connect only to backup MX addresses, and prevents them from
-talking to a Postfix SMTP server process. </p>
+configured to give the temporary whitelist status only when a client
+connects to a primary MX address. Once a client is whitelisted it
+can talk to a Postfix SMTP server on any address. Thus, clients
+that connect only to backup MX addresses will never become whitelisted,
+and will never be allowed to talk to a Postfix SMTP server process.
+</p>
<p> Example: </p>
Available in Postfix version 2.2 and later:
- <b><a href="postconf.5.html#authorized_submit_users">authorized_submit_users</a> (static:anyone)</b>
+ <b><a href="postconf.5.html#authorized_submit_users">authorized_submit_users</a> (<a href="DATABASE_README.html#types">static</a>:anyone)</b>
List of users who are authorized to submit mail
with the <a href="sendmail.1.html"><b>sendmail</b>(1)</a> command (and with the privi-
leged <a href="postdrop.1.html"><b>postdrop</b>(1)</a> helper command).
.SH postscreen_whitelist_interfaces (default: static:all)
A list of local \fBpostscreen\fR(8) server IP addresses where a
non-whitelisted SMTP client can obtain \fBpostscreen\fR(8)'s temporary
-whitelist status to talk to a Postfix SMTP server process. By
-default, a client can pass \fBpostscreen\fR(8)'s whitelist tests on any
-local \fBpostscreen\fR(8) server IP address.
+whitelist status. This status is required before the client can
+talk to a Postfix SMTP server process. By default, a client can
+obtain \fBpostscreen\fR(8)'s whitelist status on any local \fBpostscreen\fR(8)
+server IP address.
.PP
When \fBpostscreen\fR(8) listens on both primary and backup MX
addresses, the postscreen_whitelist_interfaces parameter can be
-used to disable whitelisting on backup MX addresses. With this
-configuration, \fBpostscreen\fR(8) denies whitelisting status to clients
-that connect only to backup MX addresses, and prevents them from
-talking to a Postfix SMTP server process.
+configured to give the temporary whitelist status only when a client
+connects to a primary MX address. Once a client is whitelisted it
+can talk to a Postfix SMTP server on any address. Thus, clients
+that connect only to backup MX addresses will never become whitelisted,
+and will never be allowed to talk to a Postfix SMTP server process.
.PP
Example:
.PP
<p> postscreen(8) should not be used on SMTP ports that receive
mail from end-user clients (MUAs). In a typical deployment,
postscreen(8) is used on the "port 25" service, while MUA clients
-submit mail via the submission service. </p>
+submit mail via the submission service (port 587) which normally
+requires client authentication. </p>
<p> postscreen(8) is part of a multi-layer defense. <p>
<p> Each layer reduces the spam volume. The general strategy is to
use the less expensive defenses first, and to use the more expensive
-defenses for the spam that remains. </p>
+defenses only for the spam that remains. </p>
<p> Topics in this document: </p>
<p> When the remote SMTP client is not on the static access list
or temporary whitelist, postscreen(8) can implement a number of
-whitelist tests before it grants the client a temporary whitelist
-status to talk to a Postfix SMTP server process. </p>
+whitelist tests, before it grants the client a temporary whitelist
+status that allows it to talk to a Postfix SMTP server process. </p>
<p> By listening on both primary and backup MX addresses, postscreen(8)
can deny the temporary whitelist status to clients that connect
-only to backup MX hosts (an old trick to take advantage of backup
-MX hosts with weaker anti-spam policies). </p>
-
-<p> Note 1: The status of this feature is still experimental, and
-implementation details are likely to change. </p>
-
-<p> Note 2: MX policy enforcement is currently supported only for
-domains with one Postfix MTA. Support for domains with multiple
-Postfix MTAs will have to wait until Postfix has a database client
-that can update a shared postscreen(8) database. </p>
+only to backup MX hosts (an old spammer trick to take advantage of
+backup MX hosts with weaker anti-spam policies than primary MX
+hosts). </p>
<ul>
<p> A list of local postscreen(8) server IP addresses where a
non-whitelisted SMTP client can obtain postscreen(8)'s temporary
-whitelist status to talk to a Postfix SMTP server process. By
-default, a client can pass postscreen(8)'s whitelist tests on any
-local postscreen(8) server IP address. </p>
+whitelist status. This status is required before the client can
+talk to a Postfix SMTP server process. By default, a client can
+obtain postscreen(8)'s whitelist status on any local postscreen(8)
+server IP address. </p>
<p> When postscreen(8) listens on both primary and backup MX
addresses, the postscreen_whitelist_interfaces parameter can be
-used to disable whitelisting on backup MX addresses. With this
-configuration, postscreen(8) denies whitelisting status to clients
-that connect only to backup MX addresses, and prevents them from
-talking to a Postfix SMTP server process. </p>
+configured to give the temporary whitelist status only when a client
+connects to a primary MX address. Once a client is whitelisted it
+can talk to a Postfix SMTP server on any address. Thus, clients
+that connect only to backup MX addresses will never become whitelisted,
+and will never be allowed to talk to a Postfix SMTP server process.
+</p>
<p> Example: </p>
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20110501"
+#define MAIL_RELEASE_DATE "20110605"
#define MAIL_VERSION_NUMBER "2.9"
#ifdef SNAPSHOT
/*
* Skip blank lines and comment lines.
*/
- do {
+ for (;;) {
if (readlline(buf, master_fp, &master_line) == 0) {
vstring_free(buf);
vstring_free(junk);
name = cp;
transport = get_str_ent(&bufp, "transport type", (char *) 0);
vstring_sprintf(junk, "%s.%s", name, transport);
- } while (match_service_match(master_disable, vstring_str(junk)) != 0);
+ if (match_service_match(master_disable, vstring_str(junk)) == 0)
+ break;
+ }
/*
* Parse one logical line from the configuration file. Initialize service
int saved_errno;
int from_count = 0;
int rcpt_count = 0;
+ int validate_input = 1;
/*
* Fingerprint executables and core dumps.
&& rec_type != REC_TYPE_EOF)
if (rec_type == REC_TYPE_ERROR)
msg_fatal("uid=%ld: malformed input", (long) uid);
+ validate_input = 0;
errno = saved_errno;
break;
}
* the segment terminator records, there aren't any other mandatory
* records in a Postfix submission queue file.
*/
- if (from_count == 0 || rcpt_count == 0) {
+ if (validate_input && (from_count == 0 || rcpt_count == 0)) {
status = CLEANUP_STAT_BAD;
mail_stream_cleanup(dst);
}
#define PSC_STATE_FLAG_NEW (1<<3) /* some test was never passed */
#define PSC_STATE_FLAG_BLIST_FAIL (1<<4) /* blacklisted */
#define PSC_STATE_FLAG_HANGUP (1<<5) /* NOT a test failure */
-#define PSC_STATE_FLAG_CACHE_EXPIRED (1<<6) /* cache retention expired */
+/* unused */
#define PSC_STATE_FLAG_WLIST_FAIL (1<<7) /* do not whitelist */
/*
"NEW", PSC_STATE_FLAG_NEW,
"BLIST_FAIL", PSC_STATE_FLAG_BLIST_FAIL,
"HANGUP", PSC_STATE_FLAG_HANGUP,
- "CACHE_EXPIRED", PSC_STATE_FLAG_CACHE_EXPIRED,
+ /* unused */
"WLIST_FAIL", PSC_STATE_FLAG_WLIST_FAIL,
"PENAL_UPDATE", PSC_STATE_FLAG_PENAL_UPDATE,
state->flags |= PSC_STATE_FLAG_NEW;
/*
- * Don't flag a cache entry as expired just because some test was never
- * passed.
- *
* Don't flag disabled tests as "todo", because there would be no way to
* make those bits go away.
*/
- if (PSC_PREGR_TEST_ENABLE() && time_value > state->pregr_stamp) {
+ if (PSC_PREGR_TEST_ENABLE() && time_value > state->pregr_stamp)
state->flags |= PSC_STATE_FLAG_PREGR_TODO;
- if (state->pregr_stamp > PSC_TIME_STAMP_DISABLED)
- state->flags |= PSC_STATE_FLAG_CACHE_EXPIRED;
- }
- if (PSC_DNSBL_TEST_ENABLE() && time_value > state->dnsbl_stamp) {
+ if (PSC_DNSBL_TEST_ENABLE() && time_value > state->dnsbl_stamp)
state->flags |= PSC_STATE_FLAG_DNSBL_TODO;
- if (state->dnsbl_stamp > PSC_TIME_STAMP_DISABLED)
- state->flags |= PSC_STATE_FLAG_CACHE_EXPIRED;
- }
- if (var_psc_pipel_enable && time_value > state->pipel_stamp) {
+ if (var_psc_pipel_enable && time_value > state->pipel_stamp)
state->flags |= PSC_STATE_FLAG_PIPEL_TODO;
- if (state->pipel_stamp > PSC_TIME_STAMP_DISABLED)
- state->flags |= PSC_STATE_FLAG_CACHE_EXPIRED;
- }
- if (var_psc_nsmtp_enable && time_value > state->nsmtp_stamp) {
+ if (var_psc_nsmtp_enable && time_value > state->nsmtp_stamp)
state->flags |= PSC_STATE_FLAG_NSMTP_TODO;
- if (state->nsmtp_stamp > PSC_TIME_STAMP_DISABLED)
- state->flags |= PSC_STATE_FLAG_CACHE_EXPIRED;
- }
- if (var_psc_barlf_enable && time_value > state->barlf_stamp) {
+ if (var_psc_barlf_enable && time_value > state->barlf_stamp)
state->flags |= PSC_STATE_FLAG_BARLF_TODO;
- if (state->barlf_stamp > PSC_TIME_STAMP_DISABLED)
- state->flags |= PSC_STATE_FLAG_CACHE_EXPIRED;
+
+ /*
+ * If any test has expired, proactively refresh tests that will expire
+ * soon. This can increase the occurrence of client-visible delays, but
+ * avoids questions about why a client can pass some test and then fail
+ * within seconds. The proactive refresh time is really a surrogate for
+ * the user's curiosity level, and therefore hard to choose optimally.
+ */
+#ifdef VAR_PSC_REFRESH_TIME
+ if ((state->flags & PSC_STATE_MASK_ANY_TODO) != 0
+ && var_psc_refresh_time > 0) {
+ time_t refresh_time = time_value + var_psc_refresh_time;
+
+ if (PSC_PREGR_TEST_ENABLE() && refresh_time > state->pregr_stamp)
+ state->flags |= PSC_STATE_FLAG_PREGR_TODO;
+ if (PSC_DNSBL_TEST_ENABLE() && refresh_time > state->dnsbl_stamp)
+ state->flags |= PSC_STATE_FLAG_DNSBL_TODO;
+ if (var_psc_pipel_enable && refresh_time > state->pipel_stamp)
+ state->flags |= PSC_STATE_FLAG_PIPEL_TODO;
+ if (var_psc_nsmtp_enable && refresh_time > state->nsmtp_stamp)
+ state->flags |= PSC_STATE_FLAG_NSMTP_TODO;
+ if (var_psc_barlf_enable && refresh_time > state->barlf_stamp)
+ state->flags |= PSC_STATE_FLAG_BARLF_TODO;
}
+#endif
/*
* Gratuitously make postscreen logging more useful by turning on all
state->helo_name, SMTPD_NAME_HELO);
}
} else if (strcasecmp(name, PERMIT_NAKED_IP_ADDR) == 0) {
- msg_warn("restriction %s is deprecated. Use %s instead",
- PERMIT_NAKED_IP_ADDR, PERMIT_MYNETWORKS);
+ msg_warn("restriction %s is deprecated. Use %s or %s instead",
+ PERMIT_NAKED_IP_ADDR, PERMIT_MYNETWORKS, PERMIT_SASL_AUTH);
if (state->helo_name) {
if (state->helo_name[strspn(state->helo_name, "0123456789.:")] == 0
&& (status = reject_invalid_hostaddr(state, state->helo_name,
projects / thirdparty / postfix.git / commitdiff
