This is not normal behavior, either by microsoft or your customer. My advice is the same as it was yesterday: terminate the customer.
Microsoft doesn’t normally send backscatter, so the fact that you’re getting so much tells me your customer (y’know, the one who didn’t give you a way to contact them when they signed up) is a malicious actor and is preying on you and your network. Get rid of the customer. Their behavior is causing you network problems and they won’t fix it (by pointing the MXs at a host that can handle the volume). There is zero reason to keep them. laura > On 23 Nov 2022, at 09:39, Cyril - ImprovMX via mailop <mailop@mailop.org> > wrote: > > Thank you, everyone, for your response. My timezone differs from yours, so > I'm only replying now. > > I forgot to mention this, but indeed, the first thing we did was contact > them. We had no response, so we blocked them and later realized that the > email contact we had was a black hole on their end, so we reached out using > another email we found and got a response. They are looking into it, but I > still wonder how we can have what is now 70k connections per minute solely > from Outlook. > > Blocking the recipient had the effect that we don't accept emails for them > anymore, so anyone sending an email via ImprovMX to one of their domain will > have a 5xx response on the RCPT command. > That was our initial strategy, the default when we block an account: we let > the sender know the email wasn't accepted. > > But in this case, I realized one thing: It's possible that the sender could > retry, increasing the number of connections at every new bounce. So I've > updated the policy on this specific account to accept but silently drop any > emails for them. > > I was also able to get a hold of a few emails we received. The bounce reports > don't contain the original body, but the errors I got are mostly "access > denied AS(201806281)" with a few "address not found". > > I suspect the original sender, using the mail provider, is sending a massive > campaign using a very bad list of recipients that got the mail provider > flagged and got their email rejected. > > I was hoping there was an easy fix we could implement on our end that would > tell Outlook to stop connecting, but I'm pretty sure someone here would have > shared it if that was the case. > > We now need to hope that they'll be helpful in resolving the issue. > > Thank you all again for your message and help, and if you have any > suggestions we can implement or do better, I'm all ears! > > Best regards, > Cyril > > Le mar. 22 nov. 2022 à 19:08, Jarland Donnell via mailop <mailop@mailop.org > <mailto:mailop@mailop.org>> a écrit : > I would block the recipient domains at the MTA level and cut out the IP > rate limiting for a while. An MTA should be able to handle the rejection > for the domain fine. I do the same with exim when a user tries to give > me the job of mass forwarding bounces, I just won't do it. In my mind a > flood of bounces means bad behavior and I justiy the block by refusal to > participate in whatever it is they're doing. > > I don't think you're crazy here at all, if half of your job suddenly > becomes forwarding bounce emails that's just not a good look. > > On 2022-11-22 04:54, Cyril - ImprovMX via mailop wrote: > > Hi! > > > > I would appreciate your help on a bad issue we are having. > > > > We are facing a very large amount of connections from Outlook, in the > > order of 50k connections per minute (whereas the second "most active" > > server is at 100). > > > > Upon investigation, we discovered that one of our users is a > > mass-sending email service (such as Mailgun; it seems legit in > > itself), and they created one domain per client to handle bounce > > reports, such as sp-bounce.{client's domain}. > > > > Since the MX of these domains points to our server, any bounce report > > sent is sent to our server. (Our service is a forwarding email, so > > once we get the email, we forward it to the above user). (I'll add a > > comment on this right after) > > > > The problem is that I don't see how we can stop Outlook from sending > > all these bounce reports to us. I thought about updating the SPF to > > block that sender from including us, but we don't manage their DNS. > > > > Right now, what we've done is to stop accepting connections from a > > sender (in this case, Outlook) after an abnormal amount of connections > > per a given period, but this doesn't avoid the fact that Outlook still > > tries to connect to us massively, and also impact our regular users > > that receive emails from Outlook sender legitimately. > > > > What I'm hoping by reaching out to you is to hope someone has already > > faced something similar and has some suggestions on how to mitigate - > > or ideally block - this. > > > > This could be a pretty well DDoS attack done by mail servers. > > > > On the comment above regarding the bounce report being sent: That is > > my suspicion, by looking at the domain names (sp-bounce), the email it > > receives, and the sender activity. But maybe there is another logical > > explanation I'm missing! > > I mean, to have 50k connections per minute to deliver bounce reports > > means that the running campaign must be in the order of millions of > > emails just for Outlook! > > > > All help is deeply appreciated!!! > > > > Thank you all in advance. > > > > Best regards, > > Cyril > > _______________________________________________ > > mailop mailing list > > mailop@mailop.org <mailto:mailop@mailop.org> > > https://list.mailop.org/listinfo/mailop > > <https://list.mailop.org/listinfo/mailop> > _______________________________________________ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://list.mailop.org/listinfo/mailop > <https://list.mailop.org/listinfo/mailop> > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
