[messaging] Tor Hidden Services in (Cables, SMTorP, Pond)
infinity0 at pwned.gg
Wed Jun 18 07:25:26 PDT 2014
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 880 bytes
Desc: OpenPGP digital signature
More information about the Messaging