> On Apr 16, 2014, at 11:00 PM, ned+ietf@xxxxxxxxxxxxxxxxx wrote: > >> On Sat, Apr 12, 2014 at 4:35 PM, <ned+ietf@xxxxxxxxxxxxxxxxx> wrote: > > > >>> The underlying technical issue is that the two technologies DMARC is built > >>> on - > >>> DKIM and SPF - both attach additional/restrictive semantics to > >>> longstanding mail > >>> system fields. (Broadly speaking, From: for DKIM and MAIL FROM for SPF.) > >>> > > > >> Something's amiss here. What new semantics does DKIM attach to From:? As > >> far as I know, it only requires that the field be signed. It doesn't > >> require that it be interpreted in a particular way or that it contain any > >> particular value. > > > > I was trying to be brief. Yes, I'm well aware that DKIM can be used in other > > ways. This entire discussion is within the context of DMARC here. Do you > > disagree that DMARC's use of DKIM and SPF assign additional semantics to header > > and envelope from fields respectively? > Murray is correct. DKIM does not create special From header field semantics. Actually, by requiring that the signature cover the From: field, it sort of does. But that's beside the point. Again, I was talking about DMARC's use of DKIM, not DKIM usage in general. > However, DMARC semantics are similar to those of ADSP while avoiding some > shortcomings. But both of them attach additional semantics to From:. (Not that they had a choice; as I pointed out previously, in order to acheieve the stated goal they have to attach the check to the identity users actually see.) > ... > >> Also: By "the IETF published a draft", are you talking about an RFC, or the > >> DMARC base draft? > > > > The draft, of course. > > > >> It seems extreme to lay blame on the IETF in general > >> merely for having an open mechanism by which to post a draft for all to see > >> and discuss. A "Request For Comment", as it were. > > > > You may think it extreme. I don't. I think the IETF's politics have led to it > > inching closer to moral hazard territory for a long time, and with this > > incident it has stepped in it. > This disruption should be shared with the provider that has already > enumerated 30,000 mailing-lists but made no effort to establish a means to > verify these sources and to safely assert specific exceptions to DMARC > alignment requirements. This ability is desperately needed before applying > DMARC reject on user accounts. I'll be happy to modify either ATP or ATPS to > permit these exceptions without the need to alter mailing-list. I'm by no means sure that ATP or ATPS is the right answer, but I certainly agree that we need to at least try and address the situation that's been created. Sigh. We have a lot of work to do, don't we? Ned