Re: [dmarc-ietf] Treewalk causing changes
The current algorithm effectively says that you can have subdomain policies, or you can have relaxed alignment, but you cannot have both. This does not meet my definition of upward-compatible. However, if we are willing to deprecate major functionality in the pursuit of freedom from the PSL, then lets deprecate relaxed alignment. Domain owners who are serious about DMARC will sign every message. When signing a message, it is no great inconvenience to sign it using the exact match domain. Relaxed alignment is not necessary. With this change, the tree walk is used to determine whether a higher-level policy exists or not. If none exists on the From domain, but one does exist above, then the result is FAIL. - - - - On my earlier proposal, I am surprised that you are willing to assume that everyone of importance will embrace this new and unproven algorithm to kill the PSL, but no one is willing to add a clause to their policy record. Which is the greater effort? Doug Foster On Mon, Feb 27, 2023 at 12:51 PM John Levine wrote: > It appears that Murray S. Kucherawy said: > >3) Since the goal is to wind down dependence on the PSL, I suggest that an > >implementation might choose to make the algorithm selectable, but I don't > >think the specification should. > > If for some inexplicable reason you really want to keep using the PSL > you can keep using your current DMARC software. Not our problem. > > Like everyone else, I see no reason to encruft our design with hacks > intended > to address hypothetical problems that do not actually exist. > > R's, > John > > PS: On my list of things I may or may not get around to doing is a web > page where you can enter a domain name and it'll tell you whether > you'll get different results with old and new DMARC. > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Question on RFC7489: trailing whitespaces
Seems reasonable. Thanks for the warning on the required white space engineering. Scott K On February 27, 2023 6:05:11 PM UTC, John Levine wrote: >It appears that Tim Wicinski said: >>-=-=-=-=-=- >> >>I agree that we should fix this tolerance in the bis document. > >I made a pull request. The change is four characters but the pull request >looks complicated because I had to futz with whitespace to keep xml2rfc >from complaining that things are too wide. > >R's, >John > >>On Mon, Feb 27, 2023 at 9:48 AM Murray S. Kucherawy >>wrote: >> >>> On Mon, Feb 27, 2023 at 2:29 AM Tõnu Tammer >>> wrote: >>> I am curious to know what the stance is on trailing whitespace within DMARC records. Strictly following the RFC 7489 and the formal specification in section 6.4, if there is no trailing dmarc-sep with the associated semicolon, trailing whitespace is not allowed. For example a record like: "v=DMARC1; p=reject; pct=100 " would be invalid, whereas "v=DMARC1; p=reject; pct=100 ; " would be valid. >>> >>> I think your interpretation is correct, that's what the specification >>> says. A parser would be right to reject it. >>> >>> As an implementer, I would probably tolerate this. Trailing whitespace >>> has almost never been something worth failing on in my experience. >>> >>> I would also suggest that the working group discuss making such tolerance >>> explicit in the bis document if it's not too late to add a small issue for >>> consideration. >>> >>> -MSK, no hat on >>> ___ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> >>-=-=-=-=-=- >>[Alternative: text/html] >>-=-=-=-=-=- > > >___ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Question on RFC7489: trailing whitespaces
It appears that Tim Wicinski said: >-=-=-=-=-=- > >I agree that we should fix this tolerance in the bis document. I made a pull request. The change is four characters but the pull request looks complicated because I had to futz with whitespace to keep xml2rfc from complaining that things are too wide. R's, John >On Mon, Feb 27, 2023 at 9:48 AM Murray S. Kucherawy >wrote: > >> On Mon, Feb 27, 2023 at 2:29 AM Tõnu Tammer >> wrote: >> >>> I am curious to know what the stance is on trailing whitespace within >>> DMARC records. >>> >>> Strictly following the RFC 7489 and the formal specification in section >>> 6.4, if there is no trailing dmarc-sep with the associated semicolon, >>> trailing whitespace is not allowed. >>> >>> >>> >>> For example a record like: "v=DMARC1; p=reject; pct=100 " would be >>> invalid, >>> whereas "v=DMARC1; p=reject; pct=100 ; " would be valid. >>> >> >> I think your interpretation is correct, that's what the specification >> says. A parser would be right to reject it. >> >> As an implementer, I would probably tolerate this. Trailing whitespace >> has almost never been something worth failing on in my experience. >> >> I would also suggest that the working group discuss making such tolerance >> explicit in the bis document if it's not too late to add a small issue for >> consideration. >> >> -MSK, no hat on >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > >-=-=-=-=-=- >[Alternative: text/html] >-=-=-=-=-=- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
It appears that Murray S. Kucherawy said: >3) Since the goal is to wind down dependence on the PSL, I suggest that an >implementation might choose to make the algorithm selectable, but I don't >think the specification should. If for some inexplicable reason you really want to keep using the PSL you can keep using your current DMARC software. Not our problem. Like everyone else, I see no reason to encruft our design with hacks intended to address hypothetical problems that do not actually exist. R's, John PS: On my list of things I may or may not get around to doing is a web page where you can enter a domain name and it'll tell you whether you'll get different results with old and new DMARC. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Question on RFC7489: trailing whitespaces
On Mon 27/Feb/2023 16:17:33 +0100 Tim Wicinski wrote:
I agree that we should fix this tolerance in the bis document.
I agree we should fix the grammar, but the general syntax of dmarcbis allows
trailing spaces.
I tried and verified it using the IETF's extractor[*] and an ABNF to regex
conversion tool[†] (I found no other tools to check ABNF).
I had to simplify the rules, e.g. excluding URI.
For dmarcbis, I had to replace dmarc-version with the old one, because the tool
doesn't support RFC 7405 (There's an open issue on Github[‡]). The tool
complained about 'dmarc-value = %x20-3A | %x3C-7E', where | has to be replaced
with /.
The results are as follows:
$ printf 'v=DMARC1; p=reject; pct=100\nv=DMARC1; p=reject; pct=100;\nv=DMARC1;
p=reject; pct=100 \n' | grep -nP '^[Vv][ \t]*\=[ \t]*DMARC1[ \t]*;[ \t]*(([Pp][
\t]*\=[
\t]*([Nn][Oo][Nn][Ee]|[Qq][Uu][Aa][Rr][Aa][Nn][Tt][Ii][Nn][Ee]|[Rr][Ee][Jj][Ee][Cc][Tt])))?([
\t]*;[ \t]*([Ss][Pp][ \t]*\=[
\t]*([Nn][Oo][Nn][Ee]|[Qq][Uu][Aa][Rr][Aa][Nn][Tt][Ii][Nn][Ee]|[Rr][Ee][Jj][Ee][Cc][Tt])))?([
\t]*;[ \t]*[Rr][Uu][Aa][ \t]*\=[ \t]*((\![0-9]+[KkMmGgTt]?)?)([ \t]*,[
\t]*((\![0-9]+[KkMmGgTt]?)?))*)?([ \t]*;[ \t]*[Rr][Uu][Ff][ \t]*\=[
\t]*((\![0-9]+[KkMmGgTt]?)?)([ \t]*,[ \t]*((\![0-9]+[KkMmGgTt]?)?))*)?([ \t]*;[
\t]*([Aa][Dd][Kk][Ii][Mm][ \t]*\=[ \t]*[RrSs]))?([ \t]*;[
\t]*([Aa][Ss][Pp][Ff][ \t]*\=[ \t]*[RrSs]))?([ \t]*;[ \t]*[Rr][Ii][ \t]*\=[
\t]*[0-9]+)?([ \t]*;[ \t]*([Ff][Oo][ \t]*\=[ \t]*(0|1|[DdSs])([ \t]*\:[
\t]*(0|1|[DdSs]))*))?([ \t]*;[ \t]*[Pp][Cc][Tt][ \t]*\=[ \t]*[0-9]{1,3})?([
\t]*;[ \t]*)?$'
1:v=DMARC1; p=reject; pct=100
2:v=DMARC1; p=reject; pct=100;
and
$ printf 'v=DMARC1; p=reject; pct=100\nv=DMARC1; p=reject; pct=100;\nv=DMARC1;
p=reject; pct=100 \n' | grep -nP '^[Vv][ \t]*\=[ \t]*DMARC1([ \t]*;[
\t]*[A-Za-z]+[ \t]*\=[ \t]*[ -\:\<-~]+)*([ \t]*;[ \t]*)?$'
1:v=DMARC1; p=reject; pct=100
2:v=DMARC1; p=reject; pct=100;
3:v=DMARC1; p=reject; pct=100
Best
Ale
--
[*] https://author-tools.ietf.org/abnf
[†] https://www.msweet.org/abnf/index.html
[‡] https://github.com/michaelrsweet/abnf/issues/5
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
I can not agree more than 100 percent on this. The PSL has issues. We need to stop depending on it. If anything, the PSD work has shown the W3C folks that there is a path forward for folks who need to do PSL-like things without boiling the ocean. tim (who has spent a bit too much time recently attempting to work out a success path for DBOUND2) On Mon, Feb 27, 2023 at 10:08 AM Scott Kitterman wrote: > > > On February 27, 2023 3:04:11 PM UTC, "Murray S. Kucherawy" < > superu...@gmail.com> wrote: > >On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster < > >dougfoster.emailstanda...@gmail.com> wrote: > > > >> The current text has an incentive problem. For an evaluator, the PSL > >> works fine. Unless an evaluator is Google-class, receiving mail from > >> everywhere in the world, most of the PSL entries will never be examined > and > >> most of the PSL errors will never be exposed. When an error is > detected > >> by an evaluator, it is a trivial effort to add or remove a record from > the > >> local copy of PSL. For evaluators, the PSL works fine. > >> > > > >The notion that different operators are using slightly different versions > >of the PSL is one of the reasons we want to stop depending on the PSL. I > >don't think we should offer this as an option. > > > > > >> Domain owners / message senders are the ones who should be powerfully > >> motivated to replace the PSL. If so, they should be willing to add a > tag > >> that invokes MUST USE TREE WALK because it eliminates ambiguity and > >> protects them from the PSL. With that elimination of ambiguity > >> and corresponding MUSRT, evaluators have a reason to change. Without > >> that, evaluators have every reason to ignore this new, unproven, and > >> imperfect algorithm; > >> > > > >I'm worried about leaving operators with a choice here, for a number of > >reasons: > > > >1) "pct" also presented a choice, and the consensus appears to be that > this > >didn't work out at all, for the reasons previously given (mostly related > to > >variance in implementations). > > > >2) "Stop using the PSL" as a goal is delayed or even thwarted if we add > >such a tag. It creates an undefined, possibly infinite, period of > >migration during which operators can opt out. If we're going to do this, > >we should discuss including some kind of firm sunset period for the PSL. > >But now we're walking in the direction of having a flag day, and everybody > >hates those. > > > >3) Since the goal is to wind down dependence on the PSL, I suggest that an > >implementation might choose to make the algorithm selectable, but I don't > >think the specification should. > > > >-MSK > > 100 percent agree. The only way to stop doing something is to stop doing > it. The specification is all we control. Implementers will adjust and > transition to the IETF design based on their own business timelines. > > Scott K > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Question on RFC7489: trailing whitespaces
I agree that we should fix this tolerance in the bis document. tim with no hat on On Mon, Feb 27, 2023 at 9:48 AM Murray S. Kucherawy wrote: > On Mon, Feb 27, 2023 at 2:29 AM Tõnu Tammer > wrote: > >> I am curious to know what the stance is on trailing whitespace within >> DMARC records. >> >> Strictly following the RFC 7489 and the formal specification in section >> 6.4, if there is no trailing dmarc-sep with the associated semicolon, >> trailing whitespace is not allowed. >> >> >> >> For example a record like: "v=DMARC1; p=reject; pct=100 " would be >> invalid, >> whereas "v=DMARC1; p=reject; pct=100 ; " would be valid. >> > > I think your interpretation is correct, that's what the specification > says. A parser would be right to reject it. > > As an implementer, I would probably tolerate this. Trailing whitespace > has almost never been something worth failing on in my experience. > > I would also suggest that the working group discuss making such tolerance > explicit in the bis document if it's not too late to add a small issue for > consideration. > > -MSK, no hat on > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
On February 27, 2023 3:04:11 PM UTC, "Murray S. Kucherawy" wrote: >On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster < >dougfoster.emailstanda...@gmail.com> wrote: > >> The current text has an incentive problem. For an evaluator, the PSL >> works fine. Unless an evaluator is Google-class, receiving mail from >> everywhere in the world, most of the PSL entries will never be examined and >> most of the PSL errors will never be exposed. When an error is detected >> by an evaluator, it is a trivial effort to add or remove a record from the >> local copy of PSL. For evaluators, the PSL works fine. >> > >The notion that different operators are using slightly different versions >of the PSL is one of the reasons we want to stop depending on the PSL. I >don't think we should offer this as an option. > > >> Domain owners / message senders are the ones who should be powerfully >> motivated to replace the PSL. If so, they should be willing to add a tag >> that invokes MUST USE TREE WALK because it eliminates ambiguity and >> protects them from the PSL. With that elimination of ambiguity >> and corresponding MUSRT, evaluators have a reason to change. Without >> that, evaluators have every reason to ignore this new, unproven, and >> imperfect algorithm; >> > >I'm worried about leaving operators with a choice here, for a number of >reasons: > >1) "pct" also presented a choice, and the consensus appears to be that this >didn't work out at all, for the reasons previously given (mostly related to >variance in implementations). > >2) "Stop using the PSL" as a goal is delayed or even thwarted if we add >such a tag. It creates an undefined, possibly infinite, period of >migration during which operators can opt out. If we're going to do this, >we should discuss including some kind of firm sunset period for the PSL. >But now we're walking in the direction of having a flag day, and everybody >hates those. > >3) Since the goal is to wind down dependence on the PSL, I suggest that an >implementation might choose to make the algorithm selectable, but I don't >think the specification should. > >-MSK 100 percent agree. The only way to stop doing something is to stop doing it. The specification is all we control. Implementers will adjust and transition to the IETF design based on their own business timelines. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The current text has an incentive problem. For an evaluator, the PSL > works fine. Unless an evaluator is Google-class, receiving mail from > everywhere in the world, most of the PSL entries will never be examined and > most of the PSL errors will never be exposed. When an error is detected > by an evaluator, it is a trivial effort to add or remove a record from the > local copy of PSL. For evaluators, the PSL works fine. > The notion that different operators are using slightly different versions of the PSL is one of the reasons we want to stop depending on the PSL. I don't think we should offer this as an option. > Domain owners / message senders are the ones who should be powerfully > motivated to replace the PSL. If so, they should be willing to add a tag > that invokes MUST USE TREE WALK because it eliminates ambiguity and > protects them from the PSL. With that elimination of ambiguity > and corresponding MUSRT, evaluators have a reason to change. Without > that, evaluators have every reason to ignore this new, unproven, and > imperfect algorithm; > I'm worried about leaving operators with a choice here, for a number of reasons: 1) "pct" also presented a choice, and the consensus appears to be that this didn't work out at all, for the reasons previously given (mostly related to variance in implementations). 2) "Stop using the PSL" as a goal is delayed or even thwarted if we add such a tag. It creates an undefined, possibly infinite, period of migration during which operators can opt out. If we're going to do this, we should discuss including some kind of firm sunset period for the PSL. But now we're walking in the direction of having a flag day, and everybody hates those. 3) Since the goal is to wind down dependence on the PSL, I suggest that an implementation might choose to make the algorithm selectable, but I don't think the specification should. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Question on RFC7489: trailing whitespaces
On Mon, Feb 27, 2023 at 2:29 AM Tõnu Tammer wrote: > I am curious to know what the stance is on trailing whitespace within > DMARC records. > > Strictly following the RFC 7489 and the formal specification in section > 6.4, if there is no trailing dmarc-sep with the associated semicolon, > trailing whitespace is not allowed. > > > > For example a record like: "v=DMARC1; p=reject; pct=100 " would be > invalid, > whereas "v=DMARC1; p=reject; pct=100 ; " would be valid. > I think your interpretation is correct, that's what the specification says. A parser would be right to reject it. As an implementer, I would probably tolerate this. Trailing whitespace has almost never been something worth failing on in my experience. I would also suggest that the working group discuss making such tolerance explicit in the bis document if it's not too late to add a small issue for consideration. -MSK, no hat on ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
Barry, I think you have forgotten that organizational domain is needed for relaxed alignment as well as disposition request. You cannot do relaxed alignment correctly unless you find and use the correct organizational domain. The current text has an incentive problem. For an evaluator, the PSL works fine. Unless an evaluator is Google-class, receiving mail from everywhere in the world, most of the PSL entries will never be examined and most of the PSL errors will never be exposed. When an error is detected by an evaluator, it is a trivial effort to add or remove a record from the local copy of PSL. For evaluators, the PSL works fine. Domain owners / message senders are the ones who should be powerfully motivated to replace the PSL. If so, they should be willing to add a tag that invokes MUST USE TREE WALK because it eliminates ambiguity and protects them from the PSL. With that elimination of ambiguity and corresponding MUSRT, evaluators have a reason to change. Without that, evaluators have every reason to ignore this new, unproven, and imperfect algorithm; DF On Mon, Feb 27, 2023 at 12:27 AM Barry Leiba wrote: > I think the failure of this thinking is the idea that there's any > intent going on at cuny.edu, and we need to remind ourselves that it's > a *hierarchy*, and that that word means something specific. In a > hierarchy you expect to inherit things *through* the hierarchy, > without skipping levels. No one expects to inherit from a grandparent > and *not* from the parent: that's not how hierarchies work. > > The fact that using the PSL resulted in that is unintentional and is > extremely unlikely to be what anyone wanted. It's far more likely > that it's just what happened, without intent, and that no one noticed > nor cared. > > I don't think there's anything to fix here, as the tree walk has > already fixed this anomaly. Letting people put the anomaly back in > with a confusing tag that no one will ever deploy doesn't seem to be a > good approach. The real answer for anyone who needs to jump the > hierarchy for some reason is that they simply need to put in an > explicit DMARC record, and they get exactly what they want, *whatever* > that is. > > Now, if we can find any real-world cases where that isn't practical -- > something like a whole load of subdomains of bmcc.cuny.edu that truly > want to skip up and inherit from cuny.edu instead and will be broken, > rather than fixed, by tree walk -- then I really do want to hear about > that, and then I would think we need to revisit this. I do not think > that now. > > Barry > > On Sun, Feb 26, 2023 at 2:40 PM Douglas Foster > wrote: > > > > I don't see that we have the right to tell cuny.edu and others that we > have sacrificed them to the greater good. We know exactly what their > configuration means under RFC 7489, and we need to make it supportable. > > > > We have talked about three ways of guessing the organizational domain: > > - PSL > > - Tree Walk with top-most policy selected > > - Tree Walk with bottom-most policy selected > > I am belatedly on-board that the last option is the least bad, but they > are all bad because they involve guessing. > > > > PSL is particularly hard on domain owners that have been victimized by > PSL errors (which can never be fully corrected), so domain owners have a > big stake in making the new algorithm work.I don't see how we can > propose unilaterally changing one end of the protocol without changing the > other end of the protocol as well. A configuration which is optimized for > RFC 7489 cannot be assumed to be optimized for DMARCbis. > > > > Alex and Ale have the right idea, because a DMARCbis-compliant policy > record should eliminate guessing completely. My variant of their concept > is to add this term to the DMARC policy: > > org=n, > > where > > > > n is the number of DNS segments in the organizational domain > > and is therefore a number between 2 and 4 > > and is less than or equal to the number of DMARC segments in the current > policy domain. > > > > When org=n matches the number of segments in the current policy, this is > explicitly asserted to be the organizational domain. > > > > Benefits: > > 1) The policy walk stops at the first policy, gaining all the > performance efficiency of the current walk definition. > > 2) Relaxed alignment is determined with simple compares: The "org=n" > values must be identical on both domains, and the rightmost N segments of > both domain names must be identical. > > 3) Domain owner is in full control of the computed organizational > domain. No more guessing. > > > > Protecting against malicious impersonation of a parent domain: > > 1) The policies selected for the From domain and the authenticating > domain must both contain the same org=n term. > > 2) The organizational domain policy must be queried, must exist, and > must contain the same org=n term. This helps to prevent impersonation of > private registry
[dmarc-ietf] Question on RFC7489: trailing whitespaces
Dear colleagues, I am curious to know what the stance is on trailing whitespace within DMARC records. Strictly following the RFC 7489 and the formal specification in section 6.4, if there is no trailing dmarc-sep with the associated semicolon, trailing whitespace is not allowed. For example a record like: "v=DMARC1; p=reject; pct=100 " would be invalid, whereas "v=DMARC1; p=reject; pct=100 ; " would be valid. Though some tools for verifying DMARC records, such as DMARC Analyzer and Proofpoint, consider this an error (while otherwise parsing the record just fine), most others appear to strip out or ignore the trailing whitespace. Is there something I am missing that renders the whitespace valid? If not, should this be considered an error as it goes against the standard, or is it just generally considered acceptable to ignore this? Kind regards, -- Tõnu Tammer CERT-EE juht / Executive Director of CERT-EE Riigi Infosüsteemi Amet / Estonian Information System Authority Email: t...@cert.ee Mobile: +372 53 284 054 Web: https://www.cert.ee PGP:0x77A8997 / 9477 6B86 6A1E 849B C456 46D6 9CA8 9E41 77A8 997B ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
On Mon, Feb 27, 2023 at 12:27 AM Barry Leiba wrote: > I think the failure of this thinking is the idea that there's any > intent going on at cuny.edu, and we need to remind ourselves that it's > a *hierarchy*, and that that word means something specific. In a > hierarchy you expect to inherit things *through* the hierarchy, > without skipping levels. No one expects to inherit from a grandparent > and *not* from the parent: that's not how hierarchies work. > > The fact that using the PSL resulted in that is unintentional and is > extremely unlikely to be what anyone wanted. It's far more likely > that it's just what happened, without intent, and that no one noticed > nor cared. > > I don't think there's anything to fix here, as the tree walk has > already fixed this anomaly. Letting people put the anomaly back in > with a confusing tag that no one will ever deploy doesn't seem to be a > good approach. The real answer for anyone who needs to jump the > hierarchy for some reason is that they simply need to put in an > explicit DMARC record, and they get exactly what they want, *whatever* > that is. > > Now, if we can find any real-world cases where that isn't practical -- > something like a whole load of subdomains of bmcc.cuny.edu that truly > want to skip up and inherit from cuny.edu instead and will be broken, > rather than fixed, by tree walk -- then I really do want to hear about > that, and then I would think we need to revisit this. I do not think > that now. > > Barry > Thank you. +1 Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
