, or I
support adoption of this draft only to the extent that it can be
significantly changed.
AFAICT the draft hasn't been updated beyond what RFC 7525 says, so I'm
going to wait and see what those updates say before I decide if I can
support the change.
FWIW, you appear to have responded to a message that hasn't made it to
the list yet.
Ned
Short version: this is, in many cases, a Bad Idea.
To the extent email delivery is reliable, it is because of persistence
in relaying traffic. Many mail user agents are
e we won't really have an
option not to implement it. But I think the way I'm going to handle it is by
building on top of an existing minimal https client we already have, and adding
additional capabilties as the need arises. And if that c
ection
may be limited to getting the necessary certificates. And DNS names, of course.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
ly, the material comparing MTA-STS with DANE, while useful, has no value
to someone implementing this specification. As such, it has no business being
the first thing in the document. I therefore strongly recommend relegating it
to the final appendix.
That's it for now. There are undoubtedly mor
ent in our SMTP client, and I
intend to ignore anything that makes that a requirement.)
In regards to timeouts, once we get down to it I'm likely to be very concerned
about the need to access DNS TTL information as well. IME a lot of DNS APIs
don't provide access to this informatio
together is pretty much
guaranteed not to be implemented correctly.
> 2. In what case is DNS TTL information needed?
Section 3.2, first paragraph. There's also been discussion of making more
use of DNS TTL info on the list.
Ned
__
e updated and the TXT record's TTL has passed.
> Let me know if that doesn't make it more clear. But tl;dr: senders do not
> need to know the DNS TTL.
This is much clearer, and addresses my concern.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
re users would actually want more of the
> time.
I'm in complete agreement with Viktor here. This is a case of complification
masquerading as simplicity.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
ittle use.
Yep. To the point where I cannot possibly justify implementing this proposal
unless it also includes the MAY option, which looks to me to be far more
useful.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
Please post a revised draft with these changes sooner rather than later.
Thanks.
Ned
> Sounds like we go back to underscore-prefixed. Thanks for the feedback
> John.
> On Wed, Mar 1, 2017 at 5:55 AM, John Levine wrote:
> > In article <813df83a-841e-4e6a-e3a1-f28
recovery
> after the fact by signalling the availability of an updated policy.
> I would also like to encourage the authors to post revised drafts
> more frequently. Please see:
> https://www.ietf.org/mail-archive/web/ietf/current/threads.html#101804
+1000.
I'm with Viktor on this one. Having two documents where only one is
needed will not only create redundant material that needs to be kept
in sync, it's more stuff people implementing this have to read.
This is already too complicated and spread over
ed there were no problems
currently, nothing prevents someone from writing new software based on
guarantees the standards provide in regards to the meaning of media type
suffixes.
Ned
___
Uta mailing list
Uta@ietf.org
http
e media type name or its parameters.
So unless you have a time machine and can go back and change the rules defining
+json, structured syntax suffixes, content type parameters, etc. this is a
nonstarter.
Ned
___
Uta maili
on
> any sane UI/UX story for how a troubleshooter manages to introduce it --
> it's pretty much expert feature territory (e.g. those of us who edit our
> message headers by hand).
I would hope it's obvious that you don't present in a UI as
x header_checks):
> Require-TLS: NO
> Subject: [insecure-delivery]: actual subject
> or (not easy with header_checks, but hides the subject tag):
> Require-TLS: NO
> Subject: actual subject
Also trivial to do with Sieve.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
employ domain literals"
or something stronger.
That's it for now. I should note that my implementation is incomplete, and
I expect I will have more comments once I've worked through the SMTP
client additions.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
s.
> 7) Trust Anchors
> RFC 7672 suggests that MTAs cannot rely on a set of common trust anchors,
> in Section 1.3.4. While I'm not actually convinced this is really the case,
> I'm finding it odd that on the one hand, we have a consensus
> standards-track document that makes this assertion, yet on the other this
> draft makes - implicitly - the opposite assertion.
> It would be useful to understand if circumstances have changed.
Of course circumstances have changed - it's now possible to obtain
free certificates from a widely if not universally trusted CA.
But this is also a case of reality setting in. The "too many CA" problem
is pretty small beer compared to the difficulty of deploying DANE.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
nt is for the Policy Domain to
> > > support PKIX for all SMTP; and not just for specified hosts.
> >
> > Of course that's the commitment. How could it be otherwise?
> >
> Then that needs rephrasing, because I didn't see any "Of course" about it.
> A commitment by the Policy Domain to support PKIX [RFC 5280] authenticated
> TLS, using reference identifiers as listed.
> (I'm trying to guess what was meant by "for the specified MX hosts".)
The entire point of the mechanism is to say that the policy domain supports
and wants SSL/TLS transfers and that the servers have validated certs
with the specified names. So I really don't understand what you're getting
at here.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
elsewhere, as it
> is not the case in the current document.
The problem with including the id in the policy is that now you have a gap
no matter how you order the update.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
I thought I recalled
> someone was looking into a registry for "reserved" DNS names. (But from the
> perspective of STS, if someone else uses "mta-sts" for anything else, it
> doesn't really affect the operation of the system.)
Exactly. And I thi
, because small inputs
> can uncompress to unreasonably large outputs.
> Applications might want to set limits on the amount
> of data they're willing to extract from the compressed
> stream.
That's covered in the format's security considerations, but of course it could
be
arks
> as you see fit... They are not blocking objections.
Whereas in my capacity as media type suffix reviewer, it's my responsibility
to make sure that security considerations cover the full range of possible
isssues. As such, coverage of an obvious one, especially given the current
wid
don't have a problem.
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.
ne use TLS for all inter-node transport, things would
> be better. But we can't. Next!
Of course we can't. But I fail to see what that has to do with the scalability
of MTA STS.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
something on an
MSA, chances are good that the same thing will be done on an inbound MTA
that is an MX.
Only if they happen to be the same system and the person running them is
careless, incompetent, or both.
Ned
___
U
here's also a limit on validation failures that probably applies. But
it's per-host and should not be a problem.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
if I had it, I would consider unacceptable and would
consider fixing it a top priority. And I'm speaking as someone who also uses
DNS validation for a bunch of domains on a Frontier DSL connection that doesn't
exactly deliver world-class performance or reliability.
nformation.
As to whether or not ESNI is used, I actually think logging that is a bad idea,
as it doesn't really any anything useful that I can see and less is more when
it comes to this sort of stuff.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
erations
of what to include in trace fields in general, and don't obviously
align with whether or not ESNI is used.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
f alias or list the message passed
through. It might be smart enough to edit the other stuff out of the Received:
field but not the SNI information.
Ned
_______
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
missing in mail, I don't
think we can assume that any future use of ESNI would necessarily
correlate with whether or not to put SNI information in trace fields.
Ned
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
33 matches
Mail list logo
