To the rest of the WG: Is there consensus to make this change or the others being proposed?
I feel like we're making a lot more edits here than the WG intended to make. It's fine if the WG wants to turn this into a larger editorial pass, but I thought the updates here were tightly scoped before, namely just enough to allow ARC to do what it needs. I'm inclined to resist, absent consensus, any changes that are other than (a) something ARC needs, or (b) something clearly incorrect. On Wed, Aug 1, 2018 at 5:16 AM, Alessandro Vesely <[email protected]> wrote: > >> In that case, if the producer intent is not to harm or mislead, the > trust > >> in this field's content would be proportional to the estimated > quality of > >> the producer's software. Consumer's wisdom is key. > > > > How is a receiver to know anything about the estimated quality of the > > producer's software? > > Being proportional works both ways. You can estimate the quality from the > accuracy of the content, then you can trust the field content (of a > different > method or message) based on what you learned about that operator. > How is a receiver supposed to go about estimating the quality of something? This is starting to feel a lot like either scope creep or philosophical ruminating (or both). Do we really want to get into things like that in this document? >>>> *special-smtp-verb* > >>>> This rule is redundant and, if we're after readability, can be > >>>> striked. In fact, both terms it produces fall under the "Keyword" > >>>> rule. In addition, IANA reports smtp.rcptto as defined by rfc7293, so > >>>> it can be omitted here.>>> > >>> It's not redundant. MAILFROM and RCPTTO are not SMTP verbs. > >> > >> Right, but their formation is well described in the relevant > paragraphs, > >> which I quote:>> > >> The list of commands eligible for use with the "smtp" ptype can be > >> found in Section 4.1 of [SMTP]. > >> > >> [...omitted paragraph here...] > >> > >> Where an SMTP command name is being reported as a "property", the > >> agent generating the header field represents that command by > >> converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" > >> becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). > >> > >> Please note that a dumb reader might fail to derive that the latter > >> paragraph is constrained by the former. (Perhaps reordering and/or > >> merging might help.)> > > > > I'm not clear on how ordering helps here. You need the two together > > regardless of order. > > I meant something like so: > > The list of commands eligible for use with the "smtp" ptype can be > found in Section 4.1 of [SMTP]. To report an SMTP command name as a > "property", the agent generating the header field represents that > command by converting it to lowercase and dropping any spaces (e.g., > "MAIL FROM" becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). > > > I'm also not clear on what problem you're trying to solve. > > No problem. That reorder and merge is just a marginal hint to improve > readability. > I'd like to know what the WG thinks here as well. > Keep in mind that this is now something like the fourth version of this > > document, and this has not been identified as a deficiency in any prior > > version. Is this actually broken? > > No, it is not broken, AFAICS. Rather, it's better than previous versions, > where the "policy" ptype was overloaded beyond clarity, from covering > unregistered properties, to overriding methods' results, to catchall for > any > property not extracted directly from the message session. > It has always been deliberately ambiguous, since we obviously can't specify all policy-based decision trees. But the intent has always been to identify situations where a method failed for a reason other than that method's defined algorithms reporting a failure result. >> This message is an example. Unless removed, it bears a header field > like: > >> > >> Authentication-Results: tana.it; auth=pass (details omitted) > >> > >> It means I was SMTP-authenticated when I posted the message (otherwise > it > >> wouldn't have been DKIM-signed.) However, for obvious reasons, I don't > >> want to disclose the userid I authenticated with. > > > > I think that's operationally a poor choice. > > Agreed. However, my signing agent knows nothing about any AUTH= parameter > to > the MAIL FROM command. It just knows the (non-public) smtp.auth. What A-R > field should it write? > I would suggest not adding one at all. What is a downstream agent to do with a plain "auth=pass"? > The whole point of the data that come after the pass/fail is to tell > > downstream agents what identifier(s) might be of interest to record or > > highlight to users. If you managed to authenticate as the identity in > the > > From: field, that's a lot more interesting than if you authenticated as > > something unrelated; the fact that the filter adding this left out that > key > > piece of information almost makes it useless. > > I beg to differ here. If the authentication token is syntactically equal > to > the [local-part of the] mailbox address, this can be considered as > substantial > data leakage, given that the mailbox address is public. > How would a verifier determine syntactical equivalence? IMHO, in a multi-host implementation where downstream agents need to acquire > smtp.auth, there should be a final agent to redact it before it crosses the > trust boundary. For example: > > Authentication-Results: example.net; auth=pass > [email protected] > > Or, according to rfc6590 algorithm: > > Authentication-Results: example.net; auth=pass > [email protected] > > Or just remove the header field entirely. Which is better? Also compare > with > varying values of From:: > > From: [email protected] > To: [email protected] > Authentication-Results: example.net; auth=pass > [email protected] This is almost certainly scope creep. What do others think? Both dkim=fail and dkim=policy are valid ways to override the method's > algorithmic result. To exemplify the preferred way is fine for me. > Ah, the example is wrong. Will fix it. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
