Re: [dmarc-ietf] yet more From rewriting,

Brandon Long <blong@google.com> Tue, 23 September 2014 21:58 UTC

Return-Path: <blong@google.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD9B1A2130 for <dmarc@ietfa.amsl.com>; Tue, 23 Sep 2014 14:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.164
X-Spam-Level:
X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 YDWpOVIjI_wd for <dmarc@ietfa.amsl.com>; Tue, 23 Sep 2014 14:58:39 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74A81A01EF for <dmarc@ietf.org>; Tue, 23 Sep 2014 14:58:38 -0700 (PDT)
Received: by mail-ig0-f178.google.com with SMTP id r10so5429404igi.5 for <dmarc@ietf.org>; Tue, 23 Sep 2014 14:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NLHoyZoVITHLjCBv5FTGQchpstJHEnywUPn9fZcEIWA=; b=VrDBYusXKSl1VqrDA5UV62reozb6jnl25Pnm+2wbuU1VyGP9pHzDvPsi0eZtkwb15+ zduxyKaJ5HsQ7ViAhY26XFMBHe0sfSLAwI87zy7GnCxP8vY0LfrlgC8eJ/bXOlQaa6D/ 3xQyuktPQiSSE8hVjh/ej8NDkR+D5J6dzYzBlJN7hsWqLtrFPZMNO4hslT3pAZvwHy6F P80Cpf2LM+E0JttAVn1E3cMF9gUfDRwDNfCYDyyB348NMRL9RV7Y4WDyEJDz5YyB95/J NL1ByS9Aeg3tLK1S3s3Km/XxPZdcNDV/uF09ypO6l0rPXhfq5O04TVq5Kh1gGZC2t0uD ptKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NLHoyZoVITHLjCBv5FTGQchpstJHEnywUPn9fZcEIWA=; b=DCO5Ud2Wqi+57Wx5VcDprj/yY/ylDrz1mn/WFdcxMh5h05UsLTcD/u6kTRgYXqe30t 09gjmeKLlmzSXWt4oBsbBaoV3B32PyAyJh0f5cALODSf7PT7dU/1NOe2l9CSqq6Ekp1s kypKvfKh6wtLlPcGIdkucOnaiYeIVT2Qjoi8S2PnT21HtooEV4emqsY4Hyfjv3Egv9iZ mkvJzocuWCsE8GmQGngl1k0eypL3rjji4YUvlMj/4XRzhwRhJ0jq6seVEjKOZ3tordcS yJU3vk9nO8shxyI9ODJNFhnLNW9Kskks9HLEBRaXMlq479lXccrHRP5o2uOXwHt9lLVc aDbw==
X-Gm-Message-State: ALoCoQnJO+KyZY0jJ/oQIR4x7Fwrqnqx8TTf0JYcyVkPwFC78Q46Ekv3aGK/Xyu7ztXDjSXFyUvi
MIME-Version: 1.0
X-Received: by 10.50.78.70 with SMTP id z6mr25894183igw.23.1411509518203; Tue, 23 Sep 2014 14:58:38 -0700 (PDT)
Received: by 10.64.62.78 with HTTP; Tue, 23 Sep 2014 14:58:38 -0700 (PDT)
In-Reply-To: <5421B22C.40001@crash.com>
References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <CAKXPkzt8ZVo9=Eh5kRcmvgfUvejLcQxrsP3QhF_gU56t-3PChg@mail.gmail.com> <5420A91B.2070102@crash.com> <87y4taxn75.fsf@uwakimon.sk.tsukuba.ac.jp> <5421B22C.40001@crash.com>
Date: Tue, 23 Sep 2014 14:58:38 -0700
Message-ID: <CABa8R6ujVyv606qDo+pNnTZah4Gf5_gmjM0+jNnvrohe_i509g@mail.gmail.com>
From: Brandon Long <blong@google.com>
To: Steven M Jones <smj@crash.com>
Content-Type: multipart/alternative; boundary="089e0112cfb06e3b8a0503c2abfb"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ql24idIHCpond8bobVdt8mkBgrg
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] yet more From rewriting,
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Sep 2014 21:58:45 -0000

On Tue, Sep 23, 2014 at 10:47 AM, Steven M Jones <smj@crash.com> wrote:

> On 09/23/2014 10:26 AM, Stephen J. Turnbull wrote:
> >  On 09/22/2014 03:17 PM, Josh Aberant wrote:
> >
> >  > > alias. Google Groups (takes ownership of the From per our
> >  > > #RejectPolicy) and then
> >
> > I don't understand "our #RejectPolicy".  What are you talking about?
> > Surely not DMARC?  That reject policy would be related to the From
> > Domain of the user, not anything about Twitter.
>
> My reading was that this was some kind of configuration item within
> Google Groups. Therefore it's interesting if it is a normally available
> feature that any Google Group might use to alter the RFC5322.From or add
> an X-Original-From: header.
>

Google Apps currently implements "aliases" as Google Groups (this has been
true for a number of years now, prior to that there were separate aliases
and groups).  Because of this, a "support@twitter.com" address that
redirects to internal users or an external CRM tool (salesforce) would be
getting a groups rewritten message.  These messages will not pass DKIM due
to the rewriting, and so if they're from a DMARC p=REJECT/QUARANTINE domain
such as yahoo.com, the from header will be rewritten to be the group name (
support@twitter.com) and the x-original-from will be the original sender.

Its technically possible with Google Apps domain routing rules to reroute
support@twitter.com to another address without passing through Groups and
therefore DKIM would still pass... obviously SPF wouldn't, however.  Doing
this for a number of addresses would probably be more complicated than
using Groups as the alias.

Currently, Groups rewrites messages even if the group has no footer or
subject prefix.  We're investigating having an "alias" like mode for Groups
which would allow DKIM messages to pass unscathed.

In any case, support folks, especially when dealing with paying customers,
tend to want to get all of the email, they don't want their nicely paying
customers to not get support just because of spam false positives or the
mail routing breaking dkim.

I'm not sure if any of this is particularly relevant except to say that if
one does from header rewriting, it is generally useful for there to be a
machine readable and potentially standard place to find the original
sender.  That said, I also agree that displaying that address directly to
the end user, especially without verification through some mechanism like
OAR, would defeat the purpose of DMARC in the first place.  If we knew how
to display from addresses to users without making them phishing targets, we
wouldn't have needed DMARC.

Brandon