Google groups mostly does verps style addressing for the reasons that Steve mentions. We added support for not doing it for apps domains going to internal addresses, but mostly that doesn't work any more since we split deliveries since each recipient may have different policies applied to it, and computing the intersection of policies on a multi recipient message was punted.
Fixing it is somewhere on a to-do list but I wouldn't hold my breath. Maybe if we increase the size of messages we support it will become more important. I'd recommend caching scan results to save on some of the resources, but it's no cure all obviously. I think app groups also have a setting to limit the size of messages, or you can try and encourage pass drive links instead. No good answers, sorry. Brandon On Apr 25, 2016 1:37 PM, "Steve Atkins" <st...@blighty.com> wrote: > > > On Apr 25, 2016, at 1:02 PM, Steve Freegard <steve.freeg...@fsl.com> > wrote: > > > > Hi all, > > > > We scan mail for a domain which uses Google Apps for Education and as > part of that they use Google Groups for communications to students. > > > > Does anyone have any idea why when someone sends a message to group ' > all_staff_and_stude...@domain.com' that Google insists on sending a > single message per-recipient from a host pool instead of sending a single > message to multiple groups of recipients (like 50-100 recipients or so)? > > I'd assume it's so that they can handle bounces correctly, like all good > mailing list software does. > > (Also to avoid the pain of trying to intuit what an after-DATA rejection > or deferral means when there are multiple recipients). > > > Currently if someone sends a message with a 2Mb attachment we then see > ~6Gb of traffic back. It's made worse by the fact that if a user is on > several groups and those groups are members of other groups, they get the > same message 3 times (Google appears to discard the duplicates, we still > receive them though). It's like a big amplification attack for every > message... > > > > Anyone have any ideas on how to tackle this? > > There's a bunch of user education the end user org could do but as a > filtering-in-the-middle provider you're probably stuck with eating the > bandwidth cost or inconveniencing your customer (by passing the cost on to > them or putting size limits on mail you filter or ...) to encourage them to > make changes, ideally changes you'd want them to make. > > Cheers, > Steve > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
