Postings by Victor Duchovni

Re: "default_transport" not working in all cases

Subdomains of domains in mydestination are by default relay domains.
Set "relay_domains = " (empty) if you have no relay domains. For
relay_domains, Postfix uses "relay_transport".

This type of fuzzy "like" query is highly questionable in this context.
What's wrong with "="? Why match both "%s" and "%d"?

Postfix 2.8 not alone in enabling ECDHE ciphers.

The Postfix 2.8 SMTP server will not be alone in enabling server-side
Elliptic Curve Diffie-Hellman key-agreement.

Hosted domains served by (e.g.
have ECDHE ciphers enabled:

Trusted TLS connection established to[]:25:
TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

Ditto with (e.g.

FrontBridge RFC 2920 write-up

Wietse, is this sufficient? I know it is not very detailed on the
"impact analysis". Since pipelined "[message]<CRLF>.<CRLF>QUIT<CRLF>"
works correctly, while in theory there could be other pipelining issues,
none other that SAV come to mind.

The SMTP service at does not fully conform
to RFC 2920 which defines the ESMTP PIPELINING extension.

Documentation patch: Re: postmap -q and ldap

Index: proto/LDAP_README.html
*** proto/LDAP_README.html 6 Feb 2010 07:34:26 -0000
--- proto/LDAP_README.html 24 Jun 2010 17:14:50 -0000
*** 336,342 ****
search_base = dc=example, dc=com
query_filter = mail=%s
result_attribute = memberaddr
! $ postmap -q <a href="mailto: ... at example dot com"> ... at example dot com</a>
... at example dot org, ... at example dot org
--- 336,342 ----
search_base = dc=example, dc=com
query_filter = mail=%s
result_attribute = memberaddr

Thread closed: Debian argument.. postfix hostname

This thread is over I think...

Testing Postfix EECDH support with OpenSSL 1.0.0

I've recently enabled Ephemeral Elliptic Curve Diffie-Hellman (EECDH)
key exchange on our inbound Postfix servers (Postfix compliled and linked
with OpenSSL 1.0.0), by setting:

smtpd_tls_eecdh_grade = strong

Counting recently logged ciphers yields:

33258 DHE-RSA-AES256-SHA
13126 RC4-SHA
3976 RC4-MD5
2972 ADH-AES256-SHA
1620 AES128-SHA
320 AES256-SHA
---> 302 AECDH-AES256-SHA
---> 18 ECDHE-RSA-AES256-SHA


OpenSSL 0.9.8 <-> 1.0.0 CApath (in)compatibility

Postfix works fine when compiled and linked with OpenSSL 1.0.0.

However, when migrating from OpenSSL 0.9.8 to OpenSSL 1.0.0, there is
a potential (in)compatibility issue with CApath directories.

If you use a "CApath" to store root CA certificates for either the Postfix
SMTP client or the Postfix SMTP server, be aware that the hash value of
the issuer DN is computed differently by OpenSSL 1.0.0, and a CApath
directory hashed with OpenSSL 0.9.8 utilities will not be usable by
software compiled with 1.0.0 libraries.

Conversely, if you use the OpenSSL 1.0.0 c_rehash (your PATH must include

THREAD END: (was: How to not reject valid MTAs for inconsistent forward/reverse DNS.)

This non-Postfix "discussion" has soaked up enough postfix-users list
cycles. Please drop it, or take it somewhere else. Thanks.

How to not reject valid MTAs for inconsistent forward/reverse DNS.

Don't use "reject_unknown_client_hostname" indiscriminantly. Do so only for
CIDR blocks in which you find a small number of legitimate MTAs in a larger
pool of spam sending hosts without valid PTR records.
smtpd_client_restrictions =
check_client_access cidr:${config_directory}/client_access.cidr

client_access.cidr: reject_unknown_client_hostname
# More conservative:
# reject_unknown_reverse_client_hostname

Postfix does not by default reject clients with mismatched forward/reverse

THREAD STILL CLOSED: (was Re: multiple PTR records)


If you have a specific use case in which you need guidance to configure
Postfix, please start a new thread, without the polemics.

If you just want to vent, please do it somewhere else.

THREAD CLOSED: (was Re: multiple PTR records)

You write the code, deploy it on your systems, and suffer the consequences.

Just start the other thread if it is on topic. No point in starting
a flame war instead.


END OF THREAD: How to override an MX value for a particular domain only?

Sorry, we are taking up too much time from all the people reading this
busy list. The files may be needed late, under circumstances we cannot
control. Best practice is to copy all the files that may be needed late
depending various system factors.

Let's close the thread here....

Caching TLS connections (XSTOPTLS)

I'd like to propose a Postfix-specific ESMTP feature that would
enable the caching of TLS connections by disabling crypto on
the session before putting it into the cache, and re-enabling
crypto right after.

S: 220 ESMTP
S: 220 2.0.0 Ready to start TLS
S: <SSL handshake ...>
S: 250 XSTOPTLS <--- new ESMTP feature!
C: MAIL FROM:< ... at example dot com>
C: RCPT TO:< ... at example dot com>

FYI: Imminent closure of SORBS...

----- Forwarded message from Michelle Sullivan < ... at sorbs dot net> -----


Please feel free to forward this message to any other location/mailing

It comes with great sadness that I have to announce the imminent closure of

END OF THREAD: Re: "nobody is going to write a new MTA"

Way off topic. Lets stop here please...

THREAD CLOSED (was: Re: Postfix Setup)

Let's end the thread here. :-) Hopefully the OP is trying to make sense of
the documentation he was pointed to, consulting a Postfix book (O'Reilly
or No Starch) and will start a new thread with any specific questions
that arise.

Gentoo: "cert already in hash table" error

Summary: Some Gentoo systems have 2 (related) CA certs in one of the
files in the standard root CA bundle, one of the CAs is listed separately
in another file. This leads to problems where the same trusted root is
loaded twice.

Working with a poster to the OpenSSL-users list, this was resolved today:

<a href=";m=123721072930382&amp;w=2" title=";m=123721072930382&amp;w=2">;m=123721072930382&amp;w=2</a>

there was a previous unresolved report of the same issue misdirected
to postfix-devel:

<a href="" title=""></a>

This post is for the archives.

Second candidate documentation update: smtp_tls_CAfile

How about this version?

Index: proto/TLS_README.html
*** proto/TLS_README.html 25 Feb 2009 04:38:56 -0000
--- proto/TLS_README.html 25 Feb 2009 17:33:17 -0000
*** 266,276 ****
clients without special cipher choices, the RSA certificate is
preferred. </p>

Candidate documentation update: smtp_tls_CAfile

Index: proto/TLS_README.html
*** proto/TLS_README.html 25 Feb 2009 04:38:56 -0000
--- proto/TLS_README.html 25 Feb 2009 17:33:17 -0000
*** 266,276 ****
clients without special cipher choices, the RSA certificate is
preferred. </p>

! <p> In order for remote SMTP clients to check the Postfix SMTP
! server certificates, the CA certificate (in case of a certificate
! chain, all CA certificates) must be available. You should add any
! intermediate CA certificates to the server certificate: the server
! certificate first, then the intermediate CA(s). </p>

active -> incoming migration (was: Re: postfix queue grep)

Yes, this solves the queue-manager reload problem, because the active
queue is empty when the queue-manager reloads. In the new scenario,
the active queue is not empty, and an active file is "surreptitiosly"
moved (multiple quick steps) to "incoming". If all the recipients
are at busy destinations, there may not (yet) be any delivery agent
locks, and the file could enter the queue a second time.

Is this possible?

PATCH: 2.5.6 scheduler feedback parameter names (was: Defer Retry)

Index: src/global/mail_params.h
--- src/global/mail_params.h 28 Jul 2008 18:27:05 -0000
+++ src/global/mail_params.h 30 Jan 2009 05:04:06 -0000
@@ -2899,12 +2899,12 @@
* Scheduler concurrency feedback algorithms.
#define VAR_CONC_POS_FDBACK "default_destination_concurrency_positive_feedback"
-#define _CONC_POS_FDBACK "_concurrency_positive_feedback"
+#define _CONC_POS_FDBACK "_destination_concurrency_positive_feedback"
extern char *var_conc_pos_feedback;

#define VAR_CONC_NEG_FDBACK "default_destination_concurrency_negative_feedback"

END OF THREAD: was: Aliases question - can I alias a user name to a name that is not a local user account?

No fights on this list please, we are busy enough with useful discussion.
Further posts along these lines will result in the termination of the
poster's subscription. Some humility when joining an established
community is appropriate: when in Rome, do as the Romans do. Thanks.

This thread is closed.

Re: Plugging in a multi-instance manager

Indeed, and with Wietse's modular design, you can plug in an instance
manager that does that. Is this a sound enough idea to include as
a standard feature in the (under construction) postmulti(1) manager?

I would assume " ...", when found, runs instead of "postfix
-c $confid_directory ...", rather than before it. It becomes the
responsibility of to actually start/stop/... the instance.

I am somewhat concerned that this is too much rope.

Plugging in a multi-instance manager

Or which automatically runs "" in an instance's directory,
if it's present, with a "start" or "stop" argument. I have found this
very useful.

FYI: Secure-channel TLS from Exchange 2007 to Postfix

In Exchange 2007 it is possible to configure selected destinations
for "Domain Secured" email, this is approximately equivalent to the
Postfix "secure" setting.

End of thread (OT: RFC normative verbs)

You're welcome. I think we can close this thread now.

Postfix does not dot the i's when client sends gibberish

This is not a bug, but it is admittedly an unecessary deviation from
SHOULD normative language in the RFC when the client is in flagrant
violation by sending garbage.

If you need RFC conformance for invalid client commands, here's a patch
that works for the latest 2.6 snapshot, and likely also for 2.5.5.

Message-id logging (include rfc822-comments?)

When a message-id is followed by rfc822 comment text:

Message-Id: <test@test> (test)

2008-11-06T13:13:35-0500 amnesiac postfix/cleanup[10832]: AF24675A3D:
message-id=<test@test> (test)

postfix logs both the "id" and the "comment". This is perhaps more
"robust", in case the header is mangled, and most of the unique data
is in the comment.

libspf2 Vulnerability [from another list...]

All libspf2 users should read this post by Dan Kaminsky, and upgrade
libspf2 to 1.2.8 as soon as possible:

<a href="" title=""></a>

Just in case anyone asks, and not surprisingly, the DNS code in Postfix
has no such lapses.