Mail size is incorrectly recorded when mail is encrypted

[rjl]

Currently amavisd-maia gets its mail size figure from the upstream MTA, which reports the true size of the mail. This size figure is used to determine whether the mail is "oversized" and should bypass content filtering. In practice, however, the actual size of the mail being stored in the maia_mail table may be slightly larger than advertized, due to padding added by the Blowfish algorithm, if the mail is to be encrypted. The oversize check needs to be repeated after encryption takes place, essentially.

[anonymous]

to do this, the $oversized parameter of maia_store_mail needs to be passed

by reference so that it can be changed if needed.

[mortonda@…]

I don't know how to test this; but the attached patch in theory should check the real size of the encrypted message and alter the oversized status if needed.

• changed oversized parameter to be passed by reference (and all places in the function dereference it)
• use bytes makes sure we get the real size, only valid in the enclosing block
• added size_lmit parameter to avoid having to recalculate it.

This patch only alters the state of the oversize flag (and thus stores it as oversized) The actual recorded size is still the unencrypted size - I don't think anyone is really interested in the encrypted size. This means in the event this code is needed, the reported size in the stats will actually be less than the size limit, but the log file should show the discrepancy.

[rjl@…]

There's been a 1024-byte safety margin built into amavisd-maia for years now, to protect against a corner case where the MySQL max_allowed_packet setting and Maia's size limit setting were too close to one another and could result in a situation where Maia accepted an item that became a few bytes too large for MySQL to accept after it was encrypted. The theoretical overlap is just 55 bytes (with a 56-byte key), so the built-in 1024-byte margin that amavisd-maia enforces seems to prevent this from occurring.