>The documentation says:
>
>Changed in version 3.4.3: This class now performs all the necessary
> certificate
>and hostname checks by default. To revert to the previous, unverified,
> behavior
>ssl._create_unverified_context() can be passed to the context parameter.
>
>So it seems
> On May 2, 2016, at 9:06 PM, John Levine wrote:
>
> Is it really that hard to look at the documentation for the python
> libraries? It's right here:
> https://docs.python.org/3/library/http.client.html
>
> By default, the https library checks the certificate chain against
Whether we use sub-domain or .well-known URL path to serve STS policies, I'm
not sure whether we can guarantee uniqueness with the resource. I think
sub-domains are better because it helps the Mail admins to control those
policies - means they can make updates to these endpoint without
>Cute, but likely completely insecure. I see no check that the
>certificate chain is trusted.
Is it really that hard to look at the documentation for the python
libraries? It's right here: https://docs.python.org/3/library/http.client.html
By default, the https library checks the certificate
Cool, thanks for sharing that, John.
I should note that even we are considering fetching these policies from
outside the MTA, so a script like this running in its own cron job against
the last hour's unique domains could be a totally viable option. I offer
this for those who were reluctant to
>Honestly I can't tell from the thread if there is consensus or not.
I don't think it's perfect, but I do think the problem it addresses
is real and the basic approach: publishing policies, and collecting
reports about actual practices is sound.
So yes, please adopt it so we can fix the
>
> This starts an adoption call for adoption as a WG document. Please
> indicate your support or objection (with motivation) for WG adoption
> no later than EOB (any TZ) May 1st
>
Honestly I can't tell from the thread if there is consensus or not.
> > On 1 May 2016, at 11:29, Stephen Farrell wrote:
> >
> > Wouldn't the same argument tend to indicate SRV or a sub-domain are
> > as troublesome, given in many enterprises, mail and DNS can be in
> > different silos? After all, isn't that the core of the stated
On Mon, May 02, 2016 at 07:06:42AM +0200, Daniel Margolis wrote:
> > > My impression from the converstation in B.A. was that it'd be
> > > a big problem.
>
> Probably the most likely answer is that it would be easier than deploying
> DNSSEC and harder than deploying at a custom host. For us it's
> On 1 May 2016, at 11:29, Stephen Farrell wrote:
>
> Wouldn't the same argument tend to indicate SRV or a sub-domain are
> as troublesome, given in many enterprises, mail and DNS can be in
> different silos? After all, isn't that the core of the stated argument
> for
10 matches
Mail list logo