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@xxxxxxxxx> 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
>