Batching delete packets (Trac #1484)

Delete packets should be sent only once the entire mail has been received, and only within a the timeframe of a mail fetching, or immediatelly thereafter.

(irc: from parent ticket, continued)


user: you'd send the deletes only when the user actually logs in, giving more information about the actual user behaviour
user: if, however, you delay the deletes again, then maybe it could be a good idea
user: so deletion must be only once the entire mail is downloaded, not already when one packet downloaded then send deletion for that, in all cases. Then in the half logged in case, once user logs in and decrypts deletion packets for all packets are queueed but only sent when next [or second next - use some randomness] regular mail check is triggered for that identity
<str4d@irc2p> But you're right that it would give more indication of user behavior
<str4d@irc2p> Queuing deletion packets for sending at email checks is a good idea
<str4d@irc2p> Yes
<str4d@irc2p> It does make sense to have all network-touching activity around a single identity occur at the same time
user: and if in the "normal" case, i.e. now, the deletion packets are not sent based on when the single packet was retrieved, but rather the entire mail then this would obscure the user activity a bit
user: because others could not tell whether [the delay in] sending deletion packets was due to user not being logged in, or because of a packet still missing and only being downloaded in a later run
user: it would, however, delete all packets belonging to the same mail at once. Would that be an issue?
user: i think it would also be otherwise wanted behaviour. A user backing up only his keys but not incomplete messages, inbox, sent, etc, should still be able to receive an undelivered mail after restoring from backup
user: were the packets deleted one by one intead of batchwise, this would not be possible anymore, if at least one packet was received already before the restoring

optional enhancement: scatter the sending of those deletes randomly over the next e.g. 5 mail checking/fetching 'sessions'. This would with standard check interval delay it only by less than 3 hours, but would make it less obvious to infer which packets belonged to which mail. Guess that only makes sense if you scatter-fetch too.

Migrated from https://trac.i2p2.de/ticket/1484

{
    "status": "assigned", 
    "changetime": "2017-01-15T14:09:59", 
    "description": "Delete packets should be sent only once the entire mail has been received, and only within a the timeframe of a mail fetching, or immediatelly thereafter.\n\n(irc: from parent ticket, continued)\n{{{\n\nuser: you'd send the deletes only when the user actually logs in, giving more information about the actual user behaviour\nuser: if, however, you delay the deletes again, then maybe it could be a good idea\nuser: so deletion must be only once the entire mail is downloaded, not already when one packet downloaded then send deletion for that, in all cases. Then in the half logged in case, once user logs in and decrypts deletion packets for all packets are queueed but only sent when next [or second next - use some randomness] regular mail check is triggered for that identity\n<str4d@irc2p> But you're right that it would give more indication of user behavior\n<str4d@irc2p> Queuing deletion packets for sending at email checks is a good idea\n<str4d@irc2p> Yes\n<str4d@irc2p> It does make sense to have all network-touching activity around a single identity occur at the same time\nuser: and if in the \"normal\" case, i.e. now, the deletion packets are not sent based on when the single packet was retrieved, but rather the entire mail then this would obscure the user activity a bit\nuser: because others could not tell whether [the delay in] sending deletion packets was due to user not being logged in, or because of a packet still missing and only being downloaded in a later run\nuser: it would, however, delete all packets belonging to the same mail at once. Would that be an issue?\nuser: i think it would also be otherwise wanted behaviour. A user backing up only his keys but not incomplete messages, inbox, sent, etc, should still be able to receive an undelivered mail after restoring from backup\nuser: were the packets deleted one by one intead of batchwise, this would not be possible anymore, if at least one packet was received already before the restoring\n}}}\n\noptional enhancement:\nscatter the sending of those deletes randomly over the next e.g. 5 mail checking/fetching 'sessions'. This would with standard check interval delay it only by less than 3 hours, but would make it less obvious to infer which packets belonged to which mail. Guess that only makes sense if you scatter-fetch too. \n", 
    "reporter": "user", 
    "cc": "", 
    "resolution": "", 
    "_ts": "1484489399267918", 
    "component": "apps/plugins", 
    "summary": "I2P-Bote: batching delete packets", 
    "priority": "maintenance", 
    "keywords": "I2P-Bote", 
    "version": "0.9.18", 
    "parents": "1483", 
    "time": "2015-03-04T21:34:24", 
    "milestone": "undecided", 
    "owner": "str4d", 
    "type": "enhancement"
}

i2p / i2p.i2p-bote

Batching delete packets (Trac #1484) #46