Changes coming to the SMTP Authenticated Submission client protocol

There are a number of client protocols offered by Exchange Online to allow email clients to send email from their mailboxes. One of the most widespread protocols is SMTP Authenticated Submission (also known as SMTP Client Submission) which is supported by most email service providers. This non-proprietary protocol is used to send email by legacy email clients, third-party software and services, and devices such as multi-function printers. Changes that we’re making to how this protocol works in Exchange Online may adversely affect the rate at which these clients or devices can send email.

Starting June 1, the following changes will begin rolling out for SMTP Authenticated Submission protocol:

• Sent email will now be stored in the Sent Items folder of the mailbox.
• Only three concurrent connections to our service per mailbox will be allowed. Additional connections will be rejected with the error: 4.3.2 STOREDRV.ClientSubmit; sender thread limit exceeded.

Exchange Online uses a number of mechanisms to protect the service from abuse and ensure fair usage by users. One such protection is the Recipient Rate Limit (RRL) which limits the number of recipients per day to 10,000. The aim is to deter the sending of bulk email (and as mentioned on the service limits page, you should send bulk email using a specialized third-party provider). This change to the SMTP Authenticated Submission protocol will further protect the service from large bursts of emails in a short amount of time from automated systems. This will not affect the majority of SMTP Authentication Submission users who only send from one email client or multi-function device for a given mailbox.

For customers who have numerous devices sending emails using the same mailbox (for example, printer@contoso.com), there’s a small chance that multiple devices will try to send email at the same time. Any devices that are rejected would just need to retry. The same is true if an application that uses a cloud mailbox to send email tries to send multiple messages at the same time (and that behavior depends on how the application was designed). Most applications and devices that send email should be able to handle errors and retry sending email. However, retrying will reduce the overall rate at which email can be sent.

If this change adversely affects you, you have a few options:

1. Use a different mailbox for each application or device.
2. If you’re trying to send thousands of copies of the same message (for example, a newsletter) in parallel using a third-party application, you may need to send it out in batches or use distribution groups.
3. If time is important (for example, an alert system that generates multiple alerts at the same time), you’ll need to use a third-party delivery service that’s designed to send large amounts of email.

Sean Stevenson

from TechNet Blogs https://ift.tt/2HQ8YeO