On Thu, Jan 05, 2017 at 05:29:44AM -0700, Daniel Margolis wrote: > On Wed, Jan 4, 2017 at 10:16 AM, Alberto Bertogli <[email protected]> > wrote: > > > > > Hi! Happy new year! > > > > I had some time during the holidays and started to do a basic > > implementation of the latest MTA-STS draft. > > > > While doing so, there were a couple of things I wasn't sure about so I'd > > thought I'd ask: > > > > - What happens if the "mx" field is missing from the policy? > > Should the MTA skip checking the field but honour the rest of the policy, > > treat the policy as invalid, or assume no MX is valid? > > > > The "mx" field is required, so if it is missing, the policy is invalid and > should not be honored. (It doesn't make sense to honor the policy anyway, I > would say, since a policy without allowed MXs is essentially a way of > saying, "There should be TLS and the server identity should match the MX, > whatever the MX is." I guess this prevents SSL stripping, but doesn't > prevent DNS injection, so it's of relatively little value.)
Ack, thanks for clarifying! > > - For the case of an internationalized domain name, the "mx" field should > > include domain patterns in their U form (e.g. "*.ñaca.com > > <http://xn--aca-6ma.com>"), A form > > ("*.*.xn--aca-6ma.com"), or both can be present? > > > > I suppose this is underspecified in the draft! > > I would say based on https://tools.ietf.org/html/rfc6125#section-6.4.2 that > it makes the most sense for this to be in the A-form, since otherwise the > MTA would have to convert to the A form for checking. What do you think? > > I proably can make a quick change to clarify this if it seems reasonable to > those on this list. FWIW, I'm fine with any of the options. I think allowing both forms makes it easier to deploy, so I'd be slightly in favour of that. Obviously that implies that the MTAs normalize the domains before doing the comparison, but that's not that big of a burden, I hope. Given the idempotency of the forms, normalizing inconditionally will always work regardless. But as long as it's clear, I don't feel very strongly about it :) > > - The TXT record is on "_mta-sts" but the policy is on "mta-sts". Is that > > intentional? Why not putting both on the same domain, to simplify things? > > > > Yes, this is intentional. The underscore in "_mta-sts" was kept to be > similar to that in (e.g.) _dmarc TXT records, but for the HTTP host this > seemed inadvisable: > https://www.ietf.org/mail-archive/web/uta/current/msg01524.html. Interesting, I didn't know underscores in domains were not HTTP friendly, thanks for the reference. Why not unify them both under the "mta-sts" domain then? I see the appeal of the similarity with things like _dmarc, but is it worth it? > > - The draft says that clients MUST check the TXT record, but it seems to me > > it's totaly possible to make a reasonable implementation without doing > > so. > > Is it worth using "MUST" for this? > > I imagine this is related to the previous discussion we had, but > > forcing MTAs to check seemed quite strong so I was wondering if > > there was something else. > > > > I think there's some utility in specifying this as at least a SHOULD so as > to ensure common behavior--otherwise, a recipient domain that updates its > HTTP but not TXT will work some of the time for some senders, I guess? That > seems risky. > > But need it be a MUST? Probably not. The truth of the matter is, as you > say, that nobody would really know (except from slightly higher request > rates) if your implementation did HTTP-only. ;) > > I'm open to making this a SHOULD, but it's not something I have a strong > feeling about one way or another. What do you (and others) think--worth > changing to SHOULD? Better to keep a "MUST"? I think is worth changing it to SHOULD because there's no technical reason a client must do the lookup, and seeing it as MUST may be confusing. As you say above, a client can skip the lookup and still behave nicely to the domains. But it's mostly a formality, I think; I was mostly worried that there was a strong reason behind the MUST that I wasn't seeing. > > In case you're curious, the implementation I have so far is at > > https://blitiri.com.ar/git/r/chasquid/b/sts/, in particular > > https://blitiri.com.ar/git/r/chasquid/c/febad008f38c9ac980a4c0a6179a76 > > 81fed7f125/ > > (patch and branch are subject to rebasing). > > > > It's mostly fetching, parsing and checking. It has no caching or > > reporting yet; I will add them later, but thought these questions are > > independent anyway. > > > > I feel slightly bad for not having shared this earlier, but I wrote a toy > implementation here: https://github.com/danmarg/smtp-sts. As with yours, it > does not do caching or reporting; I wrote it merely to power this: > http://sts.x.af0.net. > > Feel free to copy any code you like, of course, though it's a little late > for that. ;) Cool, I'll take a look and make sure I'm not missing anything! The web tool is quite handy as well, thanks for doing that :) Thanks! Alberto _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
