Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)
Brandon Long <blong@google.com> Wed, 09 November 2016 22:18 UTC
Return-Path: <blong@google.com>
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 121B41299BE for <ietf@ietfa.amsl.com>; Wed, 9 Nov 2016 14:18:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 4J-TZBrcgVg8 for <ietf@ietfa.amsl.com>; Wed, 9 Nov 2016 14:18:24 -0800 (PST)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F354412956F for <ietf@ietf.org>; Wed, 9 Nov 2016 14:18:04 -0800 (PST)
Received: by mail-it0-x22e.google.com with SMTP id e187so227949196itc.0 for <ietf@ietf.org>; Wed, 09 Nov 2016 14:18:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MRzqeRAt84MTNg2agjZsxg/Qqvj5TIVqbJZ5tv7GAuM=; b=cwXgmZt1fkO3Ls0N55rP7BLBzmlyPHg0t+LZ/Lrev92jp1MgxmQ2lr41s+vgTPtz0m Mrf1YrTChYr3gD8EFHdpVbNpVVGQBkIWpTXtNNoU3lMCrN1TadBqdDVX+w1I6/bpPqOm jZfH9B5PIxh6k4olnns9x8zDpM5cWw7krgdFiWAwiNegPxs2iPDuiwlBpMineGxnMlke rP3KUsKCNUsarxN/J35nDEWL/0nOMCd41y6tqvdjBAoSMt6jgkhYFqhURNiarMTYPSrl 0xOrpD8qT99V/A0JF0M2Zoaz2rTv5NFAFb88GclJUtjcNJp4RBYxALbbInhsrUio/xHL 9g1A==
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:from:date :message-id:subject:to:cc; bh=MRzqeRAt84MTNg2agjZsxg/Qqvj5TIVqbJZ5tv7GAuM=; b=KgILuUd9JucgenJDH8270O8m5ysRrsrRh/JXxdlpJHBlIWnRy1q1dH6ALHVWFIGCXJ fTSVd721EmpIJ9fT8EIoEXVyxGls1kx+BKG213vW0ee6qBl4HgGNRfUDV6eD59DiNn0n wBz06ty5CPM1fxx8zinoD0htR9GwfgKgqf7/lng3qWsnSy/YrywzojCaqk2V6vL4wRgJ eafdwDteR6tlx8nKHkazZWJeBJseqijVzBNbM9Hb3npB5yJwERyFr2HhLAW0qfvegOID 4pLUTF/U2szX9c4+oYSJQ21e3kEiJusvbwdUDH0m9/DTnzSXxwTHtrocWiagtUqcYvC5 MffQ==
X-Gm-Message-State: ABUngvdFIosi8b3/OHQRazRUuAj+6VSKj9um3nJWDxrKpUMmOng8W+Chfd8FWjDOgqKRBLCFSGqP8ni2SDQMOSZF
X-Received: by 10.202.81.5 with SMTP id f5mr1329447oib.24.1478729882422; Wed, 09 Nov 2016 14:18:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.39.167 with HTTP; Wed, 9 Nov 2016 14:18:00 -0800 (PST)
In-Reply-To: <B3DC791C1E1FC26F69500F06@JcK-HP8200>
References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <CABa8R6vHdt75NFKW3s6xOzLcq=jmVAHDPX0tjLRdGpYSTP2cYA@mail.gmail.com> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <CABa8R6u7WbbeXzkhkNM46RYtMSw7V9FT2m_LvKLHaFDvF3cw3A@mail.gmail.com> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> <CO2PR00MB01034350A8C90A1E039336F796A20@CO2PR00MB0103.namprd00.prod.outlook.com> <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> <01Q71GG3KUM8011H9Q@mauve.mrochek.com> <B3DC791C1E1FC26F69500F06@JcK-HP8200>
From: Brandon Long <blong@google.com>
Date: Wed, 09 Nov 2016 14:18:00 -0800
Message-ID: <CABa8R6v9qegBmzcsdM6T-oZbaqqs8Soa2CpEEo1wB47eU2=CHg@mail.gmail.com>
Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)
To: John C Klensin <john-ietf@jck.com>
Content-Type: multipart/alternative; boundary="001a113d7e885c98020540e5a11a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ypffOuK73o0S0Gi9sykrt1uZn9o>
Cc: Dave Crocker <dcrocker@gmail.com>, IETF <ietf@ietf.org>, Franck Martin <franck@peachymango.org>, ned+ietf@mauve.mrochek.com, "dmarc@ietf.org" <dmarc@ietf.org>, ima@ietf.org, Terry Zink <tzink@exchange.microsoft.com>
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, 09 Nov 2016 22:18:26 -0000
I think the EAI discussion took a turn a bit, but my point was: EAI sender sends mail to an EAI capable mailing list which has members which are not EAI capable is a similar scenario to what we're discussing here for DMARC. Ie, in order to resend the message, the choices are: 1) Do nothing and maybe the receiver allows the EAI message despite it not conforming to RFC 5322 and despite the receiving mail server not advertising SMTPUTF8... or maybe it rejects it. 2) Downgrade the message such that everyone on the list receives something, even if not what we'd prefer they receive 3) Don't forward EAI messages to non-EAI capable members 4) Don't accept any EAI messages to the mailing list if there are any non-EAI capable members Now, it turns out that the majority of mail software is probably fine with #1 with some level of degradation, so we're less likely to see #2 than we are in the DMARC case. Even so, at least this is an ability one could probe, so we could know when to downgrade and when not to, theoretically... a mailing list could also interpret DMARC rejects, I guess, and learn when to downgrade and not on a per-recipient basis. I would think that both #3 and #4 are less polite choices, and ditto with applying them to DMARC. In any case, I'm sure the EAI folks discussed what to do in this scenario, but I'm not really discussing whether or not #2 is within spec as much as I'm talking about the better support for your users in an imperfect world and drawing a parallel to DMARC. Brandon On Mon, Nov 7, 2016 at 7:25 PM, John C Klensin <john-ietf@jck.com> wrote: > (adding the EAI list to the distribution -- there are people who > hang out there who need to see, and check on, this) > > --On Monday, November 07, 2016 15:08 -0800 > ned+ietf@mauve.mrochek.com wrote: > > >> Absent that, there's the small question about how the EAI > >> group would have the authority to make such a major change to > >> such a basic email feature... > > > > RFC 6854 can speak for itself as to the rationale for allowing > > no address. > > > > The EAI connection was, as I recall, for use in downgrade > > formats used to > > present EAI messages to non-EAI clients via POP3 and IMAP4. > > Yes. > IIR, 6854 was written the way it was in order to avoid getting > tangled up with normative dependencies on the EAI specs. > However, I find the combination of its Section 3 ("Applicability > Statement") and Security Considerations rather clear as to both > the motivation and the "don't do this if you don't need to and > especially don't originate a message with this" advice. > "Limited Use" is really very restrictive. > > The problem (and tradeoff) are as follows: > > A message gets delivered and gets as far as a mailstore with a > backward-pointing address that looks like: > "Non ASCii Name Phrase" <non-ascii-local-part@domain-part> > > Note that, if the message got that far, the delivery MTA > advertised itself as fully SMTPUTF8-complaint. > > Then a POP or IMAP client comes along that does not support > non-ASCII addresses or headers. Now, there are probably three > plausible choices for the IMAP server (other than just dying a > horrible death): > > (a) Trash the message on the theory that any users who would get > themselves into that situation deserve it. However, remember > the important case is a backward-pointing address and, in the > general case, the delivery server doesn't know what client(s) > the user is going to use (and there might be more than one). > > (b) Figure out how to respond to any IMAP request that involves > that message with some flavor of "I have this message for you, > but you can't get it and I can't tell you about it until you > show up with an upgraded client". > > (c) Convert "Non ASCii Name Phrase" to encoded words and then do > something unpleasant to the address, of which using group syntax > was by far the least problematic solution anyone could come up > with. If the Return-path in the mailstore is the same as the > address in the "From:" and/or "Sender:" header fields, it is > going to be trashed, so a competent IMAP server doing this is > going to figure out how to warn the user and the user, perhaps > after consulting support personnel the first time one of these > happens to her, is going to figure out that doing anything with > the message other than broadly getting its gist is going to > require using an upgraded client. > > IIR, these issues are discussed at some length in RFCs 6855-6858. > > Now, coming back to the "identification of ... author" problem > and remembering the "Limited Use" bit, if I were designing a > submission server and something reached me with a group name in > the "From:" (or "Sender:") field, I'd probably return it to > whence it came. I'd probably do the same thing if I were a > relay or delivery server, noting that there is no equivalent to > group syntax in SMTP. Both are entirely consistent with > Limited Use -- if one uses it in a context in which it makes no > sense or poses a security threat, one refuses to accept it. > > If anyone things that needs to be said more clearly in one of > the EAI-related documents and wants to suggest language, I, and > I assume others, anxiously await an I-D. > > john > >
- Re: IETF Mailing Lists and DMARC Dave Crocker
- IETF Mailing Lists and DMARC Cullen Jennings
- Re: IETF Mailing Lists and DMARC John Levine
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC John Levine
- RE: IETF Mailing Lists and DMARC MH Michael Hammer (5304)
- RE: IETF Mailing Lists and DMARC John R Levine
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC John Levine
- Re: IETF Mailing Lists and DMARC Dave Crocker
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC Paul Hoffman
- Re: IETF Mailing Lists and DMARC John C Klensin
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC Michael Richardson
- Re: IETF Mailing Lists and DMARC Yoav Nir
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC Yoav Nir
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Hector Santos
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Dave Crocker
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Brandon Long
- Re: IETF Mailing Lists and DMARC Cullen Jennings
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Cullen Jennings
- Re: IETF Mailing Lists and DMARC S Moonesamy
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Brian E Carpenter
- Re: IETF Mailing Lists and DMARC John Levine
- Re: IETF Mailing Lists and DMARC John Levine
- Identification of an email author (was - Re: [dma… Dave Crocker
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Theodore Ts'o
- RE: [dmarc-ietf] IETF Mailing Lists and DMARC Terry Zink
- Re: IETF Mailing Lists and DMARC John Levine
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Theodore Ts'o
- Next step on IETF Mailing Lists and DMARC Alexey Melnikov
- Re: IETF Mailing Lists and DMARC Bob Hinden
- RE: IETF Mailing Lists and DMARC MH Michael Hammer (5304)
- Re: IETF Mailing Lists and DMARC Ted Lemon
- RE: [dmarc-ietf] IETF Mailing Lists and DMARC Terry Zink
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Andrew G. Malis
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Steve Atkins
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Andrew G. Malis
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Theodore Ts'o
- Options for temporary operational solution to DMA… Ted Lemon
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Brandon Long
- Re: [dmarc-ietf] Identification of an email autho… Brandon Long
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Franck Martin
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Hector Santos
- Re: Options for temporary operational solution to… Andrew G. Malis
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC John C Klensin
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC Michael Richardson
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Michael Richardson
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Michael Richardson
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC John C Klensin
- Re: Options for temporary operational solution to… John Leslie
- RE: [dmarc-ietf] Identification of an email autho… Terry Zink
- Re: Options for temporary operational solution to… Toerless Eckert
- Re: [dmarc-ietf] Identification of an email autho… Ted Lemon
- Re: Options for temporary operational solution to… John Levine
- RE: [dmarc-ietf] Identification of an email autho… Terry Zink
- Re: Options for temporary operational solution to… Ted Lemon
- RE: [dmarc-ietf] IETF Mailing Lists and DMARC Christian Huitema
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Brian E Carpenter
- Re: Options for temporary operational solution to… Michael Richardson
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Michael Richardson
- Re: Options for temporary operational solution to… Dave Crocker
- Re: [dmarc-ietf] Identification of an email autho… Franck Martin
- Re: [dmarc-ietf] Identification of an email autho… Khaled Omar
- Re: [dmarc-ietf] Identification of an email autho… S Moonesamy
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Brandon Long
- Re: [dmarc-ietf] Identification of an email autho… Dave Crocker
- Re: [dmarc-ietf] Identification of an email autho… Dave Crocker
- Re: [dmarc-ietf] Identification of an email autho… ned+ietf
- Re: [dmarc-ietf] Identification of an email autho… Franck Martin
- Re: [dmarc-ietf] Identification of an email autho… Dave Crocker
- Re: [dmarc-ietf] Identification of an email autho… John C Klensin
- Re: [dmarc-ietf] Identification of an email autho… Brandon Long