Tag: transport

Undeliverable Message reads: Remote Server returned ‘550 5.3.4 SMTPSEND.OverAdvertisedSize; message size exceeds fixed maximum size’

Scenario:  You try to send a message with an attachment to a recipient but you receive a bounce/undeliverable message that shows this error.

Remote Server returned ‘550 5.3.4 SMTPSEND.OverAdvertisedSize; message size exceeds fixed maximum size’

When sending the message, although the message size is close to the max message size set by Exchange, it still falls under the max message size.  For Example:  The maximum message size that your email servers will allow is 35MB, and the message you want to send has a size of 30MB.

Cause for the bounce:  There is a message size conversion when passing off between different message relays. Sometimes this conversion can be up to a 30% increase of the original message size.  For example,  when the message is received in Exchange it shows 30MB.  When the message is passing through the send connector, a size conversion takes place on the message and when Exchange attempts to send it through the send connector to the next message relay, it reads 38MB.  This 38MB exceeds the 35MB limit set on the next message relay and it causes a bounce/undeliverable message.

You can see the size conversion in the TotalBytes field by running a command similar to the following:

get-tranpsortserver | Get-messagetrackinglog -MessageSubject “Big Attachment” -start 1/28/2015  | Sort TimeStamp | Select ServerHostname, Source , EventID, TotalBytes

*In my experience, the type of message attachment influences the size conversion for the message.

WorkaroundResolution:

The easy solution is to just zip the attachment and make it smaller and then attempt to pass it through.  Else you need to increase your maximum message size limits on your message relays to account for the increase caused by the conversion.  For Example, if you truly want to allow a 35MB attachment and account for a 30% message size increase, your maximum message size needs to be 45.5MB.

A mailbox sends out to more recipients than allowed by the recipient rate limit in their throttling policy

Scenario:  A mailbox has sent to more recipients than allowed by the recipient rate limit that is set in their throttling policy.  For example, a mailbox can only send out to  100 recipients within a 24 hour period, BUT that mailbox has managed to send out to 500 recipients. How can this be?

Whats happening:  A mailbox can send to more than 100 recipients if:

  1. The 24 hours have been completed for that mailbox. The will be able to send for up to another 100 recipients.
  2. The throttling service  has been restarted on the mailbox server where the mailbox is located.
  3. If a user sends to a distribution list, as the distribution list will only be counted as one recipient EVEN though there are 400 recipients in that distribution list.   

Here is the WorkFlow of the RecipientRateLimit in the throttling Policy.

Terminology:

Token: The token is the number of recipients which has already been processed

Token Bucket Map:  This is the table where the guids of the mailboxes are kept with the current RecipientRateLimit.

The token bucket map is held in memory when the Throttling service is started on the Mailbox Server. As new mailboxes send mail, they are added to the bucket map.  When the mailbox submits mail, the throttling service checks the bucket map to obtain the token for the sender.  In order for messages to be sent by the user, this must be true:

Obtain Token + Token Bucket Map <= RecipientRateLImit

Example: If the mailbox is trying to send 10 recipients ( Obtain Token) but the user has previously sent to 96 recipients (Token Bucket Map),  sending would fail:  96 + 10 <= 100

But if the mailbox is sending to 2 recipients (and not 10), sending would succeed:   96 + 2 <= 100

Distribution groups are counted as one sender  and further into the transport process of the sent message the  distribution groups is expanded into numerous recipients.  Sending a message from a mailbox always originates from the mailbox server where the mailbox is located on.  This is the mailbox server holds the Token Bucket Map.  The expansion of the distribution group can happen on any server during the transport process, thus its not logically possible to store the true number of recipients for that sender when a distribution group is used. This is why the Distribution Group is a loophole to the Recipient Rate Limit.

Get all messages from all transport servers by a specific sender, starting on a specific day

Get all messages from all transport servers by a specific sender, starting on a specific day and export to CSV

Use this one-liner:

Get-TransportServer | Get-MessageTrackingLog -sender:test@test.com -start 7/15/2014 -resultsize unlimited | export-csv c:export.csv