On Thursday, June 10, 2021 at 11:45:01 AM UTC-7, Claus Aßmann wrote:
> Not yet - maybe you can write a patch? Unfortunately I don't have
> much time to loook into this, hopefully someone does!

Claus, pulling up an old thread here but would having a sponsor provide you the opportunity to implement a solution? This has finally reached my attention too and the ability to split envelopes by domain (something which Brandon Long thinks sendmail can do, but I can't figure out how) or perhaps being able to assign a queue group by wildcard matching on an MX record which would allow the cheesy fix of just setting a single recipient per transaction on a queue assigned to gmail's mx servers.

In any case, savvy users have started to notice and complain about delays into gmail hosted domains because of this.

Kelsey Cummings <kgc@corp.sonic.net> wrote:

> In any case, savvy users have started to notice and complain about delays
> into gmail hosted domains because of this.

I kind of lost the original thread but I think you are looking for this
solution.

In your sendmail.mc stick these in:

define(`SMTP_MAILER_MAXRCPTS', `1')dnl
define(`RELAY_MAILER_MAXRCPTS', `1')dnl

Those will make sendmail queue them out one at a time rather than bundle them
together and get that multi-domain isn't allowed error from gmail.

Been using that for a while and haven't seen a single rejection or error
dealing with them. Also works well for the idiots at protection.outlook.com
because they randomly set max nrcpts to 2.

-bruce
bje@ripco.com

On Wednesday, November 2, 2022 at 6:18:32 AM UTC-7, b...@ripco.com wrote:
> In your sendmail.mc stick these in:
>
> define(`SMTP_MAILER_MAXRCPTS', `1')dnl
> define(`RELAY_MAILER_MAXRCPTS', `1')dnl

I'm reluctant to break a fundamental optimization in email delivery to
work around google's behavior. Although perhaps on today's
infrastructure it wouldn't really make all that much of difference.

-K

Kelsey Cummings wrote:

> attention too and the ability to split envelopes by domain (something which
> Brandon Long thinks sendmail can do, but I can't figure out how) or perhaps

Try the following:
Add this to your mc file in the proper places:

QUEUE_GROUP(`one', `Path=/var/spool/mqueue/one, r=1')
LOCAL_CONFIG
Kbestmx bestmx

LOCAL_RULESETS
Squeuegroup
R< $+ > $1
R $+ @ $+ $: $(bestmx $2 $)
R $+ $: $>SearchList <! qgrpmx> $| <D:$1> <>
R<?> $@
R<$+> $# $1

Add something like this to access_db:
qgrpmx:google.com. one

Rebuild the cf file and the map.
mkdir /var/spool/mqueue/one
with proper owner/group/permissions

Now domains which have a "best MX" pointing to google.com
should end up in queuegroup one which should have this
option:

recipients
The maximum number of recipients per envelope.

This might be a good start - but I haven't tested it!

It would be nice if someone gives it a try and actually
reports back (not like with the IPv4 patch where people
ask for it but don't give feedback...)

Note: an enhanced version to send all recipients with the
same domain to google instead of just 1 per transaction
probably requires some code changes -- which would take
much more time and effort.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

On Thursday, November 3, 2022 at 12:01:44 AM UTC-7, Claus Aßmann wrote:
> Try the following:
> Add this to your mc file in the proper places:
....

Claus, this seems to work as expected provided you don't get stuck thinking that existing FEATURE(`queuegroup') configs are still going to work as well. Perhaps it's possible to do both the bestmx lookup and then override the result with a non-empty qgrp lookup. But, that's not an issue for our use case and arguably the other groups we have defined would benefit from being MX based and not domain based in the first place. With two qgrpmx's defined, I was able to split envelopes across both of them and the default mqueue with them all respecting the queues' recipient limit. I'd call this a success!