On April 26, 2022 4:50:08 PM UTC, Alessandro Vesely <[email protected]> wrote:
>On Tue 26/Apr/2022 14:53:27 +0200 Scott Kitterman wrote:
>> On April 26, 2022 8:06:50 AM UTC, Alessandro Vesely <[email protected]> wrote:
>>> On Mon 25/Apr/2022 05:56:46 +0200 Scott Kitterman wrote:
>>>>
>>>> How about something like this:
>>>>
>>>> 9.7 Determination of the Organizational Domain For Relaxed Alignment
>>>>
>>>> DMARC evaluation for relaxed alignment is highly sensitive to errors in the
>>>> determination of the organizational domain if the RFC5322.From domain does
>>>> not
>>>> have a published policy. If an incorrectly selected organizational domain
>>>> is
>>>> a parent of the correct organizational domain, then relaxed alignment could
>>>> potentially allow a malicious sender to obtain DMARC PASS. This potential
>>>> exists for both the legacy [RFC 7489] and current [Section 4.8] methods for
>>>> determining the organizational domain.
>>>
>>>
>>> I object that this text undermines the robustness of the protocol and may
>>> sound like a campaign for strict alignment. Relaxed alignment is safer
>>> from a flexibility POV, as it accounts for occasional
>>> @hostname.example.com. It has played a relevant role in DMARC success, and
>>> it's not by chance the default.
>>>
>>> Here's an alternative text:
>>>
>>> DMARC evaluation for relaxed alignment is sensitive to errors in the
>>> determination of the organizational domain due to erroneous DNS settings
>>> by
>>> either the organizational domain or its PSD parent. If the PSD parent is
>>> incorrectly selected as organizational domain, then relaxed alignment can
>>> potentially allow a malicious sender to obtain DMARC PASS while
>>> impersonating the relevant organization. This potential exists for both
>>> the legacy [RFC 7489] and current [Section 4.8] methods for determining
>>> the
>>> organizational domain.
>>>
>>>
>>>> This issue is completely avoided by use of strict alignment and publishing
>>>> DMARC records for all domains/sub-domains used as RFC5322.From domain in an
>>>> organization's email.
>>>
>>>
>>> or by publishing psd=n.
>>>
>>>
>>>> For cases where strict alignment is not appropriate, this issue can be
>>>> mitigated by periodically checking the DMARC records, if any, of PSDs above
>>>> the organization's domains in the DNS tree and (for legacy [RFC 7489]
>>>> checking
>>>> that appropriate PSL entries remain present). If a PSD domain publishes a
>>>> DMARC record without the appropriate psd=y tag, organizational domain
>>>> owners
>>>> can add psd=n to their organizational domain's DMARC record so that the PSD
>>>> record will not be incorrectly evaluated to be the organizational domain.
>>>
>>>
>>> The latter alternative is obviously easier than monitoring the DNS settings
>>> of the PSD parent, and has to be carried out anyway in case.
>>
>> What specifically do you object to?
>
>
>A quick skim through your text seems to be summarizable as "DMARC has a defect
>but you can overcome it by using strict alignment". I know that's not what
>you meant, but it sounds quite like that.
>
>
>> Do you think it's inaccurate that this concern is limited to relaxed
>> alignment?
>
>
>No, I think it's wrong to blame relaxed alignment.
>
>
>> The specific suggestion you added (or by publishing psd=n) is already in the
>> text later on, so I'm not understanding what you think the problem is or
>> what you want to do about it?
>
>
>The alternative text above differs slightly from the first paragraph of the
>text you proposed, in an attempt at watering down that meaning.
Okay. Explain how the issue occurs when alignment is strict?
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
