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 f...@example.org and deliver them to the vmail location for f...@example.com (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 f...@example.org 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=r...@example.com; 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@centos.org
https://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Reply via email to