MAILING LISTS. The mailing list problem can be stated as follows: Domain B wants to operate a mailing list.The list owner will accept messages from domain A, alter them, then re-transmit the altered message to member C.List owner B wants the mail filter for member C to guarantee that his list messages are granted the same trust level as a message sent directly from A to C without alteration. This problem is unsolvable because it is unreasonable. The options for creating trust in indirect mail have been discussed in another RFC. Applied to this issue, the options are:
1) Make List B the originator by changing the RFC 5321 sender address as well as the RFC 5322 Message From. Ideally add a DKIM signature for B, in case the message is forwarded downstream. This is the IETF list behavior and the only one that is feasible in practice. .. 2) Require all submitting domains to make List B a trusted sender for their domain by including B in their SPF record 3) Configure the list to make no changes, then require all senders to include DKIM signatures for their own domain. 4) Require all recipient systems to make special policy accommodations to grant trust to messages from List B, simply because it comes from List B. This is feasible, but specific to each participants incoming email filter. DKIM and IDENTIFIERS A large portion of legitimate mail is generated by third parties acting as agents. The problem being addressed by SPF / DKIM / DMARC is: "How can a sender provide information so that a recipient can distinguish between an authorized agent and an unauthorized identity thief?" A subset of this issue is "How do we expect recipient systems to behave?" This is a rather important detail which this group has explicitly chosen to not pursue. But I can provide these observations based on experience with mail filtering: To avoid false positives on desired messages, messages from some senders must be given some filtering exceptions. For those exceptions to be applied safely, the sender must be verified to a degree acceptable to the recipient. Depending on the situation, there are multiple ways that a sender can be identified. These include, but are not limited to, SPF, DKIM, and DMARC.. In the general case, SPF, DKIM, and DMARC simplify this problem for the recipient. Although SPF, DKIM, and DMARC are often assumed to be tools for discarding fraudulent messages, this is extraordinarily difficult to implement in practice. Too many senders have errors in their SPF / DKIM / DMARC configurations, and too many legitimate senders do things that violate a domain owner's SPF / DKIM / DMARC policies. Policy failure has not proven to be a reliable indicator of unwanted content. Without DMARC, SPF and DKIM configuration errors persist because the sender obtains no feedback about those errors. DMARC fixes the feedback problem. I still do not understand how DMARC does anything other than enhance prior work on SPF and DKIM, or how there is any conflict with prior standards. Doug Foster
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
