If MLM changes are not reversible, we still have the problem of convincing the recipient gateway to trust the modified message.
At first glance, this is an internal issue between the user who created the subscription and his email security administrator, and that communication is not obviously an IETF problem. But in a large consumer-focused environment like Gmail, or even within a Fortune 500 enterprise, some level of automation may be necessary. Additionally, the email filter MTA and the mail store are often separate products from separate companies, so we have an multi-vendor interoperability issue. Collectively this seems to make an IETF specification appropriate. At present, email gateways have very limited ability to distinguish between solicited and unsolicited mail. Some implementations check for a match on the user’s contact list. Other products check for outbound messages to the sender. Giving the email gateway better information about subscribed mail flows should improve filtering accuracy. This is the scenario in my head, a variant of something posted previously: · User A subscribes to mailing list M. · Mailing list M sends a message to User A with a request to ensure that the inbound gateway will accepts its message. The message contains attachments needed to define and justify the request. I envision an XML attachment for use with automation, and a text file for non-automated environments. An XLST file could be used to convert the XML to TXT, to validate that the XML attachment and the text attachment are really stating the same thing. · The configuration files provide this type of information: o The header fields which will uniquely identify message from this subscription, and the tests which can be performed to validate those headers. o The administrative contacts for the list. o Whether the list makes DKIM-invalidating changes, and why. o For Murray’s approach: Whether the changes will be fully or partially reversible and whether it supports the tf extension. o For John’s approach: Whether or not the list implements ARC. · The email administration then reviews the request and replies to user and MLM in one of three ways: o Fully Approved - any required gateway trust changes have been implemented. For automated systems, the XML file is used to apply these changes. o Strongly rejected - subscription is contrary to policy and should be cancelled; user should assume that any incoming messages will be blocked. o Neutral – Subscription is not rejected but no trust changes will be made. Any particular message may or may not be blocked. Would this be more likely to succeed than the alternatives? DF
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
