Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)

ni


On Wed, Dec 31, 2014, 8:36 PM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> On Mon, Dec 29, 2014 at 2:29 PM, Rolf E. Sonneveld <
> R.E.Sonneveld@sonnection.nl> wrote:
>
>>
>>
>>     3.1.3 Flow diagram
>>>
>>> The box titled 'User Mailbox' could give the impression that there's
>>> only one choice for delivery. However, quarantining can be done without
>>> delivery to a mailbox. I'd suggest to label this box 'rMDA'.
>>>
>> That's already done in -08.
>>
>>
>> OK. Well, it's MDA, but that's OK. One typo in the diagram. When:
>>
>>  "sMTA" is the sending
>>    MTA, and "rMTA" is the receiving MTA.
>>
>>
>> is correct, the box in the diagram should be labelled 'sMTA', not 'oMTA'.
>>
>
> Fixed.
>
>
>>
>>
>>
>>>   The part within parentheses of step 6:
>>>
>>>   6. Recipient transport service conducts SPF and DKIM authentication
>>> checks by passing the necessary data to their respective modules, each of
>>> which require queries to the Author Domain's DNS data (when identifiers are
>>> aligned; see below).
>>>
>>>
>>> might indicate that SPF and DKIM authentication checks need not be
>>> performed when identifiers are not aligned. However, for sake of reporting,
>>> SPF and DKIM authentication checks will in general always be done, or am I
>>> missing something?
>>>
>>
>>  I can envision a DMARC implementation that skips SPF or DKIM checks if
>> the corresponding identifiers are not aligned, because they won't be
>> interesting to DMARC in that case.
>>
>>
>> Whether or not to generate reports in the case of non-alignment is not
>> clear from the text, or am I missing something? Par. 3.1.3:
>>
>>     8.  If a policy is found, it is combined with the Author's domain and
>>        the SPF and DKIM results to produce a DMARC policy result (a
>>        "pass" or "fail"), and can optionally cause one of two kinds of
>>        reports to be generated (not shown).
>>
>>
>> and par. 6.2 goes right into the format of reports, not the conditions
>> under which a report is to be sent.
>>
>
> Added an item at the end of the bullet list in 3.1.3.
>
>
>
>>
>>
>>
>>
>>    5.7 Last sentence:
>>>
>>> Mail Receivers SHOULD also implement reporting instructions of DMARC in
>>> place of any extensions to SPF or DKIM that might enable such reporting.
>>>
>>> Not sure what this means. But it seems to me DMARC cannot claim priority
>>> over other options/extensions in other IETF protocols.
>>>
>> This is another spot where the SHOULD gives the operator the choice to do
>> both if it wishes.  I can't remember off the top of my head what the use
>> case is here, but essentially the absence of a request for DKIM or SPF
>> reporting (as developed by the MARF working group some time ago) should not
>> preclude DMARC reporting, nor should their presence interfere with DMARC
>> reporting.
>>
>>
>> Then, borrowing from your text, may I suggest the following text:
>>
>> "Mail Receivers SHOULD implement reporting instructions of DMARC, even in
>> the absence of a request for DKIM or SPF reporting [MARF]. Furthermore, the
>> presence of such requests SHOULD NOT interfere with DMARC reporting."
>>
>>
> Done, with slight changes.
>
>>
>> And as a general statement: thanks for all the work, Murray!
>>
>
> Anything to get this thing put to bed!
>
> -MSK
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>