On Sunday, June 8, 2014 5:30 PM, Murray S. Kucherawy <[email protected]> wrote:
> I'm not so sure about the SHOULD i would stay with SHOULD/MUST combo. i would, actually, even suggest it to be MUST/MUST combo, but i leave that to general consensus, as there may be reasons not to go so strong, which i'm not currently aware of. however, 1st paragraph should b stronger than RECOMMENDED, imo, cause i believe such information is quite helpful and very informative in number of ways to end users in case of issues, and especially to various levels of support and administration. also, it is a fact most current MTAs include A-R for SPF/DKIM, and ASAICS such practice is rather a common standard now, so i would go with a SHOULD, simply to be in line with what seems to be usual for MTAs today. when it comes to 2nd paragraph's MUST, if there r any operational objections or reasons why would any particular implementation have to lower these requirements in its use case, i'm perfectly fine to switch it to SHOULD SHOULD combo. however, if there aren't any, SHOULD MUST is preferred by me. anyway, i do suggest we review the list of items in 2nd paragraph, as i may have left something important out, or listed something irrelevantly redundant. i'm not sure how to process "pct" tag exactly, in sense of DMARC A-R info, to make it obvious, but minimalistic, but that's something we may want to include also. ofc, my txt needs RFC tags where appropriate, but i'm sure Murray will include them as a matter of good document writeup, which does seem to be one of his talents, as i didn't have any issues reading any spec he authored before. > It is mentioned in Section 6 yes, it was my original idea to add advice to MTAa to s6, with some adequate transformation of the original txt, but i leave that to u, as the document author, to handle, since u would do it better than me, or we can cooperate on wording, if u prefer. imo, the same section, in addition to advice to MTAs, would do good to include some wording of advice to MUAs from Franck's suggestion. i do think, however, that any design proposals should be as minimalistic as possible, since that's a whole other area of expertise, problems and requirements we cannot possibly hope to evaluate adequately, and, ofc, we need to leave creative freedom in hands of designers. so, i do support to RECOMMEND MUAs to make prominence of a validated FROM domain in their implementations, or, at least to mention it as MAY. if DMARC succeeds in its premise to validate authorised email, domain validation information could become quite useful to design choices in MUAs, making some distinction between DMARC-validated and regular email. -- Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
