It appears that Scott Kitterman  <[email protected]> said:
>> I don't remember, perhaps someone else can remind us.  In the situation
>> Mike's been warning about, the topmost record fails dangerously.
>
>As I understand it, yes, but I don't 100% agree that it's a protocol problem.  
>Typically if a company you have hired to do a job does so poorly, then you 
>hire someone else.  I don't think it's possible to write protocol to avoid 
>problems like this entirely.

In general I agree, but in the world of standards we have a very long tail of
software that is updated very slowly.  So I think our goal has to be that the
results we get from the tree walk should be close to and no worse than what
came before.  That has to apply to poorly configured systems, too, much though
we'd prefer otherwise.  (I would really like to require that every domain that
receives mail has an MX, now that we've had a 40 year transition period, but
it's not happening.)

>Walking up the tree one would look for DMARC records in:
>_dmarc.sales.cust.us.com
>_dmarc.cust.us.com 
>
>and then potentially:
>
>_dmarc.us.com
>_dmarc.com
>
>If us.com had published a DMARC record with psd=y, then we would know for sure 
>that cust.us.com is the org domain.  I think when walking up you want the 
>first 
>record for policy domain and the last non-PSD record for org domain.  

Now I'm confused.  The policy and org domain used to be the same, but now they
seem to be different.  That's not necessarily wrong, but if we're going to
separate them, then we need to be crystal clear what the function of each is.

>In your example both the first DMARC record and the org domain are the same, 
>but imagine that later cust.us.com decided that for their sales subdomain they 
>needed a different handling policy, so a new DMARC record appears at 
>_dmarc.sales.cust.us.com.  If we take the first DMARC record as the org 
>domain, 
>then it changes from cust.us.com to sales.cust.us.com.  If they had been using 
>dkim.cust.us.com it would suddenly fail to align.  I think this would be a 
>very surprising property of the system and not really what we are after.

Conversely, as it stands now, us.com does not have a PSD flag so if we take
your approach, foo.us.com and bar.us.com are aligned and there is nothing
either can do about it other than ask Centralnic to change their DMARC record.

Either way some people will be surprised.  We need to consider both how many
will be surprised, and the consequences of the surprise.  Which is worse, having
some currently aligned mail fail, or allowing a new class of phishes?  Neither
is great but the latter seems worse.

>I do think that an exact match should always be used.  For example, let's 
>imagine the operators of us.com decide to use it in email for their own email 
>and publish a DMARC record, but they use psd=y so as to not disturb the 
>alignment of their customer's mail.

Yes, that seems right, although there is a surprisingly long set of 2LDs
that are PSDs and also have regular DMARC records now.

R's,
John

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to