Re: [dmarc-ietf] IETF Mailing Lists and DMARC

[Franck Martin <[e-mail]>]

> From: "Brandon Long" <[e-mail]>
> To: "Brian E Carpenter" <[e-mail]>
> Cc: "Michael Richardson" <[e-mail]>, [e-mail], "IETF"
> <[e-mail]>, "Cullen Jennings" <[e-mail]>
> Sent: Thursday, November 3, 2016 3:39:22 PM
> Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC

> On Wed, Nov 2, 2016 at 3:19 PM, Brian E Carpenter < [e-mail]
> > wrote:

>> On 03/11/2016 10:58, Brandon Long wrote:
>> > With the understanding that my email is unlikely to be received by some of
>> > those having issues...

>> > Let us assume that those who specify p=REJECT have a good reason for doing
>> > so, and that after 2-3 years, they are unlikely to change back.

>> > Let us also assume that the members of these organizations who are
>> > participating in IETF may or may not have any power over whether their
>> > admins have decided to be p=REJECT.

>> > And let us assume that we want these folks to participate in IETF.

>> Let me stop you right there. Yes, we want everybody to be free to
>> participate in the IETF, and presumably those people want to participate
>> in the IETF. But participants have to be able to use the tools that the
>> IETF has chosen, which includes mailing lists. That's always been true.
>> (In 1992, when I started in the IETF, it meant knowing how to subscribe
>> to a majordomo list. Today, subscribing is a bit easier, but it means
>> avoiding the DMARC trap.)

>> So such participants need to use an email sending address that works
>> with IETF mailing lists.

>> yahoo.com and google.com don't work properly with IETF mailing lists.
>> Fortunately, very fine alternatives are available, such as gmail.com .
>> (gmail's spam learning is even smart enough to work around p=reject,
>> as it did for this very message that I'm replying too.)

>> I think Michael Richardson made a very valid point. If our mailing
>> list software detects a sender whose domain has p=reject, we *know*
>> that the forwarded message will fail DMARC validation. So there's a
>> strong case for rejecting the message immediately, so that the sender
>> can be told about the problem and can choose a different sending address.
>> Presumably, we'd only need to do this until ARC is deployable.

> If enforcement of DMARC was universal (or nearly so), sure. Except, it's not.
> As you said, Gmail didn't enforce it in this instance.

> Rejecting the messages is definitely an option. As stated down thread, I
> wouldn't
> think it's the best choice for the members.

Politics of exclusion are easy but usually do not go far... us vs them is never a long term option. 

but I'd like to point to a new problem surfacing as security is shifting with DMARC: impersonation on mailing lists. 

Several large lists have been recently caught by email impersonating list members. 

Was it successful enough for the miscreant? Will we see more in the future? 

Do lists need to check DMARC on incoming mail and apply policy? Do they need to do more than DMARC and authenticate the poster?