From: "Brandon Long" <blong(_at_)google(_dot_)com>
To: "Brian E Carpenter" <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>
Cc: "Michael Richardson" <mcr+ietf(_at_)sandelman(_dot_)ca>,
dmarc(_at_)ietf(_dot_)org, "IETF"
<ietf(_at_)ietf(_dot_)org>, "Cullen Jennings" <fluffy(_at_)iii(_dot_)ca>
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 <
brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com
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?