[mailop] R: Contact in Microsoft 365 Defender for Outlook?

[Rodolfo Saccani via mailop]

Ok, I’ll keep talking to myself 😊

Here is how all the false positive reports to Microsoft end up:

[cid:image002.png@01DA0346.6FA09580]

“Should have been blocked” is the standard resolution. This is clearly a false 
positive, the very same link on a different third level domain or on 
urlsand.com is allowed, some third level domains are classified as phishing and 
there is no way out other than attempting with a different third level domain.

I wander what the review process looks like.

Rodolfo

Da: mailop  per conto di Rodolfo Saccani via mailop 

Data: lunedì, 16 ottobre 2023 alle ore 08:17
A: mailop 
Oggetto: [mailop] R: Contact in Microsoft 365 Defender for Outlook?
Did anyone have similar issues?
We’re hitting a rubber wall trying to correct Microsoft false positives in URL 
classification.

Any suggestion would be greatly appreciated.

Cheers
Rodolfo

Da: mailop  per conto di Rodolfo Saccani via mailop 

Data: venerdì, 13 ottobre 2023 alle ore 11:15
A: mailop 
Oggetto: [mailop] Contact in Microsoft 365 Defender for Outlook?
We are having issues with emails flagged as phishing by Defender (and not 
delivered) when the email contains URLs of a URL sandboxing service that 
performs security checks at click-time.
One example of a URL that is currently triggering false positives is
hxxps://blackflow[.]urlsand[.]com/?u=https%3A%2F%2Fwww.mailop.org%2F&e=20266bc5&h=91873bb2&f=y&p=y
Anyway, any URL on this domain will be flagged as phishing.

urlsand.com is the URL sandboxing service that we developed and have been 
running for years, the third level domain is used for customers who want to 
whitelable the service with their own logos and brand colors. Recently, after a 
few days we deploy a new instance of the service, all the email containing URLs 
on the domain are flagged as phishing by Defender.

URLs are rewritten for inbound emails by the ESG that sits in from the 365 
tenant and, of course, the tenant owner can set an exception but any reply sent 
externally that contains one of these URLs will be flagged as phishing and not 
delivered to external recipients on 365.

When recipients report the false positives to Microsoft, the reports are 
routinely closed with a “should have been blocked” clause, with no recourse or 
escalation path.

Is there anybody on the list that I can get in touch with in order to sort out 
this issue?

Cheers
Rodolfo

--
[signature_2066823468]

Rodolfo Saccani | CTO
Email: rodolfo.sacc...@libraesva.com<mailto:rodolfo.sacc...@libraesva.com> | 
Phone: +3903411880307



--
This message has been checked by Libraesva ESG and is believed to be clean.

--
This message has been checked by Libraesva ESG and is believed to be clean.

--
This message was scanned by Libraesva ESG and is believed to be clean.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] R: Contact in Microsoft 365 Defender for Outlook?

[Rodolfo Saccani via mailop]

Did anyone have similar issues?
We’re hitting a rubber wall trying to correct Microsoft false positives in URL 
classification.

Any suggestion would be greatly appreciated.

Cheers
Rodolfo

Da: mailop  per conto di Rodolfo Saccani via mailop 

Data: venerdì, 13 ottobre 2023 alle ore 11:15
A: mailop 
Oggetto: [mailop] Contact in Microsoft 365 Defender for Outlook?
We are having issues with emails flagged as phishing by Defender (and not 
delivered) when the email contains URLs of a URL sandboxing service that 
performs security checks at click-time.
One example of a URL that is currently triggering false positives is
hxxps://blackflow[.]urlsand[.]com/?u=https%3A%2F%2Fwww.mailop.org%2F&e=20266bc5&h=91873bb2&f=y&p=y
Anyway, any URL on this domain will be flagged as phishing.

urlsand.com is the URL sandboxing service that we developed and have been 
running for years, the third level domain is used for customers who want to 
whitelable the service with their own logos and brand colors. Recently, after a 
few days we deploy a new instance of the service, all the email containing URLs 
on the domain are flagged as phishing by Defender.

