Hi Laura, many thanks for writing back.
It seems there may be some contributing factors at play, including some
clients having web-forms sending to "both parties", now cleaned up.
Q: Have you looked to see if there were changes in your sending pattern
recently that would trigger Microsoft to temp fail mail from you?
A: We don't believe so. 1x of all clients' 2x nameservers were
relocated, however no change was made by us to the SMTP configs etc, no.
Q: Could it be that there are traffic patterns that look like maybe one
of your customers is compromised or otherwise sending mail that is
problematic?
A: There is a single client who has been working through some issues on
a single host of theirs. They are not reporting the problem, others are.
It seems that it may just be exposing the websites/apps which are not
following best practices (client decisions, not infrastructure).
Q: Is it all the traffic from your system or just some of the traffic?
A: Looks like it was most and now it is slowly reducing, per comparison
on some machines. This morning, the lever is heading the right way.
[3: Wed Sep 03 08:40:36] lthompson@removed:/var/log $ grep ".outlook.com" exim_mainlog |
grep "Please try again later" | wc -l
426322
[4: Wed Sep 03 08:40:43] lthompson@removed:/var/log $ grep ".outlook.com" exim_mainlog |
grep "250 " | wc -l
3806
Q: When in the SMTP transaction is the block happening? At connection?
After DATA? Elsewhere?
A: SMTP error from remote mail server after end of data, is when we're
getting the temporary block reply.
Q: Have you tried pausing deliveries for a period of time (1 - 2 hours
or longer)? And then slowly restart sending?
A: No, we haven't attempted that. The main impacted machine had a queue
filled with deferral warnings - now purged and ratios seem to be improving.
We try to keep things running smoothly. PTR on A and AAAA. v6-enabled
SMTP. DKIM/DMARC mostly fully in-place (even just p=none), depending on
the client. SPF up-to-date re: sending infrastructure, except potential
legacy records depending on the client.
Hopefully this is the turning point back to normal deliveries through to
Microsoft.
Many thanks,
Luke Thompson, CTO
The Network Crew P/L
E: luke.t@tnc.works
https://tnc.works
On 2/9/2025 7:12 pm, Laura Atkins via mailop wrote:
On 2 Sep 2025, at 08:26, Luke Thompson via mailop <mailop@mailop.org>
wrote:
G'day,
We are seeing this error across some servers/domains.
SMTP Error 451 4.7.500 Server busy. Please try again later.
This seems to relate to Microsoft determining a change in sending
behaviour.
The error occurs when the recipient mail server's Exchange Online
Protection (EOP) service detects a significant change in the sending
mail server's previously established sending patterns.
Checking the sender.office.com system, it reports the most
problematic client machine as fine:
The IP address in question is not currently blocked in our system.
So, given it is causing a bit of havoc and vendors like cPanel have
just issued an article 4 days ago about it (so incidence rate is up),
what's the go?
https://support.cpanel.net/hc/en-us/articles/4408492985111-SMTP-Error-451-4-7-500-Server-busy-Please-try-again-later
If we can't resolve anything and it's deferring it many times (5+)
then what can we really do?
Have you looked to see if there were changes in your sending pattern
recently that would trigger Microsoft to temp fail mail from you?
Could it be that there are traffic patterns that look like maybe one
of your customers is compromised or otherwise sending mail that is
problematic?
Temp failing (451 and the like) is a common reaction that is not
blocking (that would be an actual block) to traffic that seems
suspicious. Is it all the traffic from your system or just some of the
traffic? When in the SMTP transaction is the block happening? At
connection? After DATA? Elsewhere? That may lead you to some
information about what is triggering the issue.
Have you tried pausing deliveries for a period of time (1 - 2 hours or
longer)? And then slowly restart sending?
laura
--
The Delivery Expert
Laura Atkins
Word to the Wise
la...@wordtothewise.com
Delivery hints and commentary: http://www.wordtothewise.com/blog
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
