Postings by Michael Fox

SSL_accept error on just one of several similar servers

I have several Postfix servers with virtually identical configurations.
That is, they have their own hostnames, IP addresses, etc. But the rest of and and various *_access, etc. files are the same.

I recently started having a problem with SSL_accept errors on just one of
the machines. Several people report (including me) that from the same
Thunderbird client, we can connect to all of the other servers and send a
message. But when we try to connect and send to the one server, it fails.

The Thunderbird client displays: "Sending of the message failed.

Header-Name: capitalization

I'm working on a milter that checks for certain headers. The RFCs specify
header names with specific capitalization. For example: "Message-ID". I
don't see anything the RFCs that indicates that alternate capitalization
should be accepted, such as "Message-Id". But perhaps I missed it.

So, I wonder: is it safe to match ONLY on the exact capitalization specified
in the RFCs, or should header name matching be done in a case-insensitive



RESOLVED: RE: wrong From: and Return Path: address

This problem turned out to be a DNS issue. The Postfix 3.1.0 machine's
virtual domain in the From: address was entered in DNS with a CNAME record
pointing to the gateway machine (because they are, indeed, the same

wrong From: and Return Path: address

I have a problem that seems to have started when I upgraded from Ubuntu
14.04/Postfix 2.11.0 to Ubuntu 16.04/Postfix 3.1.0. It involves the From:
and Return Path: addresses seen by recipients of mail sent from a virtual
domain on that machine.

Clients of Google, Yahoo, Rackspace, . see the From: and Return Path:
address as <user>@<virtual-domain>, which is correct.
Clients of one (rather large) email service provider see the From: and
Return Path: address as <user>@<gateway-hostname>, which is wrong.

The one email provider might have something wrong on their end.

chroot setting in

I'm configuring to add amavisd-new. The amavisd-new documentation
(/usr/share/doc/amavisd-new/README.postfix.html) differs from the default file regarding the chroot setting for the cleanup (and
pre-cleanup) service. I presume that the amavisd-new documentation is in
error and that I should go with the chroot setting that's in the default But I don't know enough about the implications of one vs. the
other to be sure.

Specifically, I have three questions:

1) Section 4.2.1 of the above web page shows adding a pre-cleanup service
with chroot=n.

reloading postfix with systemd

In v16.04 LTS, Ubuntu has switched to systemd.

"postfix reload" still seems to work just fine.
But I wonder if I should be using "systemctl reload postfix" instead.

Which method is preferred on systems that use systemd?
And if either method works, are there differences or reasons to prefer one
over the other?


postfix check warnings on new Ubuntu 16.04 install

I'm building a new 16.04 machine using the distro package for postfix
(v3.1.0). The and files are still at defaults.

I ran "postfix check" and it's listing warnings about some library files.
This didn't happen on Ubuntu 14.04.

I don't understand what it's trying to tell me or what I need to do about
it. The output is below.

simultaneous sessions from old client

I've got some very old clients that takes a message to multiple recipients
at the same destination domain and separates the TO recipients and the CC
recipients into two messages and then sends them separately.

checking file references

Is there a command that can check if all files referenced in are
present? Currently, if my manual/visual review misses something, I don't
find out until postfix tries to process a message and discovers the missing

postfix check doesn't do this.



milter to decode quoted-printable, base64, ...

I've got some clients that are really simple and don't understand various
message encoding types, such as quoted-printable, base64, possibly others.
They understand plain text only. So, for users in specific domains, I'd
like to convert quoted-printable, base64 and possibly other encoded messages
to plain text.

I presume I need a content-filter to perform this work post-queue.

I looked here: <a href="" title=""></a>

. but didn't see anything that addresses the issue. Any ideas would be



generic files

I've got several postfix systems which all have the same configuration
except for a few host-specific parameters like:
-- myhostname
-- mynetworks
-- mydestination
-- myorigin
-- inet_interfaces
-- proxy_interfaces
-- relay_domains
-- virtual_mailbox_domains

Typically, I copy the to another machine and edit the host-specific
values. What would be nice is to have a generic that can be copied
to any machine and which references all host-specific values in external

smtpd_relay_restrictions clarification

Moving from a pre-v2.10 to post-v2.10 environment, I'd like make sure I
understand the meaning/context of smtpd_relay_restrictions.

How to restrict encrypted email

I'd like to be able to reject mail that contains encrypted content. This is
to satisfy US FCC rules against encrypted content on amateur radio
frequencies. Some of our clients may connect via amateur radio.

I'd like to be able to restrict it only for certain clients. But, as I
understand it, header checks can only be applied globally, to all mail.

Sorry if this is a dumb question. But, unfortunately, I don't have any
experience with encrypted mail.

auth/tls combinations sanity check