URLs are rewritten for inbound emails by the ESG that sits in from the 365 
tenant and, of course, the tenant owner can set an exception but any reply sent 
externally that contains one of these URLs will be flagged as phishing and not 
delivered to external recipients on 365.

When recipients report the false positives to Microsoft, the reports are 
routinely closed with a “should have been blocked” clause, with no recourse or 
escalation path.

Is there anybody on the list that I can get in touch with in order to sort out 
this issue?

Cheers
Rodolfo

--
[signature_2066823468]

Rodolfo Saccani | CTO
Email: rodolfo.sacc...@libraesva.com<mailto:rodolfo.sacc...@libraesva.com> | 
Phone: +3903411880307



--
This message has been checked by Libraesva ESG and is believed to be clean.

--
This message was scanned by Libraesva ESG and is believed to be clean.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Contact in Microsoft 365 Defender for Outlook?

[Rodolfo Saccani via mailop]

We are having issues with emails flagged as phishing by Defender (and not 
delivered) when the email contains URLs of a URL sandboxing service that 
performs security checks at click-time.
One example of a URL that is currently triggering false positives is
hxxps://blackflow[.]urlsand[.]com/?u=https%3A%2F%2Fwww.mailop.org%2F&e=20266bc5&h=91873bb2&f=y&p=y
Anyway, any URL on this domain will be flagged as phishing.

urlsand.com is the URL sandboxing service that we developed and have been 
running for years, the third level domain is used for customers who want to 
whitelable the service with their own logos and brand colors. Recently, after a 
few days we deploy a new instance of the service, all the email containing URLs 
on the domain are flagged as phishing by Defender.

URLs are rewritten for inbound emails by the ESG that sits in from the 365 
tenant and, of course, the tenant owner can set an exception but any reply sent 
externally that contains one of these URLs will be flagged as phishing and not 
delivered to external recipients on 365.

When recipients report the false positives to Microsoft, the reports are 
routinely closed with a “should have been blocked” clause, with no recourse or 
escalation path.

Is there anybody on the list that I can get in touch with in order to sort out 
this issue?

Cheers
Rodolfo

--
[signature_2066823468]

Rodolfo Saccani | CTO
Email: rodolfo.sacc...@libraesva.com | 
Phone: +3903411880307



--
This message was scanned by Libraesva ESG and is believed to be clean.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] R: [E] Yahoo "Message not allowed" error

[Rodolfo Saccani via mailop]

As far as I can see, envelope-from domains without a SOA record see their email 
rejected with 554 over some volume threshold.
This seems to be a fairly recent update. This requirement only recently 
appeared here: https://senders.yahooinc.com/smtp-error-codes/ (you can check 
the internet archive for the previous version which didn’t mention SOA).

Rodolfo Saccani
CTO @ Libraesva


Da: mailop  per conto di Jarland Donnell via mailop 

Data: mercoledì, 19 aprile 2023, 04:43
A: mailop@mailop.org 
Oggetto: Re: [mailop] [E] Yahoo "Message not allowed" error
That is actually the entirety of the SMTP response from
mx-eu.mail.am0.yahoodns.net at that time:

"554 Message not allowed - [299]"

Other error messages linked to
 
https://urlsand.esvalabs.com/?u=https%3A%2F%2Fpostmaster.yahooinc.com%2Ferror-codes&e=20266bc5&h=cb659c4b&f=y&p=y
  but not that one. Nothing
seems to help much on that page for this case unless I just assume the
message is "Those people can't email Yahoo anymore." I'm fairly
confused.

On 2023-04-18 16:25, Marcel Becker via mailop wrote:
> On Tue, Apr 18, 2023 at 12:16 PM Jarland Donnell via mailop
>  wrote:
>
>> id=<481770.862217189-sendEmail@srv4414> (554 Message not allowed -
>> [299])
>
> This is most likely not the full SMTP response we provide. The full
> one will tell you the reason -- including a link to a page explaining
> what to do and who to contact.
>
> -- Marcel
> ___
> mailop mailing list
> mailop@mailop.org
>  
> https://urlsand.esvalabs.com/?u=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop&e=20266bc5&h=8e9e62e0&f=y&p=y
___
mailop mailing list
mailop@mailop.org
 
