Update email headers and attachment size notes

Author: anmolbohra97

articles/communication-services/concepts/email/email-attachment-allowed-mime-types.md

@@ -100,7 +100,7 @@ The Internet Assigned Numbers Authority (IANA) is a department of the Internet C
 IANA maintains a registry of standardized MIME types. The registry includes a unique identifier for each MIME type, a short description of its purpose, and the associated file extensions. For the most up-to-date information about MIME types, including the definitive list of media types, go to the [IANA website](https://www.iana.org/assignments/media-types/media-types.xhtml).
 
 > [!NOTE]
-> Please note that the total email size includes Email content, Attachment and the base64 encoding (you need to consider that that base64 encoding increases the size of the message. You need to increase the size value to account for the message size increase that occurs after the attachment is Base64 encoded. Base64 encoding increases the size of the message by about 33%, so the message size is about 33% larger than the message sizes before encoding. For example, if you specify an attachment of ~5 MB, you can expect a realistic attachment size value of approximately ~6.65 MB)
+> Please note that the total email size includes Email content, Attachment and the base64 encoding (you need to consider that that base64 encoding increases the size of the message. You need to increase the size value to account for the message size increase that occurs after the attachment is Base64 encoded. Base64 encoding increases the size of the message by about 33%, so the message size is about 33% larger than the message sizes before encoding. For example, if you are allowed a maximum email size of ~10MB (including attachments), realistically you are restricted to ~7.5MB of email (including attachments) because of base64 encoding of the attachments.)
 
 ## Next steps
 

articles/communication-services/concepts/email/email-headers.md

@@ -17,7 +17,7 @@ Custom headers can be sent along with an email request. These headers are define
 
 | Custom Header Name |  Property |
 | --- | --- |
-| x-ms-acsemail-ignore-duplicate-content-id | When this header is explicitly set to true, we don't validate duplicate content ID and will let the author manage duplicates. By default we return a bad request |
+| x-ms-acsemail-ignore-duplicate-content-id | When this header is explicitly set to true, we don't validate duplicate content ID and will let the author manage duplicates. The default value of this header (if not present) is false. In this case, we return a 'Bad Request' when we encounter duplicate ContentID. |
 | x-ms-acsemail-suppress-invalid-attachment | By default, if the attachment is invalid, we return bad request. If this header is set to true and if an attachment is invalid, we continue with the request without the attachment. |
 | x-ms-acsemail-validate-message-id |  When this header is explicitly set to true, we validate the internet message ID sent by the customer. The validations include checking for [RFC 2822](https://www.rfc-editor.org/rfc/rfc2822) Internet Message ID format and also if there's a duplicate already present. If it fails, we return bad request. If the header isn't set and the internet message ID validation fails, we remove the message ID and let the service create one. By default, we don't force this validation. <table><thead><tr><th>Internet Message ID</th><th>Validity</th></tr></thead><tbody><tr><td>&lt;[email protected]&gt;</td><td>Valid</td></tr><tr><td>&lt;202501131823.34067409c4494c2c8b2de03ceb26f173-NVZOA======@microsoft.com&gt;</td><td>Valid</td></tr><tr><td>[email protected]</a></td><td>Invalid</td></tr><tr><td>&lt;guid&gt;</td><td>Invalid</td></tr><tr><td>&lt;guid.domain&gt;</td><td>Invalid</td></tr></tbody></table> |