Postings by martin f krafft

Authenticating clients based on CA/CN-match


As far as I can tell, postfix can authenticate its clients using
certificates in two ways:

check_ccert_access (also permit_tls_clientcerts), which
authorizes clients based on the cert fingerprint;

permit_tls_all_clientcerts, which authorizes clients if they
present a cert signed by a specific CA;

We've been using the former for years, requiring us to manually
deploy the new fingerprints every two years.

Despite greylisting result, recipient restrictions still run


I am doing greylisting in smtpd_client_restrictions and later
a policy server check in smtpd_recipient_restrictions (postconf
included below). smtpd_delay_reject is on (the default).

The weird behaviour I am seeing is that despite a greylisting match
(4xx) in sender restrictions, the recipient restrictions are still
all being evaluated.

postscreen and smtpd chroot

Hey folks,

thanks to a hint on IRC, I started experimenting with postscreen(8)
to fend off some hefty zombie attacks.

I can't help but notice that

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

suggests to disable the chroot on all new services, and notably
smtpd. Also, all socket paths (e.g. milter) have to be updated.

Is this necessary? postscreen seems to work fine with all these
services chrooted…

I know chroots are not a reliably security enhancement, but I don't
need to turn them off either if they're working.

What's the rationale here?

sender_canonical_maps not matching


we are trying to solve a mail problem on the New Zealand Red Cross
mail server, which is sending confirmation messages for earthquake
donations from an invalid address, e.g.

postfix/smtp[26060]: 44B9C100CA13: to=< ... at madduck dot net>,[]:25, delay=10,
delays=0.01/0/6.8/3.3, dsn=4.1.8, status=deferred (host[] said: 450 4.1.8
<www- ... at rredxprdww02 dot>: Sender address rejected:
Domain not found (in reply to RCPT TO command))

I wanted to approach this using a canonical rewriting map:


static map returns 554, causing message to be accepted

Dear list,

I found that a lot of spam can be weeded out by rejecting clients
who greet me with my own hostname. Initially, I achieved this with
the following:
smtpd_helo_restrictions =
check_helo_access pcre:$config_directory/reject_helo_myhostname

/^myhostname(\.mydomain)?$/ 554 do not impersonate me

I then ran into problems when the host connected to itself through
the loopback interface.

postmap -q and address extensions

Hello list,

I am finding that

postmap -q address+ ... at domain dot com pgsql:/etc/postfix/virtual_mailbox_maps

does not return a result, while the address without the extension
works fine. Is this expected behaviour?

Log the applied TLS policy

Dear list,

We are using $smtp_tls_policy_maps, in addition to
$smtp_tls_security_level==may. Hence, the machine opportunistically
uses TLS, while the policy ensures that certain destinations are
protected by trusted and secure channels.

Due to some issues we've been having[0], I would like to have a more
permanent means of confirmation that everything is in order.
Specifically, I would like to see in the logs when a security policy
was matched and applied.

Lookup key of smtp_tls_policy_maps

Dear list,

I would be grateful for some input and confirmation about how
smtp_tls_policy_maps works. The documentation are a bit obscure on
the matter, and the results of my experimentation aren't perfectly
clear to me.

I found that smtp_tls_policy_maps is not necessarily indexed by the
"next-hop destination": in cases when there is no explicit next-hop
defined in $transport_maps or $relayhost (and hence DNS would be
asked for the MXs), the policy map is searched for the recipient's
domain instead.

how not to send a message?

Dear postfix people,

I just sent a message I should not have sent, using my local postfix
setup, which forwards to a smarthost for further processing.

After sending the message, I almost immediately pulled the plug, and
looking at mailq, I felt good about that:

-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
3DE8FEF5 5142 Tue Feb 16 13:48:14 <a href="mailto: ... at lapse dot"> ... at lapse dot</a>
<a href="mailto: ... at gmail dot com"> ... at gmail dot com</a>

-- 5 Kbytes in 1 Request.

So I removed it:

% sudo postsuper -d 3DE8FEF5
postsuper: 3DE8FEF5: removed
postsuper: Deleted: 1 m

Distro Summit 2010: call for papers extended until 18 Oct 2009

Please redistribute this call for papers.

The deadline has been extended to 18 Oct 2009.


Distro Summit 2010 is a one-day technical conference with a strong focus on
collaboration between Free Software distributions hosted at the

We are looking for proposals from any Free Software distribution, from the
typical full distributions (both linux and non-linux) to the niche market

In spite of the strong focus on collaboration between Free Software
distributions, topics may include packaging, maintenance, relationsh

header/body_checks as end-of-data checks (was: how to bypass milters, whitelist hosts)

also sprach Wietse Venema < ... at porcupine dot org> [2009.05.23.1442 +0200]:

What about header/body_checks? Those would make sense in
smtpd_end_of_data_restrictions, wouldn't they? What am I missing to
understand why they aren't? Is it the fact that those checks should
apply to all mail processed by postfix, whether received by smtpd or

delivering mail to one host to another port

I need to deliver mail to the primary MX of several hundred domains
via a different port. Unfortunately, putting the MX's address or IP
into the transport map does not seem to work. I'd prefer not to
maintain the list of domains in the transport table as well, so I am

Is it possiblew to instruct postfix to always deliver to a different
port when it tries to connect to a specific machine?


how to bypass milters, whitelist hosts


how can I bypass smtpd_milters for certain hosts?

I have asked a related question previously [0], and the only
solution seemed to be to redirect those hosts to a different smtpd
instance, but unfortunately, Linux cannot redirect IPv6 connections
yet (TPROXY is in preparation).

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

Is there another way to approach this?

Why are header_checks/body_checks/smtpd_milters not regular
restrictions, which I could put into smtpd_end_of_data_restrictions
after a whitelist?


making the permit_mx_backup decision (was: permit_mx_backup_networks and IPv6)

also sprach martin f krafft < ... at madduck dot net> [2008.09.03.1226 +0100]:

I think this is a separate issue to the one I raised in
<a href="" title=""></a>.

For an MX like with A and AAAA records, shouldn't
it be enough to list only the IPv4 or the IPv6 address in
permit_mx_backup_networks to make the relay happy? Shouldn't postfix
check both address classes? I see no reason why it should completely
ignore IPv4 when an AAAA record is served.