On 8/21/20 11:54 AM, Caveman Al Toraboran wrote:
thanks. highly appreciate your time. to save space i'll skip parts
where i fully agree with/happily-learned.
You're welcome.
(e.g. loop detection; good reminder, i wasn't thinking about it.
plus didn't know of acronyms DSN, MDNs, etc; nice keywords for
further googing).
;-)
i was thinking (and still) if such relay-by-relay delivery increases
probability of error by a factor of n (n = number of relays in the
middle). e.g. probability of accidental silent mail loss is if one,
or more, accidentally said "yes got it!" but actually didn't. i.e.:
It definitely won't be a factor of n, where n is the number of relays.
i wonder if it would be better if only the entry relay aims at the
confirmation from the terminal server? this way we won't need to
assume that relays in the middle are honouring their guarantees,
hence the probability above would be smaller since k is limited up
to 2 despite n's growth.
Nope.
Each and every server MUST behave the same way.
care to point part of the rfc that defines "safe" commit to disk?
e.g. how far does the rfc expect us to go? should we execute `sync`'s
equivalent to ensure that data is actually written on disk and is
not in operating system's file system write buffer?
TL;DR: Yes on all accounts.
See the recent reply about guarantee and relays for more details.
onion signatures? e.g. message is wrapped around several layers of
signatures for every relay in the path?
That doesn't help the problem. We sort of have an onion already.
It's quite likely possible to validate the signature of the immediate
sending server. But how does the receiving server know how to undo any
modifications that the immediate sending server made to be able to
validate the previous sending server's signature? Rinse, later, repeat
out multiple levels.
What if some of the servers signs what they send vs what they receive?
These are the types of problems that don't currently have a solution.
e.g. whitelisting, tagging, spam filtration, prioritizing, etc,
based on entities that onion-signed the message.
How is doing those things based on signature different than doing them
based on the system sending to you?
The only thing that comes to mind is trusting an upstream signature, but
not the immediate sending system. But, you have to unwrap the onion to
be able to validate the signature. But to do that you need to know what
the server(s) downstream of the signature being validated did to the
message.
Some of this is a one way trap door without any indication of what each
trap door did to the message.
--
Grant. . . .
unix || die
