As always, Mark may have better ideas.
Thomas Ward via Mailman-users writes:
> Tracing down an issue of "why are we no longer receiving owner
> notices" such as list membership changes, moderation list items,
> etc. we are seeing errors in MS365
<img src="friends-dont-let-friends.gif"/>
What is MS365 complaining about? Do you get an informative status, or
is it just 5.7.0 administratively denied, or what?
> Upon deeper trackdown of this, our owner user [email protected]
By "owner user" I assume you mean [email protected] is the common
list owner for all lists, and not the site owner specified in
mailman.cfg.
> is seeing messages sent to it from @lists.example.com and
> @distro.example.com from [email protected]
"From" here means RFC 822 From? That seems like correct behavior to
me. Mailman has no way to know that "[email protected]" is the IT
team/site owner/OWNER OF ALL THE THINGS. It doesn't treat it any
differently than it would "[email protected]", and so just sticks it in
"From". That is RFC 822-ly correct.
> (despite the From in the envelope being
> list-bounces+mailman=example.com@[lists|distro].example.com)
This is to ensure that bounces due to messages originated from the
list host go back to the list host for normal bounce processing.
Again, Mailman has no reason to think that [email protected] can
do anything about bouncing mail that originated at *.example.com (or
example.com, for that matter).
> Is there any specific reason for this [error by MS365]?
The only thing I can think of offhand (aside from the snide "MSFT is
always at fault" meme which you should discount but not to zero, it's
like DNS that way) is DMARC policy for the three domains. If the
subdomains sign as the subdomains, and the policy of the parent domain
is p=reject, you will have delivery failures. I suspect the bounces
are just handed to the bounce processor which increments the bounce
count for [email protected], but if that's not subscribed to a
Mailman list I doubt it has any visible effect.
I guess it's also possible that there's a malmail filter that doesn't
like mail from me to myself, which is pretty common with spam and
phishing in my experience.
It might make a difference whether the various Mailman domains are
handled by separate instances, or if they are virtual domains handled
by a single instance, though I can't think offhand of any reason why
it would matter, other than making the DMARC scenario more likely if
they're separate instances.
> Is it because the MS365 side is ignoring the Envelope's From
> address and relying on the actual *from* field which is breaking
> things because MS365 users are "not allowed to send as
> [lists|distro].example.com"? This seems highly suspicious if this
> is the case,
Could be, but the very similar DMARC policy hypothesis should also be
checked.
> and I want to see if there's anything we can do on the
> Mailman side of things to make this 'work' for the 365 recipient
> ([email protected] is a shared mailbox for the IT team in this
> case, so it's a legitimate user).
I don't see how stock Mailman can help you (especially not without
figuring out what is giving MS365 indigestion). There are strong
reasons for the formatting of both RFC 822 From and the envelope From.
If you want it to treat [email protected] specially (either when it
is list owner or globally) you'll need to hack Mailman's email
origination code.
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
_______________________________________________
Mailman-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Archived at:
https://lists.mailman3.org/archives/list/[email protected]/message/YHNJ2ZLBJFESYIP24GRCQYIFFYS2F2UG/
This message sent to [email protected]
