DMARC either introduced or popularized the concept of filtering on the Message From. Low-end gateways that lack DMARC support will typically do nothing with the Message From -- the header value does not appear in the message logs and it cannot be used for filtering because it is not examined.
Now that the concept has been established, spam defenses based on From filtering are a class, of which DMARC is only an instance. Recipient systems might choose to: Enforce DMARC on a domain even if the domain has a DMARC policy with p=none or pct=0.Enforce DMARC-equivalent requirements on a domain that has no DMARC policy at all.Block based on the TLD of the From addressBlock based on Domain reputation lookups using the From address. This creates a difficult problem for the MLM which wants to use author as the From address. The recipient gateway does not know the universe of all mailing list subscribers, and the list changes over time as members subscribe and unsubscribe. The MLM does not know the universe of all domains blocked by the recipient gateway, and the list of blocked domains will change over time as policies are modified. These limitations of knowledge will limit our options for solutions. I see four possible recipient configurations with specific implications for what the MLM can do. 1. Recipient system does not block based on From address MLM options are unrestricted 2. Recipient system whitelists mailing list messages based on source server identity MLM server must be reliably identifiable, typically using forward-confirmed DNS name. From address is unrestricted. 3. Recipient system whitelists mailing list messages based on list identity MLM list id must be reliably identifiable, probably using a SPF lookup on the List-ID or a DKIM signature with identifier specified to the list rather than the domain. From address is unrestricted. 4. Recipient system blocks on From address but is unwilling to whitelist (or not yet configured to do so) MLM needs to use its own Domain for the From address and for a verifiable DKIM signature. Alternatively, IETF would need to provide a way to trick the recipient into accepting the message in violation of its configured policy, which it should not do. More complicated solutions, like dual signatures, are alternatives for the middle of the above list, but are not needed for the first configuration and are excluded from the last configuration because of the "not configured" assumption. Filtering on From Address is itself an instance of a larger class: defenses based on verified identifiers. An identifier is useful to the spammer if the identifier might case the incoming gateway to allow a message that would otherwise be blocked.An identifier is useful to the spammer if it will be displayed to the user by the MUA, because then it can be used to perfect the spammer's social engineering attacks. Because of these risks, SPF validation restricts unauthorized use of the RFC 5321 Mail From, and DMARC validation limits the use of the RFC 5322 Message From. Going forward, we need to look for ways to validate any identifier that is used for either message filtering or message display. If we do not, we should expect that some non-IETF source will do so instead. For the current issue, changing the roles of the Sender and From fields will not be a long term solution unless the change includes validation of both fields. The change by itself will attract spammers to whatever field remains unvalidated. DF
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
