ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] DKIM encryption, was Request for discussion

2013-10-16 17:20:18


--On Wednesday, October 16, 2013 17:35 -0400 John R Levine
<johnl(_at_)taugh(_dot_)com> wrote:

Sender fetches TXT _encrypt._domainkey.recipient.com.  If it
exists, it uses the p= public key to encrypt the whole
message, embeds it as a MIME application/dkim-encrypted body
in a new message to the original address, and sends it off.
...

Interesting idea as long as both sender and recipient trust
the delivery server.

Well, sure, but my thought here is that it gives you about 90%
of what the Google proposal does for about 20% of the cost.
If you don't trust the delivery server, you have to unwrap in
the recipient MUA, which means per user keys, and we've
reinvented PGP and S/MIME.

Absolutely to both.  And the Wei Chuang et al proposal requires
one to trust the delivery server and every relay server along
the path, so it is no better (and probably worse) along that
dimension.

But _please_ don't use Postmaster.

Keep in mind that the idea here is that mail with a
dkim-encrypted body is unwrapped and readdressed before
delivery, so the mailbox doesn't matter much.

The mailbox doesn't matter much, but Postmaster does because
some systems intercept that address and give it special
treatment _very_ early in processing, occasionally even before
"mailbox" in the usual sense becomes relevant.  Independent of
what 2142 and other things say, it (and, atypically, its
case-insensitive variants) is the only recipient address
reserved and required from RFC 821 forward.

Having recently reviewed the list of addresses in RFC 2142,
I'm leaning toward uucp@.

:-)
But wfm.  Anything but Postmaster.

best,
    john

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>