Hi Sebastian > >>Last time he sent invoices the emails were rejected by various other > >>Outlook 365 customers because 'DirectSend' is set to forbidden for > >>the sending domain. > > This is because DirectSend is kind of a "MS internal policy". > > In the same way, you can't send emails from this server > (dns2.sebbe.eu) with a sender of sebast...@sebbe.eu unless you are > authenticated. > > Its a local policy, it has nothing to do with SPF. Even if I would > set my SPF policy to +all, it wouldn't accept the mail still, because > its a local ACL that controls that. Because a server can't ask the > SPF on itself if you understand what I mean. It wouldn't make sense > to check if 127.0.0.1 is allowed to use sebast...@sebbe.eu > > SPF is used between EXTERNAL to EXTERNAL servers. > > Sending mail from Microsoft 365 to Microsoft 365 is INTERNAL mailing. > Like you would mail from j...@sebbe.eu to sebast...@sebbe.eu
You confuse me :-) and I still don't quite understand as the Situation as I understand, is most probably one which is commonly used. There is a Sender with domain example.com - Let's say, it's a community council - it needs to send invoices to it's inhabitants for water - power etc. For convenience invoices can be transmitted in different way. * Good old paper via post. * PDF via eMail. * e-Bill (directly delivered to the recipient Bank) The council set up their email domain example.com on an exchange 365 cloud instance but they don't send the invoices via email over that platform. This is done by a 3rd party supplier who is printing or transmitting the invoices via email and e-Bill. For the recipient this shall not be visible. So the sender domain is set to 'finan...@example.com' this is also important as the finances department of that council processes the bounces. The SPF record of the council example.com includes the ip range of the supplier sending the email invoices. This has worked perfectly for several months. Now suddenly inhabitants and businesses who choose to receive the invoices via email started rejecting them with Direct Send not allowed for this organization from unauthorized sources. Apparently because example.com disabled DirectSend. But when I read on DirectSend - I understood this is to allow an external sender to relay emails to external addresses via the Exchange Cloud platform. (External to External - unauthenticated RELAY via Exchange). I understand that you want an IP whitelist for that. 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. > >>The customer confirmed, according to their security requirements as > >>a government related company, they were instructed to disable > >>'DirectSend' on their Outlook 365 service for their domain, to > >>prevent third parties to fake their envelope sender. > > Yes exactly. Thats because, Microsoft 365 doesn't require > authentication unless you are RELAYING email. And Microsoft 365 to > Microsoft 365 is still internal mail. > > So you could spoof a email by directly sending to a Microsoft 365 > server, which then sends to another Microsoft 365 server, as those > mails never leave MS premises. But this is not the case where I see those emails being rejected. > >>Aehm, this is what SPF is already doing - in a correct way - why > >>does this DirectSend setting override SPF which would allow the > >>envelope sender from our ip range? > > NO! > SPF don't handle local policies. > > Imagine whats happens inside MS premises. Of course, its a server > that would be called like 10.0.0.6 that would mail to a server called > 10.5.6.10 Since both customers are MS customers, theres no need to > route the traffic outside Microsoft premises. It is traffic FROM outside to one MS customer. No inside traffic, this is what I don't understand. > How would that be handled in SPF? Example.com (council as MS Exchange tenant) SPF: include: ipv4:192.168.99.0/29 include: whatever.outlook.com 192.168.99.0/29 being the range from which the PDF email invoices are sent. This works perfectly. Gmail, GMX all others accept those emails. Why is Microsoft rejecting them? > And why should internal servers have to ask external servers for a > policy when sending internally? IMHO: There is nothing internal in this scenario. This is what I don't understand. > This is why Microsoft invented the "DirectSend" , which was invented > in 2016, to facilitate mailing between Microsoft servers without > having to rely on external communication. > > The feature got misused, why they added the option to disable it for > the sender domain, which means, a Microsoft server will not accept a > non-authenticated mail that was sent from a Microsoft server to a > Microsoft server. Meaning the sender has to be authenticated with > SMTP Auth to send. In my example: 192.168.99.0/29 is not a range belonging to Microsoft. It's the IP range from which the 3rd party supplier is sending it's emails. So it's not form a Microsoft server to another Microsoft server. It's from a 3rd party EXTERNAL server to a Microsoft server. Just the envelope sender is set to a domainnname that belongs to a different microsoft exchange tenant. But I asked the council to get back to Microsoft and have them explain more precisely what goes wrong with their invoices they have sent with their domain from an external IP range. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