https://urlsand.esvalabs.com/?u=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop&e=20266bc5&h=8e9e62e0&f=y&p=y

--
This message has been checked by Libraesva ESG and is found to be clean.
Follow this link to submit as spam/bad:
https://mail2.libraesva.com/action/4Q1Q8T2c0wzJmh9/submit-as-bad
Follow this link to blocklist sender:
https://mail2.libraesva.com/action/4Q1Q8T2c0wzJmh9/blocklist

--
This message was scanned by Libraesva ESG and is believed to be clean.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] R: Can't deliver to Microsoft from a subnet

[Rodolfo Saccani via mailop]

Thanks for your reply Jarland, I have been contacted privately.
The procedure you described is the one we always follow but this time it’s been 
different and all of the requests have been denied at all levels for a couple 
of weeks.
This morning I see that a few IP addresses have been mitigated, unfortunately 
not the most critical ones, but at least this is a sign that we can hope for an 
improvement.

Thanks for taking time in getting back to me.
Rodolfo


Da: mailop  per conto di Jarland Donnell via mailop 

Data: lunedì, 14 novembre 2022, 19:44
A: mailop@mailop.org 
Oggetto: Re: [mailop] Can't deliver to Microsoft from a subnet
Just to be sure because I didn't see you mention it, make sure you've
contacted them via the form I often see linked so many different ways
but I'll link as this:
 
https://urlsand.esvalabs.com/?u=https%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Fgetsupport%3Foaspworkflow%3Dstart_1.0.0.0%26wfname%3Dcapsub%26productkey%3Dedfsmsbl3%26locale%3Den-us%26ccsid%3D636165504238569370&e=20266bc5&h=82b5d945&f=y&p=y

Make sure to request that the IPs be put into temporary mitigation as
you're warming up a new IP range. When they tell you that can't be done,
reply and ask for it again, as many times as is necessary. It's just the
way the dance is done, I've always been told.

Certainly, it would be faster for one of our friends here on this list
to help you if they can, but it's been a few hours since you sent this
and I at least have information that is more helpful than silence. So I
hope it helps some.

On 2022-11-14 03:13, Rodolfo Saccani via mailop wrote:
> If anybody from Microsoft con help on this, my gratitude will be huge.
>
>
> Some companies (like Southeastern railways, for example) are currently
> unable to deliver their legit email traffic to Microsoft customers.
>
> We are an email security vendor operating worldwide, we develop and
> sell email security virtual appliances and we also operate thousands
> of those in our cloud for the customers that choose so.
>
> In London we had to rush to move customers out of UKCLOUD because the
> company went into liquidation (
>  
> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fukcloud.com%2Fhub%2Fnews%2Fliquidation%2F&e=20266bc5&h=fc4d64b7&f=y&p=y
>   ). UKCLOUD used to host
> assets of government bodies, it has been branded as “the UK
> sovereign cloud” and for this reason many of our UK customers wanted
> to be hosted there.
>
> Because of the liquidation, service continuity is not guaranteed
> anymore. We have quickly moved all of the customers to another DC in
> London and for such customers we used a new IPv4 /24 that we had
> recently acquired (194.39.109.0/24).
>
> We usually don’t have problems in ramping up the reputation of a new
> subnet, all of our outbound email traffic is scanned and clean, every
> customer has it’s own IP address(es) and we do not accept marketing
> customers.
>
> This time it’s been different. The spike in email traffic from about
> 100 IP addresses belonging to this new subnet is probably seen as
> suspicious. These IP addresses are currently heavily rate-limited
> despite us having followed the usual procedure through escalations
> with Microsoft support.
>
> Some of these customers (public service operators and major colleges,
> for example) have a significant outbound email flow being scanned and
> delivered from these IP addresses, well above the current limits
> allowed by Microsoft and we are forced to route some of the traffic
> through relays with a good reputation. This is an emergency procedure
> for us because it mixes outbound traffic of different customers
> through shared IP addresses, which is something that we don’t do
> except in critical situations like this.
>
> Rate-limiting is usually temporary and the limits increase in a
> reasonable time but this time it looks like it’s not happening. I am
> worried that we might have ended up in a corner, for this reason I
> decided to write here, something I’ve never done in many years.
>
> Thanks to whoever will be able to help or provide suggestions.
>
> Rodolfo
>
> --
>
> Rodolfo Saccani | CTO
>
> Email: rodolfo.sacc...@libraesva.com | Phone: +3903411880307 [1]
>
>
>
> Links:
> --
> [1] tel:+3903411880307
> ___
> mailop mailing list
> mailop@mailop.org
>  
> https://urlsand.esvalabs.com/?u=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop&e=20266bc5&h=8e9e62e0&f=y&p=y
___
mailop mailing list
mailop@mailop.org
 
