> -----Original Message----- > From: dmarc [mailto:[email protected]] On Behalf Of Anne Bennett > Sent: Monday, March 23, 2015 4:08 PM > To: [email protected] > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > > > Dave Crocker writes: > > > As always, I'm seeking to have thinking and discussion focus on > > software behavior, not user behavior. > > > > Any discussion of end user perception or behavior is distracting to > > meaningful analysis or development of technologies like DMARC. > > I can't entirely agree, though I'm not without sympathy to your point of view. > DMARC is obviously intended to be applied by the software, and it's > tempting to think that the message is either accepted or rejected, end of > story, so this shouldn't affect the user interface or user behaviour. In > practice I don't think it's that simple. > > > Of course, because of the way DMARC is applied (in the DNS) and messages > are signed (by the ISP), the sending user is not of concern here. The > expressed concerns center on the perceptions and behaviour of the > receiving user.
Messages can be (DKIM) signed by any entity that handles the messages in question, not just by an ISP. Aligned (DKIM) signing can only be done with the permission of the domain owner/administrator. Messages may be unsigned and validated on the basis of SPF. > > If p=none (or if DMARC is not used), then the receiving user gets the > message (modulo other de-spamming techniques), but nothing can be > implied about its authenticity, so nothing changes with respect to the non- > DMARC behaviour (of the software or the user!). > Certainly something can be implied about its authenticity. All p=none says is don't apply policy to the validation. > And if the message is rejected due to p=reject, then the user never gets the > message at all, so we needn't be concerned with the receiving user's > behaviour. > Sure we can - if it's a false positive for an expected message and it never arrives. The receiving user's behavior !=happiness. > But if the message is delivered, either because it passes DMARC, or it fails > but is "quarantined", then the receiver will see the message, and will make > assumptions regarding the authenticity of its origin based, most likely, on > the > "From:" header. It seems not unreasonable to suppose that the writer of a > user interface would want to indicate somehow to the user that the message > was (or was not) vetted as coming from where it says it came from. > The DMARC results seem like an obvious source of information for such an > indication. > DMARC addresses only the specific case of direct domain abuse. If I go out and register the domain concordia.co and I send messages from [email protected] to targeted recipients with SPF/DKIM/DMARC properly configured, do you really want to give a trust indicator to those end users based on messages passing DMARC? Presumably Concordia.co would ultimately end up on a block list but would you really want to give trust indicators in the interim? > One could argue, I suppose, that once again we're talking about the > behaviour of software, but the point of all this, unless I woefully > misunderstand, is to protect the user from fraud due to the faked > provenance of a message. I don't think it will ever be the case that we can > sort 100% of messages as "authentic" or "fake" before they reach the user; > we have to accept that even if we block the "known fakes" based on > DMARC, there will still be authenticated and not-checkable messages that > reach the user - and ideally we'd have a way to indicate which are which. > > > > Anne. > -- > Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal > H3G 1M8 > [email protected] +1 514 848-2424 > x2285 > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
