ni
On Wed, Dec 31, 2014, 8:36 PM Murray S. Kucherawy <[email protected]> wrote: > On Mon, Dec 29, 2014 at 2:29 PM, Rolf E. Sonneveld < > [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
