Paul (and others),
There is no question that the email-addrquery draft needs work,
even the author has said so. I've tried to start a thread on
the SMTP list that identifies some possible issues to be
examined. If you want to have a constructive conversation about
that draft, please move it there. Probably it would be best to
wait for the next draft and comment on it rather than attacking
-01.
None of this is relevant to the proposed experiment advocated by
dane-openpgpkey unless you want to try to convert this
discussion into "dane-openpgpkey is no worse than
email-addrquery, therefore it should be approved". I suggest
not going there because the IETF doesn't need to approve _any_
flawed protocol and, be being in Last Call, there is a claim
that dane-openpgpkey is finished and ready to go, a claim that
has never been made for email-addrquery.
I'll respond to your comment below if you want to make it on the
SMTP list, but suggest that the description of _any_
key-location or key-retrieval must mechanism be clear about the
difference between obtaining a purported key and determining its
validity for some intended use in order to be taken seriously.
This thread periodically seems to lose track of that distinction.
john
--On Wednesday, February 17, 2016 22:24 -0500 Paul Wouters
<paul(_at_)nohats(_dot_)ca> wrote:
On Tue, 16 Feb 2016, John Levine wrote:
https://tools.ietf.org/html/draft-moore-email-addrque
ry-01
Unfortunately, the draft is useless for end-to-end
encryption, as it relies on a clean path from the client to
the recipient's SMTP server ...
I would encourage anyone interested in this topic to read the
draft, particularly section 4. No, it does not depend on a
clean path from the MUA to the recipient MTA.
This section defines a service extension to the Mail
Submission
Protocol [RFC6409] which can be used by an authenticated,
authorized
client to query an SMTP server on port 25 for information
about an
email address. This is intended only as a workaround for
port 25
blocking, so the extension is minimally tailored for that
purpose.
So if my ISP is blocking port 25, I am forced to ask my ISP if
the
remote party could accept encrypted email and to which key?
It is not "end to end" encryption, if the ISP can change the
outcome.
So again, the above draft does not provide a workable solution
for
the openpgpkey draft.
Paul