On 2018-04-27 at 14:58 -0700, SM wrote:
> There is some information in RFC 6125.
Hi, and thanks.
It covers in appendix B.4 two previous pieces of guidance, one of which
helps a little.
The first is a vague "probably" which fails to help; I think the text
(from 2002) predated most people involved
Hi Phil,
At 11:28 AM 17-04-2018, Phil Pennock wrote:
RFC 3207 is the closest to a profile document which SMTP MX delivery
has, since RFC 7817 explicitly excludes MX coverage. 3207 doesn't
explicitly cover SNI since it predates the earliest RFC I know of
covering SNI. The only standards-track do
On 2018-04-17 at 14:28 -0400, Phil Pennock wrote:
> and for the DANE case, Exim
> always sends SNI.
I'm going prematurely senile. I could have sworn this was true but I
can find no evidence of it. Since RFCs 7671 and 7672 mandates SNI of
the DNSSEC-secured
On 2018-04-17 at 16:47 +, Brandon Long via mailop wrote:
> So, according to our tls folks, that cert is only served to TLS 1.3 clients
> that don't send SNI,
> so they wonder if you're using a pre-release version of OpenSSL without any
> changes.
Yes, Exim supports TLS 1.3 if GnuTLS or OpenSSL
On Tue, Apr 17, 2018 at 1:49 AM Phil Pennock wrote:
> In this case though, I was wrong. I've used the SNI-conditional
> certificates I'm seeing from Gmail to debug a misconfiguration in my
> overly-complex MTA config which meant that I wasn't getting
> mandated-verification when I thought it was
On 2018-04-16 at 13:04 -0400, Phil Pennock wrote:
> What's confusing to me, the next morning, is that included in the Gmail
> overrides is a force-enabling of validation (yes, using the CA system,
> but selective for remote domains where I choose to trust they're not
> going to press for a dodgy CA
On Mon, Apr 16, 2018, 1:31 PM Rolf E. Sonneveld
wrote:
> On 16-04-18 21:39, Brandon Long via mailop wrote:
>
> [...]
> > I think this is an interesting stance, and I'm sure you've heard the
> > objections to
> > this before. You don't have to trust every CA, you certainly don't need
> to
> > tru
On 16-04-18 21:39, Brandon Long via mailop wrote:
[...]
I think this is an interesting stance, and I'm sure you've heard the
objections to
this before. You don't have to trust every CA, you certainly don't need to
trust every
CA for every host, and there are other tools to be used here such as
On 2018-04-16 at 11:45 -0700, Ned Freed wrote:
> AFAIK this does not happen in MTA-STS, that is, at no time is the MX hostname
> obtained from the DNS checked against the "mx" list from the MTA-STS policy.
> Rather, the DNS-ID of the certificate returned by the server is checked
> against
> the "m
On Mon, Apr 16, 2018 at 10:05 AM Phil Pennock wrote:
> On 2018-04-16 at 05:28 +, Brandon Long via mailop wrote:
> > I always thought of SNI has the equivalent of the Host HTTP header, so
it
> > should be the hostname you're connecting to.
> >
> > That's my reading of rfc 6066 at least, and wh
> In MX delivery without DNSSEC, if Eve injects an MX record:
> gmail.com. IN MX 1 my-spy-agency.example.org.
> then using the hostname from DNS means that the client will happily go
> talk to my-spy-agency.example.org, using that as the SNI, and validating
> against that same domain, then pres
On 2018-04-16 at 05:28 +, Brandon Long via mailop wrote:
> I always thought of SNI has the equivalent of the Host HTTP header, so it
> should be the hostname you're connecting to.
>
> That's my reading of rfc 6066 at least, and what Gmail expects.
In the HTTP Host header case, the hostname us
> Il 16 aprile 2018 alle 7.28 Brandon Long via mailop ha
> scritto:
>
> I always thought of SNI has the equivalent of the Host HTTP header, so it
> should be the hostname you're connecting to.
>
> That's my reading of rfc 6066 at least, and what Gmail expects.
>
> I admit that th
On 16/04/18 03:44, Phil Pennock wrote:
While double-checking logs after an MTA update, I saw something from
Gmail which is ... bemusing. I'm wondering if there's any consensus on
how this should be handled in a manner which scales, given that Gmail
don't publish DANE records?
2018-04-16 01:14
On 16/04/18 06:28, Brandon Long via mailop wrote:
> I always thought of SNI has the equivalent of the Host HTTP header, so it
> should be the hostname you're connecting to.
>
> That's my reading of rfc 6066 at least, and what Gmail expects.
3. Server Name Indication
[...]
clients MAY include an
I always thought of SNI has the equivalent of the Host HTTP header, so it
should be the hostname you're connecting to.
That's my reading of rfc 6066 at least, and what Gmail expects.
I admit that the limited statement about sni in rfc 7817 is kind of
ambiguous since the document describes doing c
16 matches
Mail list logo
