I did get the technical problem solved, which I'll document here for the benefit of others.
Background: I have a groupEmail script on this mail server that is run by sendmail alias commands as shown in my OP:
Code:
test: |" /user/util/bin/groupEmail test"
The groupEmail script would look up the members of e.g. "test" in the database, remove the To: line from the message, and place the looked-up email addresses in a Bcc line. That all worked fine except that in order to have the recipients' email server not get flooded with lots of email from one sender, the messages were sent one-by-one and spaced out at 3 minuted intervals. Not even gmail objected to that.
That could take a lot of time so the idea was to use a mail service like SendGrid to speed up this process by handing them all the messages is a much shorter timeframe. I subscribed the the SendGrid service, specified smtp.sendgrid.net as the system-wide SMART_HOST (relay). But ...
Problem #1 - SendGrid requires an authorized sender domain and none of the users sending email through this alias command script were local users. So, to solve problem 1 I further modified the groupEmail script to replace the From: address with an authorized domain sender (maillist@authdom.org), and put the original sender's email address in the Reply-To: line. And, most importantly, specified a different sendmail.cf config file using the -C option. Thus the groupEmail script would send specifying this special config which had the SendGrid SMART_HOST, but the rest of the normal email system would use a config script without the SendGrid relay. But ...
Problem #2 - This was the reason I posted this thread. When running Sendmail from an alias command with an alternate config file Sendmail gives up set-user-ID root permissions which means it cannot put messages in /var/spool/mqueue. As the article I reference in my #2 post, above, says, the solution to this is to specify a different mqueue folder with the -oQ option. I did this, but ...
Problem #3 - /etc/mail/access.db: Permission denied. This is because its permissions were -rw------- and it was owned by root. I solved that problem by changing its permissions to -rw-r--r--. But ...
Problem #4 - Nothing was sent, no messages in maillog. After scratching my head a while I reasoned that /etc/mail/authinfo.db also had these same ownership and permissions and perhaps the groupEmail script's sendmail could not read that file in order to authenticate with SendGrid. So, I changed it to also have -rw-r--r-- and that seemed to do the trick.
For good measure I also changed aliases.db and virtusertable.db to have -rw-r--r--. I could have probably accomplished the same by changing the group on these files to daemon and just adding group read access, but I didn't go there.
This all made the sendGrid relay implementation work. I had other problems with SendGrid actually being able to deliver these messages in a timely manner, but that's another story.