[GH-ISSUE #43] "stream" attachments to the SMTP server on send #37

New issue

Open

opened 2026-02-25 21:33:58 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 21:33:58 +03:00

Owner

Originally created by @jasonmunro on GitHub (Mar 8, 2016).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/43

Originally assigned to: @jasonmunro on GitHub.

Currently we read attachments into memory to format them to be sent. We need to do this one line at a time so we don't overflow available memory with larger attachments.

Originally created by @jasonmunro on GitHub (Mar 8, 2016). Original GitHub issue: https://github.com/cypht-org/cypht/issues/43 Originally assigned to: @jasonmunro on GitHub. Currently we read attachments into memory to format them to be sent. We need to do this one line at a time so we don't overflow available memory with larger attachments.

kerem added the

smtp

label

2026-02-25 21:33:58 +03:00

kerem commented

2026-02-25 21:33:59 +03:00

Author

Owner

@jasonmunro commented on GitHub (Jun 21, 2016):

One issue here is we currently encrypt the attachment while it rests on the server between upload and send. If we stream these (which we should), we have to do something like line by line encryption, which presents it's own set of problems.

@jasonmunro commented on GitHub (Jun 21, 2016): One issue here is we currently encrypt the attachment while it rests on the server between upload and send. If we stream these (which we should), we have to do something like line by line encryption, which presents it's own set of problems.

kerem commented

2026-02-25 21:33:59 +03:00

Author

Owner

@dumblob commented on GitHub (Jun 21, 2016):

Well, I think we shouldn't be focused on lines, because no devices nowadays use text protocols, but rather some packets to send data over the network (not considering circuit networks which are very rarely used for plain data nowadays). I would take the maximum TCP packet payload size which causes no fragmentation (for the whole Ethernet frame it's 1492 octets in case of PPPoE/DSL, 1500 octets otherwise; after removing Ethernet frame 24 octets, IPv4 header 20 octets, and TCP header 20 octets, we'll end up with payload 1492 - 24 - 20 - 20 = 1428 octets) and split the data according to this size. Of course, not everybody is using Ethernet-based connection, but this one is most prevalent and will cover 99.999% of users of Cypht in my opinion.

In general I would avoid small pieces of data (like lines in an email), because the packet size grows (in IPv6 it's 65535 octets) and devices will try not to fragment those. It is also inefficient to cipher small pieces of data, because it involves more copying and shuffling with meta data.

For ciphering the most suitable would be of course a block cipher mode of operation of an existing cipher of your choice.

@dumblob commented on GitHub (Jun 21, 2016): Well, I think we shouldn't be focused on lines, because no devices nowadays use text protocols, but rather some packets to send data over the network (not considering circuit networks which are very rarely used for plain data nowadays). I would take the maximum TCP packet payload size which causes no fragmentation (for the whole Ethernet frame it's 1492 octets in case of PPPoE/DSL, 1500 octets otherwise; after removing Ethernet frame 24 octets, IPv4 header 20 octets, and TCP header 20 octets, we'll end up with payload 1492 - 24 - 20 - 20 = 1428 octets) and split the data according to this size. Of course, not everybody is using Ethernet-based connection, but this one is most prevalent and will cover 99.999% of users of Cypht in my opinion. In general I would avoid small pieces of data (like lines in an email), because the packet size grows (in IPv6 it's 65535 octets) and devices will try not to fragment those. It is also inefficient to cipher small pieces of data, because it involves more copying and shuffling with meta data. For ciphering the most suitable would be of course a block cipher mode of operation of an existing cipher of your choice.

kerem commented

2026-02-25 21:33:59 +03:00

Author

Owner

@marclaporte commented on GitHub (Jul 31, 2022):

@marclaporte commented on GitHub (Jul 31, 2022): Related: https://github.com/jasonmunro/cypht/issues/351 https://github.com/jasonmunro/cypht/issues/469