Sendmail provides for queue groups where one can have messages that stay in queue be placed in separate queues which are treated differently according to rules described in the queuegroup ruleset. FEATURE(queuegroup) helps managing such queues via the access database but unfortunately deals only with recipient addresses. But what if one wants to place messages in a separate (slower) queue based on sender’s address?
QUEUE_GROUP(`newsletter', `N=10, I=31m, P=/storage/queues/n.*')dnl LOCAL_RULESETS Squeuegroup R$* $: $>canonify $&f R$* < @ $* > $* $: $1 Rowner-newsletter $# newsletter
The above trick does not make use of the access database. In fact you must not use FEATURE(queuegroup) in your sendmail.mc with it. The queuegroup ruleset is called with the recipient address as an argument. The first line replaces it with the sender’s address ($&f) canonified. In this particular newsletter case, we are only interested in the left hand side of the email address ($1). Others may be interested in the sender’s domain ($2). The third line checks to see whether the left hand side matches what we expect (owner-newsletter) and if so, it selects the corresponding queue. Otherwise the default queue, named mqueue, is selected.
For a more complete ruleset that can treat combinations of senders and recipients and via the access database see “Sendmail Extended Queue Groups“.
Managing organized complexity 
Since you had to write the above, it probably means some of your customers are sending a high volume of “newsletters”, that end up clogging your queues.
You also probably don’t have an established limit for your smtp service, e.g. each customer may send 500 emails per day, so these users in fact abuse your kindness, and send as many mails as they can.
Thus you spend some nights/weekends working and write custom rulesets trying to keep your service smooth for the rest.
Story of our life!
Actually this customer is THE CUSTOMER. Limits do not apply in this case. And the problem in question is a single mail per day (the newsletter) that has to be sent daily to roughly 60K users (with a rapidly increasing trend).
At least this problem helped justify the need to purchase new equipment. The real problem is that I cannot push it to production as fast as both I and the users want.