And you have me a little confused as what is going on as well..
In MagicMail you can set a policy..
'local_require_auth', where if the MAIL FROM is an address hosted on the
platform, it requires authentication. Stops forgeries. But it can stop
remote contact forms that mistakenly try to use form supplied
credentials in the MAIL FROM, or if the admin set the MAIL FROM to an
address that is actually located elsewhere. That can be addressed by
using SMTP relay.
The other case, is 'require_local_sender'. This is a case where you
CANNOT use a MAIL FROM, that isn't hosted on the server, for sending,
authenticated or not. Stops compromised email accounts where the hacker
attempts to change the MAIL FROM, to avoid 'bounces' that might reveal
that the account is hacked, when sending to servers that can generate
backscatter.
Are we talking about similar functionality? This isn't related to SPF or
'Known Sender Forgery'.
On 2025-09-26 00:17, Jaroslaw Rafa via mailop wrote:
Dnia 26.09.2025 o godz. 08:43:07 Benoît Panizzon via mailop pisze:
The situation we have here is an external sender sending emails to a
recipient local on the exchange Platform using a domain which is hosted
on exchange by a different tenant.
So we have EXTERNAL to INTERNAL - no relaying - no authentication
required.
[...]
It is traffic FROM outside to one MS customer. No inside traffic, this
is what I don't understand.
From your description, it looks like MS simply implemented their
"DirectSend" wrong. Their system thinks that ANY incoming mail with sender
address from a domain hosted on MS is "internal to internal", regardless of
the fact it is coming from external source. They probably check the sender
address first, and not the IP address, and if the sender address is from MS,
they decide it's "internal to internal".
I have already seen such behaviour, long time ago, on one Polish mail
service (@op.pl). It was at the times when there was no SPF yet (so
forwarding was commonly used without issues) and email services just started
to implement SMTP AUTH - on port 25, without using a separate submission
service. The scenario was when [email protected] was sending their mail to
[email protected] (external to op.pl, totally different service), and
[email protected] in turn forwarded the mail to [email protected], the op.pl
server rejected the mail with a message requring authentication - because it
saw a sender address from op.pl domain. I think I see similar
misconfiguration here.
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