I have a possibly unusual AUTH/TLS combination requirement. As a newbie, I
could use a sanity check.

* All virtual mail clients will use SASL AUTH
* Virtual mail clients on specific internal networks MUST NOT be offered
TLS. This is to satisfy FCC requirements prohibiting the use of encryption
on certain radio frequencies.
* Other virtual mail clients on internal networks may choose to use TLS or
not. (Some simple network appliances don't support TLS at all, or don't
support STARTTLS)
* Virtual mail clients from external networks (outside the firewall) MUST
use TLS.

smtpd_sasl_security_options clarification

<a href="" title=""></a> says "the
following security features are defined for the cyrus server .". Dovecot is
not mentioned. So, is it correct to interpret this to mean that this
postfix setting is a noop when dovecot is used for sasl authentication?

And how does Postfix know which authentication mechanisms to offer the
client? Does dovecot communicate this to postfix somehow?




I'm confused about how the reject_sender_login_mismatch restriction works.


Reject the request when $smtpd_sender_login_maps
<> specifies
an owner for the MAIL FROM address, but the client is not (SASL) logged in
as that MAIL FROM address owner; or when the client is (SASL) logged in, but
the client login name doesn't own the MAIL FROM address according to
<> ."

I also tried "reject_authenticated_sender_login

how to prevent MX lookup of virtual_mailbox_domain

I have defined:

virtual_alias_maps = hash:/etc/postfix/virtual

virtual_mailbox_domains = my.virtual.domain (sanitized)

virtual_mailbox_maps = hash:/etc/postfix/vmailbox

virtual_transport = lmtp:unix:private/dovecot-lmtp

I'm still testing/configuring locally, so I haven't created the DNS MX
record for my.virtual.domain yet.

When a client submits a message to a mailbox in that domain
( ... at my dot virtual.domain), I get the following in /var/log/mail.log

Jun 30 20:12:31 myhost postfix/submission/smtpd[28379]: warning: Unable to
look up MX host for my.virtual.domain: Host not found, t

Newbie SASL Auth with Dovecot problem

I've been using Postfix for a while with no client submission.

RBLs in postscreen AND smtpd_*_restrictions

I think I recall seeing something about this a while ago, but I can't find
it in the archives.

If I'm using several RBLs in postscreen_dnsbl_sites, each with its own
weighting, then what is the best practice for using at least some of those
RBLs in smtpd_*_restrictions, or not?



Need clarification of lookup table result values

I need some help understanding the valid "result" values that can be used in
Postfix lookup tables and what the result values do. The examples I see in
various places in the docs seem to contradict each other.

As just one example, I'd like to configure postscreen_access.cidr.

postscreen vs. fail2ban

I haven't implemented postscreen yet, but plan to. So this question is for
the postscreen experts here.

As I understand it from the documentation, postscreen protects postfix from
having to deal with most attack vectors, including higher volume attacks.
So, does it make sense to also use something like fail2ban to block IPs that
postscreen (or postfix) logs repeatedly as offenders? Or is postscreen
sufficient to protect posfix?

Thanks much,


Recipient address rejected: Domain not found

I have a question about the situation where postfix receives a connection
from a client trying to send to an invalid recipient address such as
<a href="mailto: ... at nohow dot"> ... at nohow dot</a>.

Currently, postfix responds with:

450 4.1.2 < ... at nohow dot>: Recipient address rejected: Domain not

What seems reasonable to me is the following:

-- If postfix receives a response from DNS that the domain does not exist,
then reject with 550

-- Otherwise, delay with 450 (DNS failure, etc.)

<a href="" title=""></a> says one
can use unverified_recipient_reject_co

header checks for a relay client

Sanity check please:

I have a relay machine:

And a client:

I'd like to filter (silently discard) messages at the relay machine from
going to any account on the client machine if the From: address is:
<a href="mailto: ... at yahoogroups dot com"> ... at yahoogroups dot com</a> <mailto: ... at yahoogroups dot com> .

Restricting relay of attachments

Sorry if this is a bit simple, but I can't seem to figure out how the
components fit together.

Given the following:

1) MX/Relay machine running postfix:

2) Client machine:

I'd like to restrict/deny (5xx permanent error) incoming messages from the
Internet to if they contain attachments. But no such
restriction should be applied to other clients or to users on

I presume this would be done with some type of header check plus some type
of restriction class.

Need help with canonical maps

I'm having difficulty getting the canonical_maps function to work as needed
to repair some incorrect addresses from a legacy client. Here's the
situation and what I've tried so far:

Legacy client ( does not append its domain (
to addresses in the envelope or the message when sending them via SMTP. So,
if the user on oldhost types an address such as "user@oldhost", it goes out
with SMTP as "user@oldhost" instead of " ... at oldhost dot".

A machine with postfix ( has a different domain
( from the legacy machine.