On Nov 14, 2014, at 8:55 PM, Stephen J. Turnbull <step...@xemacs.org> wrote:
> Silberman, Sam writes: > >> They have no $$, so they use a free mail service ( >> p...@dmarc-protected-mailservice.com) > > which is a specifically deprecated use-case in the DMARC document (and > at least some such services are well-aware that what they are doing is > a Bad Idea[tm]). Should we spend effort specifically on remediating > foot-shooting behavior by mailbox-provider services? Dear Sam and Stephen, A draft may attempt to dissuade assertion of disruptive policies (i.e. p=quarantine, or p=reject) against typical email use. However, this effort could be seen as explaining to a 900lb gorilla where they should sleep. Justifications heard from those at DMaRC meeting were: -|- Disruptive policies protect their "brand" by disallowing other sources use of their domain in From header fields. -|- Disruptive policies protect their customers from being "spoofed" by other domains. -|- Authorization schemes can never work because malefactors quickly jump from domain to domain. -|- Forwarded email going to a different domain, even if approved on a domain/user basis, is too difficult to manage. In other words, say goodbye to email's agility as a result of restrictive policies placed on general use email accounts by AOL, Yahoo, and others as they employ policies originally intended to protect transactional email. Those promoting DMaRC claim this scheme now protects 60% of all inboxes from being phished. As a result, we can expect those being disrupted will arrange the From header field information into the Reply-To header field and ignore http://tools.ietf.org/html/rfc5322#section-3.6.2 which states: "In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message." DMaRC simply does not offer a practical scheme that permits "alignment" of the From with either DKIM or SPF for third-party services. >> Telling user like this one to change mail providers solves nothing >> in the long term. > > Of course it does make a difference, though. If enough users switch, > that email/portal service will awaken to the need for solutions like > DKIM-Delegate, DKIM-Conditional, and TPA-Labels, or alternative > solutions to their specific spam problems. Otherwise I imagine they > will be most comfortable continuing to throw their problems over the > fence into our backyards, as they have been doing. Changing that > benefit-cost proposition is essential to getting implementation of > solutions effected. Internet access often includes email accounts facilitating Internet services. Most users are reliant on their Internet providers to restore services when problems are experienced. As such, most are reluctant to modify services offered, even when there may be a means to substitute email-addresses from different providers. Typically no examples are given leaving most unaware of possible options. This should be expected since such options would interfere with the marketing of ads. In addition, not every email service relies on SPF or DKIM. Both of these protocols offer weak protection which has led to a rapid uptake of DANE/SMTP. In addition, without TPA-Labels, DMaRC is unable to align with most third-party services. Mailing-lists that tag subject lines and flatten messages actually provide safer services by making messages less suitable for exploitation. It is a sad outcome, since DMaRC offers feedback allowing various domains a means to monitor and identify compromised accounts. Use of the TPA-label scheme would allow an immediate method to omit abusive domains and alert users to a problem while selectively permitting improved authentication schemes. Domains offering bundled email combined with free accounts remain abuse prone. Any risk associated with authorizing a third-party domain is offset by improved feedback able to achieve an immediate remedy, when compared against abuse emitted directly from the DMaRC domain that can be replayed to an unlimited number of recipients for days at a time. > So far these services have contributed nothing helpful to the > discussion of design of protocol improvements that I've seen; they > clearly don't see a profitable (for them) way forward from the status > quo. And the most active contributor from the DMARC-using operator > group is an advocate of positions that I would summarize as "typical > MLMs and 3rd-party services are broken and need to fix themselves to > adapt to a DMARC 'p=reject' world". Sadly, I agree. We even offered to help manage the use of the TPA-label scheme. There was a concern regarding the Forwarding of email from one domain to another which might require special handling. It seems this need to be explored further. >> Ultimately, solving DMARC indirect flows for this user will get us >> very close to solving indirect flows over the rest of the world. > > But *we* can't *solve* indirect flows. All *we* can do is provide a > protocol that mitigates the problem in theory. > > To have an effect, that protocol must be adopted by the same folks who > created the problem and are busily telling 3rd parties to fix their > service models, and thanking the 3rd parties for behavior clearly not > conformant to the most basic of RFCs. I don't see why we can expect > them to stop doing these things -- DMARC p=reject been quite effective > in stopping some very dangerous spam/phishing, and blame the victim > has convinced many of their users that the problem is in the 3rd-party > service models, and those users turn around and complain to lists and > other indirect mail services. > > Viz. the recent post to this list, requesting that list tags in > Subject and footers containing detailed contact information no longer > be added to list posts. That the poster would take that position > doesn't surprise me: he's advocated that same measure on Mailman lists > as well. But that other members of this WG would give even qualified > support shows a clear lack of confidence that a solution attractive to > the 'p=reject' freemail providers will be found *and* implemented. Agreed. Over time, domains too big to block causing work for others may soon find that status fading. Only then, does it seem likely progress can be made. I'll repeat an offer to help manage handling this very serious problem. It seems that offering even weaker forms of DKIM is not something that would be safe. An alternative solution might involve using the Outlook scheme of "on behalf of" or displaying the Sender header field (an available option with many MUAs). A DMARC flag could then safely permit inclusion of Sender to satisfy alignments when being used for general purpose user email accounts. This would give most third-parties a simpler solution. TPA-Label could also allow selective deployment of the Sender option as well. Regards, Douglas Otis
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
