Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage
On 09/18/2014 10:44 PM, Stephen J. Turnbull wrote: Roland Turner writes: > It is hardly realistic to assume that no Mediators will make this > choice [to munge From], nor that all will. Agreed. > It would seem desirable to have a standardised method of specifying > the poster for those who do. Not at all clear to me. The From field currently is the standardized method of specifying the poster, and I'm not sure it's a good idea to have another. Not quite: it's the standardised method of specifying the author(s) (RFC 5322 3.6.2), however specifying both authors in the From: header in Mediated mail is problematic because (a) DMARC recommends rejecting messages listing multiple authors (so far, this recommendation is not contentious) and (b) the listing of multiple authors in the From: field is vanishingly rare in real-world email. For mailing lists, the use of From: to specify the poster in preference to the Mediator is specifically not standardised. It has of course been customary for a long time, however a substantial volume of Mediated email now identifies the Mediator in the From: field instead of the poster. It is correctly observed that much of this shift is in response to DMARC, but that does not make it any less real. Especially since it doesn't solve many other indirect mail issues, and would clearly be inappropriate to deal with, say, the "virus checker breaks DKIM signatures." Don't get me wrong -- an answer to Life, the Universe, and Everything is *not* a necessary condition. But I find the idea of a new standard Really-Truly-From-for-Indirect-Channel-X for each channel X quite distressing, and I'd rather not start down that path if there are less ugly alternatives available. This is unduly burdening the proposal. If mailing lists were some obscure corner case then, sure, but (a) they're not (you may have noticed their being mentioned occasionally in discussions around SPF, DKIM, ADSP, ...) and (b) they're an important enough special case that two draft standards already exist to specify additional List-* headers to identify list traffic (RFC 2919) and to state list commands (RFC 2369). If some more general mechanism comes up in this WG that deals with the mailing list case as well then, certainly, let's consider adopting it. Until or unless that occurs, the fact that it doesn't solve all of the known cases (let alone as-yet-undiscovered cases) is not an argument against it. - Roland ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage
On 09/18/2014 09:44 PM, John Levine wrote: The opportunity for this WG would appear to be to spell out sensible practices for use in the two situations, and perhaps to spell out the trade-offs for deciding between the two, assuming that we are able to do so without devolving into further equine abuse. I'd suggest that specifying a List-Poster: header for use in the rewrite case is an appropriate example of the former. While I realize that the enormous market power of the DMARC group has given mailing lists no choice but to use various workarounds, You've already pointed out the inappropriateness of rehashing this argument. The appropriate response here would appear to be to agree to disagree and, therefore, to avoid attempts to pick a winner. Using pejorative language to describe the actions of legitimate participants in the email system would appear to be out of scope. I don't think you'll find any consensus in this WG that From: rewriting or anything similar is a fait accompli. I did point this out. The WG need not involve itself in trying to pick a winner. I also haven't seen anyone seriously address the concern that List-Poster: and its ilk are a short term workaround with the long term effect of training users to be phished, even more than they are already. I have yet to see a credible threat model (plenty of hand-waving, to be sure). I would much rather look at technical approaches that allow mailing lists and other forwarding agents to continue operating as they have for the past 30 years, in as secure a way as possible, without inventing new giant holes for the use of the criminals that DMARC is supposed to deter. Your personal preferences are [very] well understood, and aren't appropriate here. As you have already pointed out, rehashing these arguments is not appropriate.[1] That's what my two-level DMARC forwarding signature proposal is supposed to do. I don't claim it's perfect, but I think it's within tweaking distance of being workable. I'm not wedded to it, there are other approaches that might work, too. I'd be happy to review it; got a URL? - Roland 1: I accept Tim's point about in-context summaries in relevant contexts. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage
Roland Turner writes: > It is hardly realistic to assume that no Mediators will make this > choice [to munge From], nor that all will. Agreed. > It would seem desirable to have a standardised method of specifying > the poster for those who do. Not at all clear to me. The From field currently is the standardized method of specifying the poster, and I'm not sure it's a good idea to have another. Especially since it doesn't solve many other indirect mail issues, and would clearly be inappropriate to deal with, say, the "virus checker breaks DKIM signatures." Don't get me wrong -- an answer to Life, the Universe, and Everything is *not* a necessary condition. But I find the idea of a new standard Really-Truly-From-for-Indirect-Channel-X for each channel X quite distressing, and I'd rather not start down that path if there are less ugly alternatives available. Regards, ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage
>The opportunity for this WG would appear to be to spell out sensible >practices for use in the two situations, and perhaps to spell out the >trade-offs for deciding between the two, assuming that we are able to do >so without devolving into further equine abuse. I'd suggest that >specifying a List-Poster: header for use in the rewrite case is an >appropriate example of the former. While I realize that the enormous market power of the DMARC group has given mailing lists no choice but to use various workarounds, I don't think you'll find any consensus in this WG that From: rewriting or anything similar is a fait accompli. I also haven't seen anyone seriously address the concern that List-Poster: and its ilk are a short term workaround with the long term effect of training users to be phished, even more than they are already. I would much rather look at technical approaches that allow mailing lists and other forwarding agents to continue operating as they have for the past 30 years, in as secure a way as possible, without inventing new giant holes for the use of the criminals that DMARC is supposed to deter. That's what my two-level DMARC forwarding signature proposal is supposed to do. I don't claim it's perfect, but I think it's within tweaking distance of being workable. I'm not wedded to it, there are other approaches that might work, too. It also has the advantage that the implementation effort is primarily by large users of DMARC, who I would expect are aware of this WG and might actually do it, rather than makers of MUAs, who aren't, and won't. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect mail flows
On 09/11/2014 07:41 PM, Hector Santos wrote: For multiple decades, starting with mail systems predating RFC822, with everyone one of them there was a common mail engineering taboo, "thou shall not tamper with mail" and one of the primary anchoring fields, the author of the message was a principle field you didn't screw around with. You either get it or you don't. I would suggest that accepting Subject: header tagging, footer addition, attachment stripping, etc. but then objecting to From: header rewrites to identify the [second] author who made all these changes is not merely straining at a gnat having swallowed an entire herd of camels, it's missing the point: * The "forward it clean" crowd would have messages unmodified right down to byte-stream level, but for the pre-pending of trace headers. Messages handled this way have various desirable properties, particularly including passing DKIM effortlessly, and therefore DMARC likewise. * Other forwarders change stuff. DKIM makes heroic efforts to compensate - and it would be sensible to specify further mitigations if there remain workable ones to specify - but the fact remains that once you start changing stuff - particularly big things like stripping attachments, adding advertisements, etc. - you're no longer in the "forward it clean" category; it's no longer even a relevant question. - Roland ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage
On 09/17/2014 05:10 PM, John Levine wrote: Lists that rewrite the From: line were a bad idea then, and are an equally bad idea now, for reasons that have been discussed to death. Your position on that debate is well known. I'd suggest that arguing over whether or not anyone should rewrite the From: header or not would be rather wasteful at this point as it is now abundantly clear that will be significant fractions of list-forwarding conducted both with and without From: header rewrites for the foreseeable future. The opportunity for this WG would appear to be to spell out sensible practices for use in the two situations, and perhaps to spell out the trade-offs for deciding between the two, assuming that we are able to do so without devolving into further equine abuse. I'd suggest that specifying a List-Poster: header for use in the rewrite case is an appropriate example of the former. - Roland ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage
On 09/17/2014 08:55 AM, Stephen J. Turnbull wrote: I believe that "Mediator" is the currently standardized generic term (RFC 5598), so "mediating list" would be the best such term. For the present discussion, although Mediators are indeed Authors (as defined by RFC 5598), the important specialization is that a Mediator "attempts to preserve the original Author's information in the message it reformulates". Sounds good. I'd note that the Mediator's Authorship trumps the poster's in any situation in which they clash (poster wants to include an attachment, Mediator removes attachments -> the forwarded messages will have no attachments) but yes, can see the sense in describing delivered list posts as having joint authorship. That said, the specifying of a List-Poster: header doesn't require determining which author is _*the*_ author for DMARC and 5322 purposes, I'd suggest that it's simply about describing an appropriate mechanism to use to indicate the author of the message prior to its passing through the Mediator for those operators who have decided to change the From: header to refer to themselves. It is hardly realistic to assume that no Mediators will make this choice, nor that all will. It would seem desirable to have a standardised method of specifying the poster for those who do. - Roland ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider
I used to get this error message no matter what email address I typed in : --cut-- Password request failed The automatic login and password service failed; manual intervention is needed. Please send a mail to webmas...@tools.ietf.org and explain the situation for further assistance. --cut-- Gave it another try just now, and my Gmail address was accepted :-) /Henrik On Thu, Sep 18, 2014 at 1:39 PM, Roland Turner wrote: > On 09/18/2014 07:30 PM, Stephen J. Turnbull wrote: > > I was referring to >> >> http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki >> >> > I had no trouble working through the automated sign-up. What trouble > (error message?) are you having with your email address(es)? > > - Roland > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Mvh/Best regards Henrik Schack ICQ: 889295 http://henrik.schack.dk/ http://links.schack.dk/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider
On 09/18/2014 07:30 PM, Stephen J. Turnbull wrote: I was referring to http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki I had no trouble working through the automated sign-up. What trouble (error message?) are you having with your email address(es)? - Roland ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider
John Levine writes: > If you're referring to the ASRG wiki, the person responsible for it is > me. I am unaware of any signup problems, and there are multiple > people contributing to it. I'm not sure what ASRG refers to, perhaps http://wiki.asrg.sp.am/? I was referring to http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki Sorry for not providing the URL in the first place. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider
I've added an indirect mail flow page to the ASRG wiki. If you don't have a password to log in and edit, write to me and I'll give you one. >> >IMO, the place to record the inventory is the wiki. Mailing lists are >> >not a good place to keep such records. >> I would love to add it to the Wiki, unfortunately the Wiki signup features >> seems to be broken, wont accept any of my email addresses. >> >And the person responsible does not respond when asking for help. If you're referring to the ASRG wiki, the person responsible for it is me. I am unaware of any signup problems, and there are multiple people contributing to it. Feel free to contact me directly for help. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
