An Increase in Message Size observed for an Outbound email in Message Audit Logs in SMG.
SMG
Some mailbox servers translate the SMTP message into a binary data structure for storage. So the difference in increased message size is based on differences in the data encoding at the different times of measurement.
SMG does NOT "increase" the message size. Scanning of the message and/or its attachments has zero impact on the original email. The original email is copied and the copy is scanned and "thrown away".
The difference is in the data encoding. The smaller message files (which are not supposed to be in the case anyway) are binary while the original file is text with base64 encoded attachments.
So the difference in reported size is based on differences in the data encoding at the different times of measurement. You can't send binary messages over SMTP which is why the message is larger when being sent than when binary encoded in the receiver's message store. The same data takes up different amounts of space based on how it is encoded.
Plain text with base64 encoding takes more space than the binary encoding of the data at rest in the message store.
SMTP does not allow you to send a fully compressed binary data structure over standard SMTP so the data is base64 encoded which takes up more space when the message is being sent.
SMG does not change the message size. The mailbox server (example: Lotus) translates the SMTP message into a binary data structure for storage.
The message size in MAL is the size of the message when SMG received it. SMG does NOT change the message size. The message that SMG delivers may change size if you have policies that remove attachments, add annotations, etc but otherwise, SMG does not modify the message except where specified by the customer policies.