Opened 16 years ago

Closed 12 years ago

#51 closed defect (fixed)

Mail size is incorrectly recorded when mail is encrypted

Reported by: rjl Owned by: rjl@…
Priority: low Milestone: 1.0.3
Component: amavisd-maia Version: 1.0.0 RC5
Severity: normal Keywords: encryption blowfish size encrypted


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.

Attachments (1)

0001-check_encrypted_size.patch (2.6 KB) - added by mortonda@… 12 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 16 years ago by rjl

  • Status changed from new to assigned

comment:2 Changed 15 years ago by dmorton

  • Milestone changed from 1.0.0 to 1.1.0

comment:3 Changed 14 years ago by rjl

  • Milestone changed from 1.1.0 to 1.0.2
  • patch set to 0

comment:4 Changed 14 years ago by rjl

  • Priority changed from high to low

comment:5 Changed 14 years ago by 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.

comment:6 Changed 14 years ago by dmorton

  • Milestone changed from 1.0.2 to 1.0.3

Changed 12 years ago by mortonda@…

comment:7 Changed 12 years ago by 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.

comment:8 Changed 12 years ago by mortonda@…

  • Owner changed from rjl to rjl@…

comment:9 Changed 12 years ago by rjl@…

  • Resolution set to fixed
  • Status changed from assigned to testing

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.

comment:10 Changed 12 years ago by rjl@…

  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.