Matt Simerson writes: > That just seems to reinforce the point that the message alterations > are far more popular with list *operators* than they are with list > *users.*
*shrug* List operators are my constituency. If you, as a list (site) operator, choose to do things differently, more power to you. But my mission is providing the options that "enough" of my constituents desire, and I will advocate protocols that enable those options. > I can't help but think that all this energy would be better spent > focusing on solutions that provides a consistent method for email > lists to present their decoration and admin URIs without breaking > DKIM. Me too. But Dave Crocker et al have squashed (by the weight of their arguments) discussion of that on this list because *presentation is UI*, and we don't do UI because we don't/can't do it well, and if we leave it up to the MUAs they won't do it either, because users aren't capable of using the information effectively even if it's presented to them. I'm not giving up (I'm not so pessimistic about the utility to at least a significant subset of users), but for the purpose of this list my options are restricted to third party authorization protocols and "subversion" (as Hector and Doug would say) when those aren't available and Author Domain publishes "p=reject". The rest is tl;dr for mainstream DMARC advocates. :-) > Something that: Nothing new here, people, move along! Specifically. > a) Identifies messages as list traffic (aka: List-ID) List-ID, indeed. List-Post might also be used. > b) Incorporates list info into headers (see below) We already have something pretty much equivalent, but much more general: the DKIM z= tag. Murray's concerns about "secondary validation" are inapplicable, as this would be advisory to the MUA's presentation algorithms, not part of a security mechanism for authorizing the message. > c) Requests MUA authors to identify list messages in a safe > and useful fashion** Again, this is not general. It is already done as far as "useful" goes (even moderately-skilled users can sort list mail into a separate folder or tag it), not obviously possible if "safe" means "identifying legitimate posts" (RFCs 2369 and 2919 can be easily perverted to use by the Black Hats). As several posters have pointed out, it probably can't be done at all, when you're talking about the kind of greedy and unwary user who falls for "I picked you out of a hat to make you rich" schemes. > I fully realize that c) is a can of worms, but I can't help but > think that MUA authors are equal to the task. If we provided them > with a defined set of Mailing List Actions that were enabled when > the MLM software populated the appropriate headers, we could > eliminate the vast majority of message alterations. Maybe. We could try, but the whole history of the Web shows that upstream wants to control appearance in the browser. I think an analogous desire is present in list operators, though the details are different and the degree of control desired is not so absolute. > > Removal of prohibited content is not so easily addressed, > > In such cases, don't you think it's appropriate for the list to > take ownership of the message, after applying the transformations > necessary to make it conform to site policy? No, I don't. In general, the agent that caused the content to be posted is still the original From:. That's what *she* will think, that's what *readers* will think, and I think it is wrong (and know it is confusing) to present that content as "From:" anybody else. In particular, the most common transformation removes text/html parts from multipart/alternative bodies, and I can see no justification for claiming authorship in that case. If you do, I would recommend presenting your intention accurately by encapsulating the transformed message in a rfc822/message MIME part, prefixed by a part containing text explaining the transformations applied to the message. You would not then "take ownership" of From: in the encapsulated message, would you? _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
