On 01/11/2019 12:28 PM, John Levine wrote:
I use acme.sh which inserts them every time it renews the cert. I haven't
looked to see whether the record changes. Everything's automated and
the renewals start a while before the cert expires so if it flakes today,
it'll work tomorrow which has
In article
you write:
>> If I could give LE a hint about which NS to look at, the flakiness would
>> go away.
>
>How often do you need to update DNS records for Let's Encrypt?
I use acme.sh which inserts them every time it renews the cert. I
haven't looked to see whether the record changes.
On 01/11/2019 10:51 AM, John R Levine wrote:
In my case the problem is that I swap DNS secondary service with the ISP
down the road, and his name servers don't always pick up changes when I
poke it.
Nice trade.
If I could give LE a hint about which NS to look at, the flakiness would
go
On Fri, 11 Jan 2019, Ned Freed wrote:
From what I can tell there is no limit that would prevent you from maintaining
as many domains as you want, even in the presence of a 2% valiation failure
rate - a rate which, if I had it, I would consider unacceptable and would
consider fixing it a top
> In article <01r1svv1718u000...@mauve.mrochek.com> you write:
> >Agreed, but to be fair, there is a 500 domain per IP limit with Let's
> >Encrypt.
> >But 500 is a lot more than 80, and if you're servicing over 500 domains that
> >sounds like a fairly commercial enterprise to me, with all that
On 01/10/2019 12:09 PM, John Levine wrote:
It is a poor idea to assume that everyone else's setup is like yours.
Agreed.
Similar with experience.
That's why I try to always articulate when I'm saying things based on my
experience / configuration and give ample amounts of room for people to
In article ,
A. Schulze wrote:
>
>
>Am 09.01.19 um 17:34 schrieb John Levine:
>> If you have to validate 80 names, and each validation works 98% of the
>> time, validating all 80 alt names in a row only works 19% of the time.
>> That's the scalability issue.
>
>I run a webserver for > 1000
In article <893cac17-bcc8-3189-b694-1de31e5b7...@spamtrap.tnetconsulting.net>
you write:
>-=-=-=-=-=-
>
>On 01/09/2019 08:04 PM, John Levine wrote:
>> Since MUAs don't talk to MXes, I have no idea what this is supposed to mean.
>
>MUAs talk to MSA's, which in my experience are usually also an
On 01/09/2019 06:11 AM, John Levine wrote:
> Yes, I know. The chances of verifying 80 names in a row without one of
> them glitching does not seem high. I'd probably get rate limited first.
> The usual LE rollover for a single cert starts quite a long time before
> the old cert expires so if it
On Thu, Jan 10, 2019 at 05:41:30PM +, Salz, Rich wrote:
> I never said MTA STS did not scale. IF somehow I gave that impression, I
> apologize.
I did not hold firm on the MX pattern as SAN constraint rather than
MX name constraint, yielding to EKR's objection. So as a result,
deployment
On 01/09/2019 08:04 PM, John Levine wrote:
> Since MUAs don't talk to MXes, I have no idea what this is supposed to mean.
MUAs talk to MSA's, which in my experience are usually also an MTA.
Even if inbound and outbound MTAs are separated, they are usually
administered in the same manner.
Not
I never said MTA STS did not scale. IF somehow I gave that impression, I
apologize.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
Am 09.01.19 um 17:34 schrieb John Levine:
> If you have to validate 80 names, and each validation works 98% of the
> time, validating all 80 alt names in a row only works 19% of the time.
> That's the scalability issue.
I run a webserver for > 1000 domains. Fully automated, with one guiding
On 01/09/2019 08:04 PM, John Levine wrote:
Since MUAs don't talk to MXes, I have no idea what this is supposed to mean.
MUAs talk to MSA's, which in my experience are usually also an MTA.
Even if inbound and outbound MTAs are separated, they are usually
administered in the same manner. So
> >AFAIK, the relevant Let's Encrypt limits are:
> That might be right, it might not.
It's the value they document. Here's a link:
https://letsencrypt.org/docs/rate-limits/
I also note that I missed the point that this limit only applies on creation,
not renewal. So it doesn't look
In article
you write:
>-=-=-=-=-=-
>
>On 01/09/2019 07:22 AM, John Levine wrote:
>> until STS came along there was no expectation that the name the client
>> used matches the cert.
>
>I've been seeing MUAs complain about the CN or SAN(s) not matching the
>FQDN for years. Completely
>AFAIK, the relevant Let's Encrypt limits are:
That might be right, it might not. Making deployment policies based on soft
guidelines is probably not going to scale well.
Yes, if we made everyone use TLS for all inter-node transport, things would be
better. But we can't. Next!
On Wed, Jan 09, 2019 at 01:28:29PM -0700, Grant Taylor wrote:
> On 01/09/2019 06:11 AM, John Levine wrote:
> > Yes, I know. The chances of verifying 80 names in a row without one of
> > them glitching does not seem high. I'd probably get rate limited first.
> > The usual LE rollover for a single
On 01/09/2019 07:22 AM, John Levine wrote:
until STS came along there was no expectation that the name the client
used matches the cert.
I've been seeing MUAs complain about the CN or SAN(s) not matching the
FQDN for years. Completely independent of MTA-STS.
--
Grant. . . .
unix || die
On 01/09/2019 06:11 AM, John Levine wrote:
Yes, I know. The chances of verifying 80 names in a row without one of
them glitching does not seem high. I'd probably get rate limited first.
The usual LE rollover for a single cert starts quite a long time before
the old cert expires so if it
In article <01r1svv1718u000...@mauve.mrochek.com> you write:
>Agreed, but to be fair, there is a 500 domain per IP limit with Let's Encrypt.
>But 500 is a lot more than 80, and if you're servicing over 500 domains that
>sounds like a fairly commercial enterprise to me, with all that implies.
> On 8 Jan 2019 15:59:30 -0500
> "John R Levine" wrote:
> > I can set up the TXT records easily enough, but it looks like I need
> > an HTTPS server with 80 names and 80 certficates, or one certificate
> > with 80 alt names. That doesn't scale very well.
> I believe the thing you want is
In article <20190109164709.6f869d92@computer> you write:
>On 8 Jan 2019 15:59:30 -0500
>"John R Levine" wrote:
>
>> I can set up the TXT records easily enough, but it looks like I need
>> an HTTPS server with 80 names and 80 certficates, or one certificate
>> with 80 alt names. That doesn't
On 8 Jan 2019 15:59:30 -0500
"John R Levine" wrote:
> I can set up the TXT records easily enough, but it looks like I need
> an HTTPS server with 80 names and 80 certficates, or one certificate
> with 80 alt names. That doesn't scale very well.
I believe the thing you want is automation.
Well, like I said, STS requires clients to provide SNI, so they should not
consider it an STS violation if they don't send SNI and consequently get
the wrong cert.
I am not claiming your setup is broken--just that among possible fixes (a
cert with many SANs, using SNI to serve one cert of many,
>The larger issue is that this is the same unfortunate road that SPF
and DMARC went down. Oh, our magic bullet can't handle your totally
standard but slightly unsusual setup, so we will retroactively redefine
it as broken.
Yeah, we're not allowed to do that.
It's one of the
On 1/9/19 6:22 AM, John Levine wrote:
In article
you write:
I think this is hard. You probably could get a single cert with SANs for
all of your 80 domains, or one for each new domain, but you will have to
figure out how to automate this (and I guess use SNI to pick the right cert
on the
In article
you write:
>I think this is hard. You probably could get a single cert with SANs for
>all of your 80 domains, or one for each new domain, but you will have to
>figure out how to automate this (and I guess use SNI to pick the right cert
>on the server side--note that the RFC does
In article <9361f00f-3962-7611-c55d-e01208488...@domblogger.net> you write:
>Note that you can use certbot to submit a CSR with multiple alternative
>names and if desired re-uses the private key to reduce DANE rollover
>issues. That's what I do with Let's Encrypt, only change the private key
In article you write:
>You said that you control the DNS for the 80 domains. Is there any
>reason you can't use a common MX name for them?
I don't want to. The current setup works fine, and the separate MX names make
it somewhat easier to track down some kinds of problems.
On 1/9/19 3:15 AM, Daniel Margolis wrote:
*snip*
/
I think this is hard. You probably could get a single cert with SANs for
all of your 80 domains, or one for each new domain, but you will have to
figure out how to automate this (and I guess use SNI to pick the right
cert on the server
> On Jan 8, 2019, at 9:11 PM, Peter Gutmann wrote:
>
>> https://github.com/danefail/list :-(
>
> Woah, that's taking a DNSSEC mechanism back to the state of HOSTS.TXT from the
> 1980s. Once dane_fail_list.dat gets too big to be hand-edited, will someone
> create a global distributed database
Viktor Dukhovni writes:
>https://github.com/danefail/list :-(
Woah, that's taking a DNSSEC mechanism back to the state of HOSTS.TXT from the
1980s. Once dane_fail_list.dat gets too big to be hand-edited, will someone
create a global distributed database that can be queried for entries? You
> On Jan 8, 2019, at 5:24 PM, A. Schulze wrote:
>
> And there are already some (unintended) proofs that DANE work.
> Mostly because the recipient did not properly handled a MX certificate
> rollover.
https://github.com/danefail/list :-(
--
Viktor.
Am 08.01.19 um 23:02 schrieb Grant Taylor:
> I'm not aware of anything else that provides the signal that MTA-STS provides.
Oh, it's DANE, as I understand it.
A DANE aware sender will not transmit a message if validation for a DANE aware
recipient domain fail.
And there are already some
On 01/08/2019 03:18 PM, Viktor Dukhovni wrote:
DANE for SMTP as defined in RFC7672 as strictly stronger than MTA-STS.
For clients that implement the DANE spec, TLS and authentication are
mandatory with receiving MX hosts that publish TLSA records, and unlike
MTA-STS the signalling is
> On Jan 8, 2019, at 5:02 PM, Grant Taylor
> wrote:
>
> On 01/08/2019 02:35 PM, Viktor Dukhovni wrote:
>> That's OK, you have working DANE, you mostly don't need MTA-STS.
>
> Wait a minute.
>
> Maybe it's the "mostly" qualifier there, but I thought first S was one of the
> critical parts of
On 1/8/19 12:59 PM, John R Levine wrote:
> Adding to the excitement, every domain has its own name for the mail
> server, e.g., for foo.com the mail server name is mx1.foo.com, all
> pointing at the same IP address. (This is not unusual; Tucows
> hostedemail does the same thing with much longer
Am 08.01.19 um 21:59 schrieb John R Levine:
> Adding to the excitement, every domain has its own name for the mail server,
> e.g., for foo.com the mail server name is mx1.foo.com, all pointing at the
> same IP address.
Oh, just re-read that.
this makes it really hard. So you could only
On Tue, Jan 08, 2019 at 03:59:30PM -0500, John R Levine wrote:
> I have about 80 domains pointed at my mail server. I control the DNS for
> all of them but I can't see any reasonable way to make MTA-STS work.
>
> I can set up the TXT records easily enough, but it looks like I need an
> HTTPS
Am 08.01.19 um 21:59 schrieb John R Levine:
> I have about 80 domains pointed at my mail server. I control the DNS for all
> of them but I can't see any reasonable way to make MTA-STS work.
>
> I can set up the TXT records easily enough, but it looks like I need an HTTPS
> server with 80
I have about 80 domains pointed at my mail server. I control the DNS for
all of them but I can't see any reasonable way to make MTA-STS work.
I can set up the TXT records easily enough, but it looks like I need an
HTTPS server with 80 names and 80 certficates, or one certificate with 80
alt
42 matches
Mail list logo
