Re: The issue of mime parsing

Rickard Armiento <[email protected]>:

>   https://example.com/cgi/im2k.cgi?msgid=8A932r89&part=mybody.txt
> I.e,: a message is fetched by running a cgi-script on the server
> that besides giving out a message part, also carefully keeps track
> of its delivery status.
>
> [snip]
>
> Now, instead of having 'external-body' servers "telling" the
> outgoing im2k server every time a message has been downloaded, I
> suggest that their role is only to serve parts and keep track of
> downloads.  Instead we let the outgoing im2k server iterate over
> each email and fetch delivery status data from the 'external-body
> servers' to decide if that message's "delivery finished" criteria is
> fullfilled.

that's it.  "bounces"(?) are generated like this:  the sending server
associates a flag with the parts offered:  was it downloaded in time
or not?  it compares the (cash-) expiry deadline with the latest
download attempt and returns a bounce only for messages offered, but
never downloaded.

do we agree on download URIs to be hard-to-guess big numbers?  this
simplifies notification.

  https://example.com/cgi/im2k.cgi?msgid=8A932r89&part=mybody.txt

i hope https:// means verification of receiver certificates, but if
it doesn't, just {8A932r89, mybody.txt} is an invitation for
attackers to brute force downloads.

  clemens