On Mon, Dec 29, 2014 at 2:29 PM, Rolf E. Sonneveld < r.e.sonnev...@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
