Well, hello, there!

You want outbound routing.   No, it does not exist, but it has been requested.

But if you need it now, you need to be willing to build it yourself.  Some options:

Migrate listname@example.com to listname@lists.example.com.   After the old list is removed, you should be able to create an alias that redirects listname@example.com to listname@lists.example.com transparently.  Removing the old list means that you will lose its archive.    SmarterMail may be able to provide some custom services to help with the transition.

Create your outbound routing solution using PostFix on Linux.   I don't know how, but I have read some of the documentation, enough to be both impressed and overwhelmed.   MailsBestFriend.com has built some PostFix experience, and they know SmarterMail well, so it would be worth making an inquiry.

Use domain forwarding to split your domain across two servers.   One server has the users and one has the mailing lists.   The caveat is that non-existent recipients might bounce back and forth a lot.   Many systems have loop detection for this problem, but I don't what loop detect controls are in SmarterMail.

Use two outbound gateways running SmarterMail Free with Declude or Declude Reboot.    When the MailFrom address is one of your mailing lists, move the .HDR and .EML files from the Spool\Proc folder on Server1 to the Spool\Proc folder on server2.   Untested concept, but It seems likely to work.

However, you need to be aware of the limitations.   These workarounds can support your plan to get AWS to allow the traffic to escape, but it does not guarantee that the traffic will be received.   Mailing Lists assume that evaluating systems will tolerate impersonation, and this is no longer a safe assumption.  Some options, none that are entirely satisfactory:

1) Require that potential subscribers have mail system which apply DKIM signatures to all outbound mail, and then ensure that you don't break DKIM signatures during mailing list processing.

2) Require that potential subscribers do not have a DMARC policy with p=reject or p=quarantine.  This will maximize the chance that a receiving system will ignore the impersonation implied by the mailing list message.

3) Require that potential subscribers work with their support organizations to trust messages from your mailing list.

4) Obtain a customizable mailing list manager application that can do conditional rewrite of the From address.   For example if the sending domain requests DMARC enforcement (quarantine or reject), and the receiving domain applies DMARC enforcement, then rewrite the From address to user=domain@lists.example.com or something similar.

5) Take your chances, while directing subscribers to add the list address to their contacts folder, and to mark list messages as Not Spam if they do end up in the Spam folder.

I apologize for my first response in which I inquired of a completely useless solution for your problem.  I missed this bit (I am blaming the Community's habit of ignoring my PgUp/PgDn key presses.)

Building upon Douglas Foster's intricate solutions, I will say this is just a Bad Idea(tm) and you are going to have to advise your customer.  You have already experienced one of the problems.  The other is addressed by Douglas in the handling of DKIM, and then DMARC and, in addition, SPF records specifying your list server in subscriber's records.  This is a pretty hefty burden on your subscribers, many of whom may not even have that kind of control.

Another question is, "why?"  Agreeing with Douglas' explanation, this how some listservs were done in the 90s and 00s, but I propose this is not practical in today's email environments (which are meant to prevent exactly what you are intended to do.)

As well, there simply is no need to rewrite the FROM: address as that of a poster.  Replies should all be directed back to the list which would then be distributed to the poster.  If someone needs or wants to email the poster directly, then they will need to do what we do in forums: go private.

I have been fighting for routing rules for a long time.

But I have never had a response from SM

What I would like is for SM to comment on this. Since most Mailservers have this option, why would SM consider it a bad idea?

@Sabatino I would certainly like a more robust gateway system in SmarterMail, including fail-over gateways in addition to round-robin.  With my Sendmail setup, I can define routes for individual source email addresses, by destination domain, fail-over routes, and a few other options.  All very handy, but terry's proposed application is really more about doing something very wrong in the first place.

yes @awrdata.

I didn't read the problem well. It's still absolutely useful that SM introduces routing rules because it solves many problems without going through third-party products.

In my opinion, some things can't even be solved with third-party products.

Take for example aliases that forward to external emails.

Only SM can know this and having the ability to use a specific gateway prevents me from putting my IP's reputation at risk.

Not to mention the follies of Microsoft and/or Yahoo who sometimes ban the IP without a real reason and you have to work hard to get it removed, losing hours/days.

In that case, with routing rules you solve it immediately and without spending a fortune. If the recipient is outlook.* send via the gateway xxxx

I honestly don't understand the resistance from SM