On 11/10/21 2:06 pm, Rob Kampen wrote: > OK - just to let you know the munge I used. > > example.com is an alias domain for example.org which is the actual > domain with Maildir space on the server. > > rob@ is alias for rkampen@ thus the only real address is > rkampen at example.org That's not what I meant by munge, but it helps. Anyhow, what you showed me is what I need to see. > now the results This is all good, except... > [root at mx rkampen]# postmap -q @example.com > mysql:/etc/postfix/mysql-virtual_forwardings.cf > @example.org This is a bad idea. It's not the cause of your problem (as you discovered below) but it will lead you to become a backscatter source. I'll explain. Postfix checks virtual_alias_maps entries twice, once in smtpd and once in cleanup (actually trivial_rewrite, which is called from cleanup). At the smtpd stage it simply checks to make sure that there is a virtual_alias_map entry for the recipient address, but it doesn't care where that entry points, then (after other checks) postfix accepts and queues the message. The message is then passed to cleanup, which, as once of its functions, calls trivial_rewrite which, once again, checks virtual_alias_maps and in turn rewrites the recipient to the target email address. (It then loops and does this until there are no more rewrites to be done). Then delivery is attempted to the target address. So in your case, what happens when the original recipient is "nonexistent at example.com"? Well Postfix first checks virtual_alias_maps for entries of "nonexistant at example.com", "nonexistent" and "@example.com", it finds a match for the last of these and so the message passes the checks in smtpd and the message is accepted for delivery and queued. Then the message is passed to cleanup which checks with trivial_rewrite and trivial_rewrite checks virtual_alias_maps (again) and after finding the "@example.com" entry it rewrites the recipient to "nonexistent at example.org". Then Postfix attempts to deliver the message to nonexistent at example.org, but since there's no such recipient and since postfix has already accepted the message for delivery it generates a bounce message which it sends to the envelope sender. Thus you have a situation where messages can be sent to invalid recipients and your system will bounce them, and as such you become a source of backscatter. You can confirm this by attempting to send a message to nonexistent at example.com and another one to nonexistent at example.org. The example.com one will generate a bounce from Postfix while the example.org one will reject the message instead (you'll be able to see the difference in your Postfix logs). The solution here is to not use an @example.com entry in virtual_alias_maps, but instead to have a separate entry for each valid recipient in example.com. Since you're using mysql it is possible to craft a mysql query that can check the valid example.org recipients and only return example.com matches for those recipients, I'll leave that as an exorsize for you, but if you have problems with it I'll be happy to help. > Well that may have done it! > > Now I get a correctly sent email with the alias substitutions done. > Funny how that line seems to cause no error on my two original MX - > looks like I better check them out a little more too. That's great. So basically what you've done by removing that entry is to bypass the policyd-spf check from Postfix. What that means is that the problem is in policyd-spf and this is further confirmed by the following log entry: > Oct 11 13:53:10 mx policyd-spf[10723]: ERROR: Unknown name "TestOnly" in > file "/etc/python-policyd-spf/policyd-spf.conf" Unfortunately I am not a policyd-spf expert by any stretch, so at this stage I'll direct you to their community support for further help (unless someone else here wants to chime in and help). What I can say is that if you fix your policyd-spf issue then it is likely that you can add that entry back into the Postfix configuration and it will work. > Thanks Peter, your help has been invaluable and MUCH appreciated! You're quite welcome. Peter