On 18/06/14 15:20, Daniel Kahn Gillmor wrote: > On 06/18/2014 07:21 AM, Eleanor Saitta wrote: >> On 2014.06.18 00.31, Daniel Kahn Gillmor wrote: >>> I was surprised by this claim as well -- my current expectation is >>> that i have *no idea* when my mail reaches the receiver's mailpile >>> (and i'm fine with that, tbh). >> >> You do expect to know when your message reaches their MTA, and if you >> don't have a good idea of how long that's going to take (measured on >> the order of ten minute increments), email becomes an entirely >> different medium vs. how it's currently used, especially in business >> settings. > > but "reaches their MTA" is not the same as "reaches the user's MUA", > which is what i thought "reaches their mailpile" meant. > > This means that currently, the recipient's MTA acts as a "receive > proxy". (in most modern mail setups, the sender relays their own mail > through their own MTA, which itself acts as a "send proxy" as well, but > that's not required). > > That suggests to me that current expectations indicate the need for a > "receive proxy", no? I don't think i understand how to get to the > conclusion that a "send proxy" is warranted based on these expectations. >
For end-to-end security the MTA is irrelevant; acknowledgements / delivery receipts should be authenticated using the end peer's credentials, otherwise regarded as potentially-bogus. One point I forgot to express in my last email, is that the receiver should of course only do this for senders they expect to receive mail from - which is why auto-delivery-receipts would be bad for email. However in an end-to-end secure system, I hope the former requirement would be already be satisfied via other mechanisms. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
