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 at example.org and deliver them to the vmail location for > fred at 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 fred at 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=rob at 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos