On Thu 04/Jun/2020 12:31:51 +0200 Douglas E. Foster wrote: > 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.
Starting a message by posing an ill-defined problem does not help clarity. > 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. This is the *de-facto* standard. As the OP noted, the agent responsible for the transmission should be set in the Sender: field. Instead, mailing lists are forced to rewrite the From: field because of DMARC. IOW, DMARC hijacked From: thereby violating RFC 5322. I agree this point should be fixed, making a real standard of it. I think that would take more than one RFC. > 2) Require all submitting domains to make List B a trusted sender for their > domain by including B in their SPF record This never was an option. Mailing lists used to practice some form of VERP long before SPF. > 3) Configure the list to make no changes, then require all senders to include > DKIM signatures for their own domain. Many lists do so, for example opendkim-users, that some of us are subscribed to. Note that this set-up does not prevent posters from writing "[opendkim-users]" in the Subject: of new messages. Nobody does so, since posts are accepted even without a subject tag, yet it could be easily enforced. > 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. This is a hindrance to DMARC adoption. The need to catch and mark all the mailing list domains that don't rewrite From: can prevent an MTA from blindly conforming to all DMARC policies. Alternatively, an MTA can mark highly abused domains and conform to DMARC policies in those cases only. For completeness, I'd also mention conditional signatures, as a fifth point. They were specified, implemented and then abandoned in lieu of ARC. > [...] > > 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. The OP quoted the passage of RFC 5322 where the roles of From: and Sender: are specified. Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
