On 7/10/21 6:18 pm, Rob Kampen wrote:
Hi, not sure this is the best place to go for my problem, but hoping
someone can point me to the correct or better place.
I have two currently working CentOS 7 based email servers that host a
number of virtual domains and users and delivers mail just fine - for
correctly addressed vmail inboxes AND for alias addressed emails and
domains.
These all use postfix, dovecot, amavisd, clamAV, spamassassin, mysql
(mariadb) and roundcubemail
I use port 25 for the world email delivery - no auth needed as only
accepts hosted virtual domain addressed email.
and
port 587 for user client MUA to send mail - smtp with STARTTLS auth
needed
port 993 for MUA IMAP access to account mail boxes
A couple of weeks ago I rolled up a new minimal virtual server (also
CentOS 7) and basically copied the same setup as the other two and
have now spent far too long trying to get it going.
My initial problem was that I set up mydestination to include
$mydomain - this has the consequence of seeing any mail@$mydomain as
local email and trying to deliver to the local machine rather than the
vmail inboxes.
So after setting up a new domain just for the MX we moved on.
All three installations use mysql (mariadb) as the data store for
domains, alias domains, user vmail accounts, and forwardings (virtual
alias mapping)
The mysql bits work just fine as I can send mail from an MUA client
and they deliver correctly via an authenticated session on port 587 -
i.e to any world email address AND to local vmail boxes, including
those addressed via an alias and/or alias domain.
What fails to work on the new installation, but works fine on my two
legacy servers, is mail addressed via an alias. Specifically an alias
domain. Even adding the complete alias email address to the
forwardings table doesn't work.
e.g. let's say we have an email domain '@example.com' and an alias
domain '@example.org'.
Needed so I can migrate my clients from one server to the other in a
staged manner.
Thus the new server is set up to operate as the MX for @example.org
and @example.com but needs to alias redirect the incoming emails being
sent to fred@xxxxxxxxxxx and deliver them to the vmail location for
fred@xxxxxxxxxxx (i.e. we have no vmail locations for @example.org
only for @example.com
So if I send a test email via my MUA (using port 587 and hence
authenticated) it does the alias lookups and translations needed and
correctly delivers the mail.
However if I send an email to fred@xxxxxxxxxxx from say a gmail
account, it arrives at my new server and promptly gets bounced with a
550 5.7.1 error - no such email address.
After doing diff on the main.cf and master.cf from all three servers
the only differences are the myhostname, mynetworks (new one is dual
stack IP4/IPv6 and thus includes [::1]/128), smtpd_tls certificate
names, and the virtual_uid_maps - all expected and accounted for.
master.cf are identical
Many dozens of google searches and reading far too many pages, has
left me with no idea why my new server doesn't accept alias directed
emails via port 25.
All the documentation indicates that alias lookups and translations
are performed by postfix - all the time.
receive_override_options is not set.
So, after many dozens of hours and sending test emails I have found a
solution (work around) that appears to work okay. It is now different to
the original two MX servers I cloned from, in that the maillog shows a
different cycle of processing, and it now fails a truly unknown mailbox
much later in the process - thus higher workload on my MX. But the key
thing is that it does now do the virtual_alias checks on incoming emails
on port 25 before rejecting.
No idea why this third MX is behaving differently. It has a dual stack
IP, so I disabled IPv6 access and tried again, but that certainly wasn't
the cause of the difference in processing.
It should be noted that the two initial MX machines have an extra line
in the maillog that is the second logged step in the process, and goes
something like:
Oct 8 19:00:58 mx policyd-spf[16055]: prepend Received-SPF: None
(mailfrom) identity=mailfrom; client-ip=209.85.210.180;
helo=mail-pf1-f180.google.com; envelope-from=rob@xxxxxxxxxxx;
receiver=<UNKNOWN>
After that processing steps are identical.
My work around makes the steps a little more different.
So the work around is changing master.cf
From
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - n - - smtpd
-o content_filter=spamassassin
TO
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - n - - smtpd
-o smtpd_recipient_restrictions=
-o content_filter=spamassassin
So I understand that this seems to force virtual_alias checking to
occur, and thus works for my situation where we have both user and
domain aliases in place.
No idea why my original two servers just do this check regardless and
here I have to fudge it to make it do so.
Would love to hear from someone that understands postfix better than me,
why this is needed when the servers are running same version updated of
CentOS 7 and same releases of all the packages, same main.cf and master.cf
Certainly has me stumped.
Thanks for reading, hope this may help someone else in the future.
Any suggestions of things to check or test would be welcome.
TIA
Rob
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
