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

["Murray S. Kucherawy" <[e-mail]>]

On Mon, Dec 29, 2014 at 2:29 PM, Rolf E. Sonneveld <
[e-mail]> 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