When making my "virtual_alias_maps" file, I use a SED script to convert
each virtual hostname to the several RFC2142 "role" accounts required of
each mail domain. I did not remember that the script left the
(required) virtual domain name in the file for postmap. So, now I've
just added the following line to my Makefile: "postmap -d example.com
{map_name}". All worked (and no more warning message).
However, as I noted below, a better solution was to use a non-public
name for $myorigin, and then use "smtp_generic_maps" to remap the local
"apache" mail from "apa...@private.name" to "apa...@example.com".
At least that's how I've configured it. The next mail out of apache
will tell ...
On 2017-03-23 14:54, Dean Gibson (Mail Administrator) wrote:
For the past 10 years, I've been successfully running two Postfix
(v2.2.10) servers in the following configuration:
1. At my home (ie, using a dynamic IP address) with private DNS
hostname (say) "mail.local.example.com". Here, Postfix received
mail from server #2 (below) and delivers it locally to Procmail.
Locally generated mail (eg, from root, cron, logrotate, etc) goes
to Postfix for local delivery.
2. At a VPS on the Internet (w/ static IP) and public DNS hostname
(say) "mail.example.com". Internet-destined mail (from home,
smartphone, etc) is sent to this server via port 587 and
authenticated with saslauthd.
This all worked fine for a decade.
However, I decided to move the public Postfix server to another VPS
(now using Postfix v2.6.6), and in the process change the delivery to
Procmail on the VPS host. That means that I want mail generated (eg,
from root, cron, logrotate, etc) on the home system to be "forwarded"
to the VPS host for local delivery on VPS host. There are several
such accounts, and since delivery is destined for the VPS host, they
can appear as normal incoming mail and don't need to have each sender
authenticated (although that would be nice if it's simple).
On both hosts:
* myorigin = example.com # a recent change that seems to have
started the trouble
On local host (at home):
* mydestination = $myhostname $myorigin home.example.com #
"home.example.com" maps via a dynamic DNS to the home cable box
On the VPS host:
* mydestination = $myhostname $myorigin mail.example.com.
* "virtual_alias_maps" points to a map with a large number of
virtual mail addresses (including "example.com" domains, which all
resolve to a VPS host alias map that ultimately maps to a VPS host
UNIX user account.
This all seems to work, but now I'm receiving "warning: do not list
domain example.com in BOTH mydestination and virtual_alias_domains" in
the log. I think this should be resolved before putting the finishing
touches on the "smtpd_*_restrictions".
I don't specify "virtual_alias_domains", but my guess is that it gets
implied in this situation. I guess I could move the "*@example.com"
virtual mail addresses to "aliases", but I'd like to keep all the
virtual (external) mail addresses in the "virtual_alias_maps" file,
separate from the local main addresses in "aliases".
After the move, I originally had myorigin = local.example.com (to get
around a "smtpd_sender_restrictions" configuration issue with the home
generated mail), and that seemed to work fine, except for the pesky
mails that phpBB in Apache generated (on the VPS host) to notify phpBB
users of stuff. Since the mail was sent from Apache, Apache didn't
send it with a domain name, and so the sender appeared to be
apa...@local.example.com, which of course some receiving SMTP servers
didn't like ("unknown sender domain").
Re-architecture suggestions welcome!
