You pay full handshake setup only if you don't have a shared key. If reducing bandwidth is the priority you would always set up a key on first connection and use the maximum allowable expiry time (10 days?) so long as you reconnect this often you never do another full handshake since you have a key (and you're allowed to get a new key with the old one, resetting the expiry timestamp each time).

With this slimming approach you also wouldn't use these grotesque "... and here's a portrait of my dog" type certificates we sometimes see, that may be several kilobytes in size, nor use the lengthy RSA keys. You'd do the minimum possible certificate for a single name and an EC key.

So it'll probably cost ~1kB on first connection and then only a few hundred bytes on subsequent connections, without any special components, this all just works with generic software you already have if configured appropriately.

You can shave a little more off if you agree to custom configure everything since the proof-by-certificate isn't mandatory in TLS per se, you can do everything with shared keys if you agree out of band what those keys are. This is intended for IoT-type applications.

1-RTT TLS 1.3 handshake with small ECC keys and certificate chain optimized for size, and TLS shouldn't be a problem to sync mail over slow connection.