On May 28, 2014, at 4:05 PM, Brandon Long <[email protected]> wrote: > > > > On Wed, May 28, 2014 at 3:46 PM, Barry Leiba <[email protected]> wrote: > > We could attempt to define a dkim canonicalization that would pass through a > > mailing list. > > This was beaten pretty severely during the DKIM work, and we couldn't > come up with anything that was workable. > > > It should include the subject, but have rules for stripping "standard" > > subject prefixes. It should obviously include other headers, but not List-* > > headers (since the RFC for those says the mailing list should strip the > > existing ones). > > > > The body is challenging. We could have it specify a length... that does > > allow for some weirdness with html positioning. We could require no-html > > part. > > > > We could optionally require footers to be added as separate parts, and have > > the canonicalization be for "first text part". > > Anything that requires mailing list software to change won't work. If > mailing list software is changed, the right answer is for the mailing > list to re-sign the message. That doesn't help the DMARC situation > now, but DMARC could be given other options once that happens. > > If the mailing list signs and verifies, that's OAR... and then the challenge > becomes knowing when to trust the OAR.
Exactly. TPA-Label provides this answer. > Also, it seems to me that mailing lists without changes and DMARC are > basically incompatible, so I'm unclear of any solution that will allow them > to work unchanged. Again, TPA-Label provides this answer. By the way, the TPA-Label draft has been updated to include Original-Authentication-Results draft reference which also states this concern as well. > We discussed using l= at (um...) length, and no one liked that > approach. There were too many holes, yes: allowing arbitrary amounts > of data to be added to the message text, having it fail anyway if text > isn't added at the end (such as for multipart messages), and so on. > > Heuristics involved in tweaking the subject are problematic. > > Some of this could perhaps work if we had a canonicalization that was > *specific* to mailing list posts... but then how would the signing > domain know that the message it was signing was going to a mailing > list? > > Theoretically, a client could easily know its a mailing list in most cases, > but yes, where the signing often occurs, its unlikely to know. The easiest > thing to do would be to sign it both ways, and then the receiver might only > trust the mailing list canonicalization if it went through a mailing list... > and of course that can be forged as well. That is what spam-traps and DMARC feedback provides. When a problem is detected and reported to the DMARC domain, the response can be to withdraw authorization and report problems to third-party service providers. Fast and easy. Depending on the urgency, it would be nicer to report problems to the service provider and give then an opportunity to fix issues before causing an unnecessary disruption. The point is to ensure everyone has an incentive to cooperate. There are many cases that are never originally signed by the DMARC domain. Such as an accounting package that sends out invoices on behalf of some company that wants their email address in the From header since this is what their customers will recognize. > I really think this isn't a useful approach, but perhaps someone might > come up with the necessary "aha" to make it work. > > I think it depends on what the goal is. If the goal is "unforgeable messages > through a mailing list to pass DMARC", then yes, this is probably not going > to work. The only solution there is for the mailing lists to actually not > munge messages. > > I might argue that "if the mailing list is going to munge the message, then > it needs to munge From as well"... but there seems to be a fairly high > resistance to that. This would be an understatement which also ignores other valid uses. People might remember someone said something profound without recalling related details. Not being able to search through their message stream would be fairly frustrating. Not all mailing lists offer usable reference header fields for such use (perhaps to ensure user privacy). References: <CABa8R6v6tk7ZdgtTkBQGT6F7A17VP=zccpmcbojfze7sy99...@mail.gmail.com> might not be something that can be used by most MUAs to review what someone said in the past, for example > I suspect that many parties that implement DMARC are "cheating" by allowing > things that look like mailing list or forwarded mail through even if they > fail auth and the domain is p=REJECT. Providing a higher bar for when to > "cheat" may be useful, then. > > Now, my anti-spam colleagues will say that any hole will eventually be > exploited... but given that I don't see how we can make this work with no > holes, and if we can't change mailing lists... and any sort of whitelisting > is adding a hole... I feel like I'm in a circular argument. The hurdle that seems to be in everyone's mind is how to go about facilitating feedback that is not a lot of work. Some have used specialize DNS servers to cut corners. http://www.corpit.ru/mjt/rbldnsd.html is an example related to dealing with email abuse. There are off-the-shelf DNS servers able to return 30K resource records without an issue. Add a few scripts and voila. A specialized server however may assist in the administration of providing DMARC related authorizations for third-party domains. This could be mailing-lists, office and facility services using a separate Sender header, "acquaintance" initiated message services, etc. It seems the same specialized server could be tasked with processing DMARC feedback looking for confirmation in outbound logs. The server itself might even look for which log domains match hashed labels. This could provide a heads-up something is outside the federation. Once the initial corpus has been accommodated, keeping the system maintained should become progressively easier. Or of course we could say it is too hard which places this problem back into making guesses. When that happens, vast amounts of abuse will suddenly appear. Malefactors quickly learn where the gray areas exist. The goal is to ensure there is as little guesswork as possible while keeping the DMARC domain in control. It seems unlikely there will be many outside service providers willing to make decisions about which DMARC related messages are legitimate or not. Only the DMARC domain can realistically be expected to make those decisions. This then means the real task is to then communicate these decisions to all of the DMARC domain's potential receivers. Regards, Douglas Otis
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
