Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

[[e-mail]]

> On Apr 16, 2014, at 11:00 PM, [e-mail] wrote:

> >> On Sat, Apr 12, 2014 at 4:35 PM, <[e-mail]> 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