For mailing lists, we have pushed the limits of authorization. But there is another class of problems where sender authorization is not feasible: mail which is auto-forwarded after a spam-filter has made content-altering changes.
In some respects, the problem is similar to a mailing list. This mailing list adds a prefix to the subject, adds a footer to the body, and converts content to text. The first two changes are potentially reversible, while the last one is not. Commonly used spam filters may add a prefix to the subject, a header or footer to the body, and rewrite embedded URLs to provide time-of-click protection. Again, the first two changes are potentially reversible, while the last is more difficult. Because an auto-forward has the potential for senders from any source, third-party authorization of the forwarding domain is not possible. Instead the mechanism requires either that the recipient domain provides a DMARC exception for the forwarding stream, or the forwarding domain must remove the spam-filter's changes so that signature integrity is restored. In general, the changes provided by a spam filter are intended for the subscribed client, so it is an interesting licensing question whether those protections should extend to external non-subscriber addresses that are served via auto-forwarding. But for our purposes, removing those edits would solve the DMARC problem by restoring signature integrity. So I think we need to re-examine rollback options I think it is useful to categorize the types of edits that may occur: - A simple insertion of new text. A change log which documents the start point and length of insertion would be sufficient to identify the added text separately from the prior text. If the document is signed after the changes are applied, an MUA could potentially separate the contents of each author, with author identification. This may actually enhance efforts to use spam-filter additions as a trust indicator. An MTA could evaluate the original content against the original signature, or could remove the added content to restore the original message. - A replacement or removal of text, where the original content can be represented in a message header. In this case, the change log would include the starting point of the change, the length of the new text, and the entirety of the original text. An MTA could reverse the changes or evaluate the original signature after applying a virtual reversal of the changes. An MUA would probably not be able to identify the changed regions to the user, especially if the changes were in the non-visible portion of an HTML component. - A replacement or removal of text, where the original content is too complex to be stored in the message header. In this case, the original content can only be recovered if the original content is retained external to the message in a proprietary data store. Since many organizations use the same vendor for both inbound and outbound gateways, external data stores are plausible. In the absence of such techniques, the forwarding system (or the outbound gateway) needs to be aware that a message has been forwarded after content-altering changes. When this is the case, the message either requires a known exception at the receiving system or a From address rewrite so the message will pass DMARC. At minimum, our DMARC specification should make this clear. Doug Foster
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