https://urlsand.esvalabs.com/?u=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop&e=20266bc5&h=8e9e62e0&f=y&p=y

--
This message has be

[mailop] O365 new outbound relay pool

[Rodolfo Saccani via mailop]

Hi everyone,
below is a notification recently sent by Microsoft to O365 tenant admins.
As far as I understand this new subnet (40.95.0.0/16) is expected to deliver 
mostly traffic from compromised O365 tenants.
I’d like to check whether my understanding is correct or not, any feedback is 
welcome.

We are apparently talking about outbound traffic that has been attributed to a 
tenant but with an envelope sender on a domain that is not part of the tenant’s 
accepted domains.
For example the tenant has an inbound connector with TLS authentication, the 
email passes this authentication and is therefore attributed to the tenant, it 
is an outbound email but the envelope sender domain is not one of the tenant’s 
accepted domains.

Today what happens with such an email is that the envelope sender is rewritten 
based on Microsoft’s specific 
SRS
 scheme and the email is delivered from one of the IP addresses listed in 
Microsoft’s SPF record.

What will happen on the 27th, as far as I understand, is that unless this email 
passes SPF or DKIM authentication, it will be delivered through the new 
outbound relay pool without any SRS rewriting. I don’t expect this new pool to 
be added to Microsoft’s SPF record.

I anticipate that most of the traffic coming from this new pool will be from 
compromised tenants: email passing tenant attribution but having an 
envelope-sender not among the tenant’s accepted domains and not passing either 
SPF or DKIM validation.
Is there any legit outbound traffic that can match this pattern?

Below the notification message sent by Microsoft to our tenant a few days ago.

Cheers
Rodolfo

--

Rodolfo Saccani
CTO / Head of R&D





New outbound relay pool

We're making some changes to harden the configuration for relaying or 
forwarding email through Office 365.

Starting July 27, 2021, we are updating special relay pools, a separate IP 
address pool that is used for relayed or forwarded mails that are sent from 
domains that are not a part of accepted domains in your tenant. Only messages 
that are sent from domains that are not accepted domains in your tenant are 
impacted by this change.

How this will affect your organization:

When this change is implemented, messages that do not meet the below criteria 
will route through the Relay Pool and the messages might potentially end up in 
recipient junk folder.

  1.  Outbound sender domain is an accepted domain of the tenant.
  2.  SPF passes when the message comes to M365.
  3.  DKIM on the sender domain passes when the message comes to M365.

All messages that meet the above criteria will not be relayed through the Relay 
Pool. For relayed messages, we will skip 
SRS
 rewrite.

What you can do to prepare:

When this change takes effect, you can tell a message was sent via the Relay 
Pool by looking at the outbound server IP (all Relay Pool IPs will be in the 
40.95.0.0/16 range), or by looking at the outbound server name (will have "rly" 
in the name).

For the messages to go through the regular pool you will need to make sure when 
a message arrives to Microsoft Office 365, SPF or DKIM passes, or sender domain 
of the outbound message matches an accepted domain of your tenant

For DKIM to work, make sure you enable DKIM for sending domain for example 
fabrikam.com is part of contoso.com accepted domains, if the sending address is 
sen...@fabrikam.com, the DKIM needs to be enabled 
for fabrikam.com. you can read on how to enable DKIM 
here.

To add custom domains follow the steps outlined 
here.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop