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

Cullen Jennings <fluffy@iii.ca> Wed, 02 November 2016 22:14 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2192F12953E for <ietf@ietfa.amsl.com>; Wed, 2 Nov 2016 15:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRNrywayU0Si for <ietf@ietfa.amsl.com>; Wed, 2 Nov 2016 15:14:03 -0700 (PDT)
Received: from smtp142.dfw.emailsrvr.com (smtp142.dfw.emailsrvr.com [67.192.241.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67FE12965C for <ietf@ietf.org>; Wed, 2 Nov 2016 15:14:02 -0700 (PDT)
Received: from smtp26.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B41C0A02A5; Wed, 2 Nov 2016 18:14:01 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp26.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0F57EA01AF; Wed, 2 Nov 2016 18:14:00 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.7); Wed, 02 Nov 2016 18:14:01 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CABa8R6vHdt75NFKW3s6xOzLcq=jmVAHDPX0tjLRdGpYSTP2cYA@mail.gmail.com>
Date: Wed, 02 Nov 2016 16:13:59 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <B3D04B32-C387-4C3F-B062-F961FF214679@iii.ca>
References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <CABa8R6vHdt75NFKW3s6xOzLcq=jmVAHDPX0tjLRdGpYSTP2cYA@mail.gmail.com>
To: Brandon Long <blong@google.com>
X-Mailer: Apple Mail (2.3226)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/31IjZ5jrYUJ5Zvg47X3Ca2M3oyk>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "dmarc@ietf.org" <dmarc@ietf.org>, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2016 22:14:05 -0000

Agree with your assumptions ( and the later point that receiving person can't controls what their admins do any more than sender can control what their admins do)

But there are two failure modes for something like this 

1) sender knows their email was not received 

2) email was not received by a bunch of people and neither the sender nor receiver knows that

The second failure mode is much worse than the first. 


> On Nov 2, 2016, at 3:58 PM, Brandon Long <blong@google.com> 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.
> 
> I will assume that if you're not willing to stipulate to the above, then you don't actually want a solution.
> 
> We are then left with only moving forward.
> 
> If this is a problem for you as a receiver, you can choose to attempt to whitelist the ietf mailing list mail from DMARC enforcement.  You may not be able to do so, just like the sender may not be able to change their organizations DMARC record.
> 
> The middle man, ietf, can work around this today.  They need to run a new enough version of mailman and enable one of the workarounds.  For mailman, this means munging the mail, usually the From header.  It's not pretty, but it works, it works now, and it will work for everyone.  The difference is mostly cosmetic, though depending on your mail client, there may be other downsides.  And it may violate RFC 5322.
> 
> I don't think this is possible with mailman, but theoretically it is also possible for a mailing list to pass the message through without breaking the DKIM signature.  This means no footers and no subject tags.  Which of these a list would choose is probably dependent on the list members.
> 
> mailman should also know how to tell the difference between a message specific policy bounce, and particular DMARC bounces, and should apply different heuristics to handling them.  I have no idea if that existing in any version of mailman or is a planned feature.
> 
> There is a proposed standard, ARC, that would allow mail receivers to do more intelligent whitelisting.  It's not ready yet.
> 
> It is unfortunate that these types of choices have to be made.
> 
> Brandon
> 
> 
> On Wed, Nov 2, 2016 at 12:00 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> Cullen Jennings <fluffy@iii.ca> wrote:
>     > So if someone send a email with a bad signature to an IETF list from a
>     > domain that has a reject policy, and the IETF server forwards it to my
>     > email email provider, my email provider rejects it. Now the IETF email
>     > server counts that as a bounce. Too many bounces in a row and the IETF
>     > server unsubscribes me from the list.
> 
>     > This does not seem OK that anyone can trivially send some SPAM and get
>     > me unsubscribed.
> 
> yeah, that's a real problem isn't it.
> 
> After nearly three years of yelling about this problem, we are not even close
> to consensus that it's a problem, with many people suggesting that IETF mailing
> list software should just munge headers.
> 
> DMARC WG was supposedly designing a solution. I don't know where that is.
> 
> My take is that IETF mailing list software should reject email from p=reject
> senders, since that's their stated policy.
> 
> The original threads include:
>     https://www.ietf.org/mail-archive/web/ietf/current/msg99659.html
> 
>     > What's the right advice on how the IETF server should be run?
> 
>     > Now to a more detailed problem - Jana sends lots of email to the quic
>     > list. I don't get any of them. It appears that my email server (run by
>     > rackspace) rejects them with an
> 
>     > Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy for
>     > google.com (G15)
> 
>     > If Jana sends the email directly to me, it works. This seems to point
>     > at the IETF server is doing something that breaks signature in Jana
>     > email.
> 
> Jana needs to stop sending from google.com.
> 
> Their policy is that not to forward, so sad to lose all the google.com
> contributors.... we really shouldn't violate their stated policy.
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 
>