From nobody Sun Feb  1 19:22:36 2015
Return-Path: <ned+dmarc@mrochek.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 7B5821A9245 for <dmarc@ietfa.amsl.com>; Sun,  1 Feb 2015 19:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.688
X-Spam-Level: 
X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 V0uQWJb45CDA for <dmarc@ietfa.amsl.com>; Sun,  1 Feb 2015 19:22:23 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 03F281A9236 for <dmarc@ietf.org>; Sun,  1 Feb 2015 19:22:23 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PI0N0YQMKW003H7M@mauve.mrochek.com> for dmarc@ietf.org; Sun, 1 Feb 2015 19:17:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1422847041; bh=X1iVFtoPFhVMcFeLH9XNq1aPEdwItUDajLAljBuNrhg=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=ii5wUJxd2LJ0Vp6iC2snl1b52RkyafY4F9YCSMmGhppgt8rrKRggJRL9bGAuLiQ7i IFzdvMtemn9jhyWsgJeIJ2g6AhPQ2MtQKKLCeynoQsySjOq2R9InyZ8jj4RsDVWjud vEuJQM6PTMB4dDDeGW4aWrUSKdcRXOmWY9Us9mI4=
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=utf-8
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PHTJGGFVBK000052@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Sun, 01 Feb 2015 19:17:18 -0800 (PST)
From: ned+dmarc@mrochek.com
Message-id: <01PI0N0XDKNA000052@mauve.mrochek.com>
Date: Sun, 01 Feb 2015 17:58:10 -0800 (PST)
In-reply-to: "Your message dated Thu, 29 Jan 2015 14:09:52 -0500" <E17F9594-A071-4DBC-B1A7-049CCC382DD7@eudaemon.net>
References: <E17F9594-A071-4DBC-B1A7-049CCC382DD7@eudaemon.net>
To: Tim Draegen <tim@eudaemon.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/vQnERexhDb9J6u9JVtPXRpGkhbY>
Cc: dmarc <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] interoperability draft for review
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: Mon, 02 Feb 2015 03:22:34 -0000

> Hi all,

> Frank, Eliot, and myself have finished up a first cut at the WG’s 1st real deliverable:
> 	• Document describing interoperability issues with DMARC and indirect mail flows and possible methods for addressing them.

> Please review at your convenience and submit comments, feedback, and suggestions for text to this list.  Frank and/or Eliot will be folding in edits.  A serious effort to cast issues in the language of RFC 5598 was made.

> Find it here:  https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/

> Our aim is to have this document ready for publication by end of February.

<chair hat off>

A few quick comments:

The introduction classifies message transformations as a type of indirect mail
flow. This takes a little getting used to, to say the least. For example, if
someone's mail always traverses a relay which incorporates boundary filtering
functionality that breaks DKIM signatures, and this in turn prevents them from
performing DMARC checks, you may have a hard time convincing them that there's
anything "indirect" about the path.

Of course it all works if you define "indirect" as anything more complex than
an agent that incorporates a DKIM signer sending directly to the agent that
verifies the signature. (And even this could involve a transport encoding
change that breaks a DKIM signature.) I admit there's some temptation to define
things this way - but do we really want to go there?

There also really needs to be a distinction made between indirect paths that
involve final delivery and subsequent resubmission and those that do not. I for
one don't have much expectation that if I resend a message that's been
delivered to me without changing the From: field that it will pass muster.
Message that fail because of the involvement of a simple alias are another
matter. 

The last sentence in section 2.1 doesn't really make sense to me. There is no
problem with having multiple SPF records point at the same server IP address or
addresses, so multiple mail streams are not issue. Of course this doesn't
make this sort of thing a good idea. Selecting the host name for use in
HELO/EHLO do that SPF checks will pass, while theoretically possible, is
entirely contrary to the purpose of the parameter and thus bad operational
practice. Indeed, I have to question why this is in the draft.
Are people actually doing this?

Section 2.2 is incorrect in regards to how SPF mismatches on forwarders occur.
Essentially all forwarders change the 5321.HELO/EHLO, but simple alias exansion
usually does not change the 5321.MailFrom. In these cases the issue isn't that
the 5321.MailFrom doesn't match the 5322.From, but rather that the SPF check
may fail because the list of allowed IPs does not include the forwarder.

Section 2.3 needs considerable expansion, and needs to talk about the
differences between simple and relaxed canonicalization.

3.1.2.1 conflates at least two different meanings of the word encoding.
Further, only changes to the transport encoding fall under the purview 
of an MTA; charset transcoding is a gateway function and needs to move
to the proper section for that.

3.1.2.2 ismispositioned. An MTA that modifies, adds, or removes content isn't
just an MTA, it's also performing the function of a gateway, boundary filter,
mediator. etc. And once you get into such functions, AS/AV checks are but one
possible action among many.

I guess my suggestion would be to talk about AS/AV checks and message
modification under boundary filter. That's where RFC 5598 positions such
things. (I note in passing that a brief mention of AS stuff is already in
section 3.2.5. Merging this section in there seems like a good idea to me.)

I also don't see how outright blocking is relevant to the matter at hand. Sure
boundary filters reject or discard messages all the time, but how are such
cases relevant to DMARC interoperability? DMARC validation can't fail for a
message that never made it to the validator.

Section 3.1.2.3 "invalide" -> "invalidate"

In section 3.1.3, Sieve is in no way limited to messing around with headers.
For example, sieve extensions exist that can delete or modify message parts.

That said, since Sieve operates on or around the time of final delivery, such
modifications are supposed to be happening at a point past where DMARC checks
have been performed. It's only when messages are reintroduced into the
transport infrastructure with the same From: field that issues may arise, and
this needs to be noted.

What is the first sentence of section 3.2 supposed to mean?

Section 3.2.3 really needs to talk about why mailing lists perform the message
modifications they typically perform.

I don't believe the use of X-Original-From is described in any RFC currently.
If we're going to talk about it in section 4.3 we need to talk about how
it's actually used or refer to some place that does.

The Internet is a big place, and none of us are in a position to fully assess
the state of play in every nook and cranny out there. As such, I'm very
reluctant to make statements like "there is very little reason to modify the
encoding of a message". What if there are good reasons to somwhere? Do we 
really want another round of the charset wars in this context?

And as for transport encodings, like it or not, the standards say that if 
you're in possession of an 8bit message and the system you're sending it
to doesn't support 8bitMIME, you either downgrade or bounce. Of course you
can argue that this is obsolete, but do we really want to open this 
particular can of worms in this document?

And on a similar note, try selling what 4.4.1.2 says to a financial institution
that is bound by laws saying what must be and cannot be in the messages it
emits as well as what's inbound messages destined for employees. I'm sure
they'll find it amusing.

That's it for now.

</chair hat off>

				Ned


From nobody Mon Feb  2 18:31:39 2015
Return-Path: <johnl@taugh.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 22E9A1A1B7E for <dmarc@ietfa.amsl.com>; Mon,  2 Feb 2015 18:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.263
X-Spam-Level: **
X-Spam-Status: No, score=2.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=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 IQQy6d-8x1BV for <dmarc@ietfa.amsl.com>; Mon,  2 Feb 2015 18:31:36 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F971A1BDD for <dmarc@ietf.org>; Mon,  2 Feb 2015 18:31:35 -0800 (PST)
Received: (qmail 3593 invoked from network); 3 Feb 2015 02:31:33 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Feb 2015 02:31:33 -0000
Date: 3 Feb 2015 02:31:11 -0000
Message-ID: <20150203023111.14642.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dmarc@ietf.org
In-Reply-To: <E17F9594-A071-4DBC-B1A7-049CCC382DD7@eudaemon.net>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/UqmVfOSynU2KE00ThALdPjGF7UM>
Cc: tim@eudaemon.net
Subject: Re: [dmarc-ietf] interoperability draft for review
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, 03 Feb 2015 02:31:37 -0000

In addition to other comments:

Section 3.1.2.3 is just wrong.  EAI specifically does not allow for
downgrading of messages in transit from UTF-8 headers to ASCII
headers.  The only place the header downgrade is allowed is when a
non-EAI MUA picks up mail via POP or IMAP, but that would be long
after any DMARC tests were applied.  You were probably confused
because the early experimental version of EAI did allow downgrades in
transit, but they worked so poorly that we took them out of the
standards track version.

One place it might happen is when mail is relayed through a mailing
list, but that's really the same issue as any other modifications a
mailing list makes to mail that passes through it.  See RFC 6783.

In section 3.2.1, there are certainly vanity domains (I have lots of
them) but I think you're more referring to stable addresses from
professional associations or alumni associations, e.g., I will always
be uucp@computer.org regardless of where I get my mail.  Some
rewording would likely help to clarify what you're talking about, and
the fact that most of them do not offer MSAs but expect you to use the
one provided by your current mail system.

In 4.4.1.1 the main reason to recode is if a message arrives via an
8BITMIME channel and leaves via a 7 bit channel so it has to change
from 8bit to quoted-printable or base64.  Every curent MTA can handle
8BITMIME but there are still a fair number of dusty old ones.

Section 4.4.1.3 is wrong for the same reason that 3.1.2.3 is wrong.
If you send an EAI message, it'll either be delivered as EAI or
bounce.  There is some ambiguity about what a DKIM signature on an EAI
message would look like (is the domain in d= a U-label or A-label) but
they should not be a big deal to work out.

In section 4.5.1, another mailing list workaround is to rewrite the
From: address into another address with an aligned signature that
forwards to the original address.  LISTSERV does this by rewriting to
some random looking address in the list's domain, I do it by appending
a local domain such as DMARC.FAIL.

R's,
John


From nobody Tue Feb 10 00:34:14 2015
Return-Path: <franck@peachymango.org>
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 850141A00DB for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 00:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.299
X-Spam-Level: *
X-Spam-Status: No, score=1.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=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 iRiPL-iyWOOK for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 00:33:58 -0800 (PST)
Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id B4D7B1A00DC for <dmarc@ietf.org>; Tue, 10 Feb 2015 00:33:58 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 4EBAE5641FA; Tue, 10 Feb 2015 02:33:58 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 35558A02E5; Tue, 10 Feb 2015 02:33:58 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-rLeXzkAZzb; Tue, 10 Feb 2015 02:33:58 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E41E9A02FB; Tue, 10 Feb 2015 02:33:57 -0600 (CST)
DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com E41E9A02FB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1423557237; bh=8IlyyCqu4BM/vqlcXWzajn+02wYIpXHIuW29/g8MV5Q=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=F8jUpi5Q+eLIsVWrK0762HMwtROcwgGKTZySGFOXnvwSeI5YgEhEHrA5Ud8Bqi+Xo Ozrpm8/xqtf2KA2zwvzRlg3OAgxroAJRRORoPMfOdxbF2XXBOJ6C6Vq1E9MoR2veQt ie2IOTbGtxW9al9JXL48wt9LvOkkcc8OqTna2mvo=
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B172EA02F7; Tue, 10 Feb 2015 02:33:57 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QdxjHFJ6kDHQ; Tue, 10 Feb 2015 02:33:57 -0600 (CST)
Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 823FFA02E5; Tue, 10 Feb 2015 02:33:57 -0600 (CST)
Date: Tue, 10 Feb 2015 02:33:57 -0600 (CST)
From: Franck Martin <franck@peachymango.org>
To: John Levine <johnl@taugh.com>
Message-ID: <1301462137.31775.1423557237433.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!0ab9196df96faaf1ccfa9c1ca3b04ff2afcac412949f030dd06acbb2fb2883bcb83f1ad7e8db8c2d65805f0d4784a5eb!@asav-1.01.com>
References: <20150203023111.14642.qmail@ary.lan> <WM!0ab9196df96faaf1ccfa9c1ca3b04ff2afcac412949f030dd06acbb2fb2883bcb83f1ad7e8db8c2d65805f0d4784a5eb!@asav-1.01.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.101.179]
X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839)
Thread-Topic: interoperability draft for review
Thread-Index: c5jYTlyDrmrugn/LIQehwW2WqitrEg==
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/pHM2awKYFbnUjFQb3c_9lKyvvyg>
Cc: tim@eudaemon.net, dmarc@ietf.org
Subject: Re: [dmarc-ietf] interoperability draft for review
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, 10 Feb 2015 08:34:00 -0000

----- Original Message -----
> From: "John Levine" <johnl@taugh.com>
> To: dmarc@ietf.org
> Cc: tim@eudaemon.net
> Sent: Monday, February 2, 2015 6:31:11 PM
> Subject: Re: [dmarc-ietf] interoperability draft for review
> 
> In addition to other comments:
> 
> Section 3.1.2.3 is just wrong.  EAI specifically does not allow for
> downgrading of messages in transit from UTF-8 headers to ASCII
> headers.  The only place the header downgrade is allowed is when a
> non-EAI MUA picks up mail via POP or IMAP, but that would be long
> after any DMARC tests were applied.  You were probably confused
> because the early experimental version of EAI did allow downgrades in
> transit, but they worked so poorly that we took them out of the
> standards track version.

Yes not in transit, but the downgrade is likely to happen at the source be it the human or the MUA (I have not seen an implementation of such yet and I do have an EAI). Reworded to be clearer.

> 
> One place it might happen is when mail is relayed through a mailing
> list, but that's really the same issue as any other modifications a
> mailing list makes to mail that passes through it.  See RFC 6783.
> 
> In section 3.2.1, there are certainly vanity domains (I have lots of
> them) but I think you're more referring to stable addresses from
> professional associations or alumni associations, e.g., I will always
> be uucp@computer.org regardless of where I get my mail.  Some
> rewording would likely help to clarify what you're talking about, and
> the fact that most of them do not offer MSAs but expect you to use the
> one provided by your current mail system.

ok

> 
> In 4.4.1.1 the main reason to recode is if a message arrives via an
> 8BITMIME channel and leaves via a 7 bit channel so it has to change
> from 8bit to quoted-printable or base64.  Every curent MTA can handle
> 8BITMIME but there are still a fair number of dusty old ones.
> 
Ned spoke about it

> Section 4.4.1.3 is wrong for the same reason that 3.1.2.3 is wrong.
> If you send an EAI message, it'll either be delivered as EAI or
> bounce.  There is some ambiguity about what a DKIM signature on an EAI
> message would look like (is the domain in d= a U-label or A-label) but
> they should not be a big deal to work out.

same as above
> 
> In section 4.5.1, another mailing list workaround is to rewrite the
> From: address into another address with an aligned signature that
> forwards to the original address.  LISTSERV does this by rewriting to
> some random looking address in the list's domain, I do it by appending
> a local domain such as DMARC.FAIL.
> 
Do we really want to create a non existing domain, without standardization? It is a bit the same as the group syntax, it just remove information to assess email reputation. I think this is not cool in these days of serious breaches due to email attacks.


From nobody Tue Feb 10 00:34:15 2015
Return-Path: <franck@peachymango.org>
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 1A25C1A00DB for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 00:34:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level: 
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 VgG8PL484XLP for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 00:33:57 -0800 (PST)
Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB341A0056 for <dmarc@ietf.org>; Tue, 10 Feb 2015 00:33:57 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id ADE0B5641B4; Tue, 10 Feb 2015 02:33:56 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 9306FA02E5; Tue, 10 Feb 2015 02:33:56 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kr4haVRZQOdF; Tue, 10 Feb 2015 02:33:56 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 1C483A02FB; Tue, 10 Feb 2015 02:33:54 -0600 (CST)
DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 1C483A02FB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1423557235; bh=b4PNp4mCjZqZCxSgk7CXjulpSX+YMIAdBNU7UqkQypc=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=dglbn0ffnss0YDMq47M732NNNSmBWx45eauRGgFyXhEmIvceTP/AWetMtQwu/d/ss B+EyV3zL9q3wwvWZXnFoM/eBcdMqI7Jd+4VvwSWk5ToECkXLr13wXYmABbPsJetlMm IoB6b0xKWjhX4Aub4uEIHb9fsuGdYABKk412A4qo=
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E3312A02F7; Tue, 10 Feb 2015 02:33:53 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eWTrflfBdBLf; Tue, 10 Feb 2015 02:33:53 -0600 (CST)
Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 9731EA02E5; Tue, 10 Feb 2015 02:33:53 -0600 (CST)
Date: Tue, 10 Feb 2015 02:33:52 -0600 (CST)
From: Franck Martin <franck@peachymango.org>
To: ned+dmarc@mrochek.com
Message-ID: <1062018335.31774.1423557232665.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!988a9ef1983ebed63b8d744fcc42b2a46a51d47d665644da34da0fa1d4c893fdb8489757ff45032d36d9e21c9ad13869!@asav-3.01.com>
References: <E17F9594-A071-4DBC-B1A7-049CCC382DD7@eudaemon.net> <01PI0N0XDKNA000052@mauve.mrochek.com> <WM!988a9ef1983ebed63b8d744fcc42b2a46a51d47d665644da34da0fa1d4c893fdb8489757ff45032d36d9e21c9ad13869!@asav-3.01.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.1.101.179]
X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839)
Thread-Topic: interoperability draft for review
Thread-Index: NlbTsPvfeSwT2cydw6Mm5328clEi1Q==
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/YioSrikpsC37chOQhx8S5NAcYjw>
Cc: dmarc <dmarc@ietf.org>, Tim Draegen <tim@eudaemon.net>
Subject: Re: [dmarc-ietf] interoperability draft for review
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, 10 Feb 2015 08:34:04 -0000

----- Original Message -----
> From: ned+dmarc@mrochek.com
> To: "Tim Draegen" <tim@eudaemon.net>
> Cc: "dmarc" <dmarc@ietf.org>
> Sent: Sunday, February 1, 2015 5:58:10 PM
> Subject: Re: [dmarc-ietf] interoperability draft for review
>=20
> > Hi all,
>=20
> > Frank, Eliot, and myself have finished up a first cut at the WG=E2=80=
=99s 1st real
> > deliverable:
> > =09=E2=80=A2 Document describing interoperability issues with DMARC and=
 indirect mail
> > =09flows and possible methods for addressing them.
>=20
> > Please review at your convenience and submit comments, feedback, and
> > suggestions for text to this list.  Frank and/or Eliot will be folding =
in
> > edits.  A serious effort to cast issues in the language of RFC 5598 was
> > made.
>=20
> > Find it here:
> > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/
>=20
> > Our aim is to have this document ready for publication by end of Februa=
ry.
>=20
> <chair hat off>
>=20
> A few quick comments:
>=20
> The introduction classifies message transformations as a type of indirect
> mail
> flow. This takes a little getting used to, to say the least. For example,=
 if
> someone's mail always traverses a relay which incorporates boundary filte=
ring
> functionality that breaks DKIM signatures, and this in turn prevents them
> from
> performing DMARC checks, you may have a hard time convincing them that
> there's
> anything "indirect" about the path.
>=20
> Of course it all works if you define "indirect" as anything more complex =
than
> an agent that incorporates a DKIM signer sending directly to the agent th=
at
> verifies the signature. (And even this could involve a transport encoding
> change that breaks a DKIM signature.) I admit there's some temptation to
> define
> things this way - but do we really want to go there?
>=20
> There also really needs to be a distinction made between indirect paths t=
hat
> involve final delivery and subsequent resubmission and those that do not.=
 I
> for
> one don't have much expectation that if I resend a message that's been
> delivered to me without changing the From: field that it will pass muster=
.
> Message that fail because of the involvement of a simple alias are anothe=
r
> matter.
>=20
> The last sentence in section 2.1 doesn't really make sense to me. There i=
s no
> problem with having multiple SPF records point at the same server IP addr=
ess
> or
> addresses, so multiple mail streams are not issue. Of course this doesn't
> make this sort of thing a good idea. Selecting the host name for use in
> HELO/EHLO do that SPF checks will pass, while theoretically possible, is
> entirely contrary to the purpose of the parameter and thus bad operationa=
l
> practice. Indeed, I have to question why this is in the draft.
> Are people actually doing this?

at ESPs or domain hosters, dedicated IP address often comes at a premium, i=
f possible. At google/microsoft/... email domain hosting, you get the googl=
e/microsoft/... hostname not something in your own domain. (if not mistaken=
)

>=20
> Section 2.2 is incorrect in regards to how SPF mismatches on forwarders
> occur.
> Essentially all forwarders change the 5321.HELO/EHLO, but simple alias
> exansion
> usually does not change the 5321.MailFrom. In these cases the issue isn't
> that
> the 5321.MailFrom doesn't match the 5322.From, but rather that the SPF ch=
eck
> may fail because the list of allowed IPs does not include the forwarder.

I think we speak of something else here the alignment, but your point is va=
lid too. Adding some text.

>=20
> Section 2.3 needs considerable expansion, and needs to talk about the
> differences between simple and relaxed canonicalization.

done

>=20
> 3.1.2.1 conflates at least two different meanings of the word encoding.
> Further, only changes to the transport encoding fall under the purview
> of an MTA; charset transcoding is a gateway function and needs to move
> to the proper section for that.

done

>=20
> 3.1.2.2 ismispositioned. An MTA that modifies, adds, or removes content i=
sn't
> just an MTA, it's also performing the function of a gateway, boundary fil=
ter,
> mediator. etc. And once you get into such functions, AS/AV checks are but=
 one
> possible action among many.
>=20
> I guess my suggestion would be to talk about AS/AV checks and message
> modification under boundary filter. That's where RFC 5598 positions such
> things. (I note in passing that a brief mention of AS stuff is already in
> section 3.2.5. Merging this section in there seems like a good idea to me=
.)

merged

>=20
> I also don't see how outright blocking is relevant to the matter at hand.
> Sure
> boundary filters reject or discard messages all the time, but how are suc=
h
> cases relevant to DMARC interoperability? DMARC validation can't fail for=
 a
> message that never made it to the validator.
>=20
> Section 3.1.2.3 "invalide" -> "invalidate"
>=20
> In section 3.1.3, Sieve is in no way limited to messing around with heade=
rs.
> For example, sieve extensions exist that can delete or modify message par=
ts.
>=20
> That said, since Sieve operates on or around the time of final delivery, =
such
> modifications are supposed to be happening at a point past where DMARC ch=
ecks
> have been performed. It's only when messages are reintroduced into the
> transport infrastructure with the same From: field that issues may arise,=
 and
> this needs to be noted.
>=20

done

> What is the first sentence of section 3.2 supposed to mean?

that we stole some text.

>=20
> Section 3.2.3 really needs to talk about why mailing lists perform the
> message
> modifications they typically perform.

done

>=20
> I don't believe the use of X-Original-From is described in any RFC curren=
tly.
> If we're going to talk about it in section 4.3 we need to talk about how
> it's actually used or refer to some place that does.

it is RFC5703

>=20
> The Internet is a big place, and none of us are in a position to fully as=
sess
> the state of play in every nook and cranny out there. As such, I'm very
> reluctant to make statements like "there is very little reason to modify =
the
> encoding of a message". What if there are good reasons to somwhere? Do we
> really want another round of the charset wars in this context?


Like the blue ribbon ASCI footer? :P

In my personal experience when I pointed that an MTA was doing encoding and=
 therefore breaking DKIM, the option was removed, nobody came back to me an=
d said I cannot do that.

toning down the language nevertheless

>=20
> And as for transport encodings, like it or not, the standards say that if
> you're in possession of an 8bit message and the system you're sending it
> to doesn't support 8bitMIME, you either downgrade or bounce. Of course yo=
u
> can argue that this is obsolete, but do we really want to open this
> particular can of worms in this document?

well, in this day and age with security vulnerabilities every week, how far=
 do we have to support legacy mail systems?

>=20
> And on a similar note, try selling what 4.4.1.2 says to a financial
> institution
> that is bound by laws saying what must be and cannot be in the messages i=
t
> emits as well as what's inbound messages destined for employees. I'm sure
> they'll find it amusing.

I think we had in mind the AV that adds "scanned by Great AV, you should bu=
y it".

Can you give some samples of what you have in mind?

I suppose a financial institution would add a disclaimer on all emails, but=
 before DKIM. Also I don't think they would operate a mailing list or forwa=
rder lightly...


From nobody Tue Feb 10 00:41:04 2015
Return-Path: <franck@peachymango.org>
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 85C191A011D for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 00:41:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 IhfXEiv3oozE for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 00:41:00 -0800 (PST)
Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 927C51A0056 for <dmarc@ietf.org>; Tue, 10 Feb 2015 00:41:00 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 3EF0556402A for <dmarc@ietf.org>; Tue, 10 Feb 2015 02:41:00 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3B72A601D5 for <dmarc@ietf.org>; Tue, 10 Feb 2015 02:41:00 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RcuXHNkmC5r for <dmarc@ietf.org>; Tue, 10 Feb 2015 02:41:00 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 10EE6601FF for <dmarc@ietf.org>; Tue, 10 Feb 2015 02:41:00 -0600 (CST)
DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 10EE6601FF
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1423557660; bh=2YlpRtxQqpSBBkTJxoo5HHoy+6mvKOfn5+FrqMMLIlo=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=iOJHkCe4qilCwyHLaTGuNhSwkQt3I5Y8/jM9DDFni8Av5rMX7kz0m5MpJ1ZZpWRu7 E19ZC0edylSCsbUbhqdVB7EL4wyaxzaPG489w6Ffbj2QCZkxlDrseGPn3mQBP+0XE8 o7vj0NQkU9N7yqQDPQfTy0EAZkSLKTPHfocVsysw=
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id EE999601F5 for <dmarc@ietf.org>; Tue, 10 Feb 2015 02:40:59 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ktwvTlSVA2Xo for <dmarc@ietf.org>; Tue, 10 Feb 2015 02:40:59 -0600 (CST)
Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id D7347601D5 for <dmarc@ietf.org>; Tue, 10 Feb 2015 02:40:59 -0600 (CST)
Date: Tue, 10 Feb 2015 02:40:59 -0600 (CST)
From: Franck Martin <franck@peachymango.org>
To: dmarc <dmarc@ietf.org>
Message-ID: <960999840.31781.1423557659690.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!1235b90a1389d97761db3a8c98735c462a0adf9577bee7518c9ac8db136dfd34292b7aa661d1f386943cd364b3ef98d2!@asav-2.01.com>
References: <E17F9594-A071-4DBC-B1A7-049CCC382DD7@eudaemon.net> <01PI0N0XDKNA000052@mauve.mrochek.com> <WM!988a9ef1983ebed63b8d744fcc42b2a46a51d47d665644da34da0fa1d4c893fdb8489757ff45032d36d9e21c9ad13869!@asav-3.01.com> <1062018335.31774.1423557232665.JavaMail.zimbra@peachymango.org> <WM!1235b90a1389d97761db3a8c98735c462a0adf9577bee7518c9ac8db136dfd34292b7aa661d1f386943cd364b3ef98d2!@asav-2.01.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.101.179]
X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839)
Thread-Topic: interoperability draft for review
Thread-Index: NlbTsPvfeSwT2cydw6Mm5328clEi1f16l5hD
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/GetjJjTf9R6TppI7dp3NmNy7Pkw>
Subject: Re: [dmarc-ietf] interoperability draft for review
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, 10 Feb 2015 08:41:02 -0000

Latest diff is at https://github.com/dmarc-ietf/id/commit/d7b1a401f3c171c27df926bd6a0c5a2ba06eec9b

May be the xml diff (at then end) is best to read. Github is not very nice with RFC formatting...


From nobody Tue Feb 10 00:52:23 2015
Return-Path: <johnl@taugh.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 228211A0404 for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 00:52:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.537
X-Spam-Level: 
X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=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 Jhbx3kfPeYxV for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 00:52:19 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758381A1A2C for <dmarc@ietf.org>; Tue, 10 Feb 2015 00:52:19 -0800 (PST)
Received: (qmail 82387 invoked from network); 10 Feb 2015 08:52:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=141d2.54d9c6c2.k1502; bh=dw8DJFOfU0zoTMbUE4oWhoNSjBPWyqFfOOLaVgWiHYg=; b=j76YwrygvFuQ8e55mza6KrMagLCrAkCNN8Fmxs1pRgGFRVW6b68aQX1ZT4wzUVRvQOsLb+/AuZjW/iFM7gGpTKdbgI0v6JL4cvx88AhTpGNleRSI3va0h886eNLv/ln6nmU6F784W9t8ep6Ov2g7H//+fb8TMdreDhLUNwnUaXz5DaJUofzpkrwdZrrzTeoEKt9akGNNLnuDw+YwPED51FuyqNeVuY7kf6Parno6qEVSGu4ltoYAjl522HRodmgU
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=141d2.54d9c6c2.k1502; bh=dw8DJFOfU0zoTMbUE4oWhoNSjBPWyqFfOOLaVgWiHYg=; b=B8bMdlAjYAgO/41RjfxyvmJucWRf37JxdFMb3Sz7qJQ/h8Mblhjg4/fAEmSY8HIehpSABUJbvQoaE/WMsY4onQ/og8e6BFNeiThz2nlSM6W9P7YLXmyVL0OskeaTz+En7c4uXe04/kos+4HsMFpdOv79jT3nKBOEyY1nxNBdQau/NIdhJ7W6wSuO01EKotu8nCc1WYTOuTCR83Jh8vnGMB58WKIw2PV4ct9ii9BKtGvQu+uvO8w5zKeQMIMMuudX
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 10 Feb 2015 08:52:17 -0000
Date: 10 Feb 2015 16:52:13 +0800
Message-ID: <alpine.OSX.2.11.1502101645290.90420@ary.local>
From: "John R Levine" <johnl@taugh.com>
To: "Franck Martin" <franck@peachymango.org>
In-Reply-To: <1301462137.31775.1423557237433.JavaMail.zimbra@peachymango.org>
References: <20150203023111.14642.qmail@ary.lan> <WM!0ab9196df96faaf1ccfa9c1ca3b04ff2afcac412949f030dd06acbb2fb2883bcb83f1ad7e8db8c2d65805f0d4784a5eb!@asav-1.01.com> <1301462137.31775.1423557237433.JavaMail.zimbra@peachymango.org>
User-Agent: Alpine 2.11 (OSX 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/3rniNVg6rjhrx4GZy-o920dQ5sA>
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] interoperability draft for review
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, 10 Feb 2015 08:52:21 -0000

>> Section 3.1.2.3 is just wrong.  EAI specifically does not allow for
>> downgrading of messages in transit from UTF-8 headers to ASCII
>> headers.  ...

> Yes not in transit, but the downgrade is likely to happen at the source 
> be it the human or the MUA (I have not seen an implementation of such 
> yet and I do have an EAI). Reworded to be clearer.

That makes no sense.  If you send mail to a different address, that's what 
will get signed and it has no DMARC issues.

>> In section 4.5.1, another mailing list workaround is to rewrite the
>> From: address into another address with an aligned signature that
>> forwards to the original address.  LISTSERV does this by rewriting to
>> some random looking address in the list's domain, I do it by appending
>> a local domain such as DMARC.FAIL.

> Do we really want to create a non existing domain, without 
> standardization? It is a bit the same as the group syntax, it just 
> remove information to assess email reputation. I think this is not cool 
> in these days of serious breaches due to email attacks.

Again, that makes no sense.  I'm not aware of anyone advocating a "non 
existing domain."  Could you explain what you mean here?

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Tue Feb 10 09:44:01 2015
Return-Path: <superuser@gmail.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 38F7F1A1A9E for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 09:43:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 utdEZKU0tHFP for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 09:43:55 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 A58FA1A1A5B for <dmarc@ietf.org>; Tue, 10 Feb 2015 09:43:53 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id hm9so14731598wib.1 for <dmarc@ietf.org>; Tue, 10 Feb 2015 09:43:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oBEwkjQnztsZKuaMf+kE6d/btIhhJgNxZ6AnaE/I4Vg=; b=NcdTAzNWt1NGFO+jwBJMR1rtMHJHPVAR0BXsJVYmRnOSkpJP9c6kBfzr7kuXi5ndiR ZGS6+URyT3Lx1LpN/u7KuuwZkivUrl5S0RCzrkWe5Qgs9TJHURe0m91YJvwaW4QRbhaj sHdlPJdTagJ1lAg9KG+KFHwYNsl6arj7I8qOblE6fNNYZwS+NYeD3y4trGSGxH142GgJ 0pwqYquej/3sfK080ND8RytBBgNucufFQBDXoHjrtarx4PsjTdMNNFnQOu8AAhOK3WGW nb3MzcZIyoGRRtM3K5UeStZsx+VaQkBik+x+gMnxOi47wYNIfrMJqxrFDSQ1IeS86YqI xQiQ==
MIME-Version: 1.0
X-Received: by 10.194.185.68 with SMTP id fa4mr53939311wjc.111.1423590232322;  Tue, 10 Feb 2015 09:43:52 -0800 (PST)
Received: by 10.27.179.146 with HTTP; Tue, 10 Feb 2015 09:43:52 -0800 (PST)
In-Reply-To: <1062018335.31774.1423557232665.JavaMail.zimbra@peachymango.org>
References: <E17F9594-A071-4DBC-B1A7-049CCC382DD7@eudaemon.net> <01PI0N0XDKNA000052@mauve.mrochek.com> <WM!988a9ef1983ebed63b8d744fcc42b2a46a51d47d665644da34da0fa1d4c893fdb8489757ff45032d36d9e21c9ad13869!@asav-3.01.com> <1062018335.31774.1423557232665.JavaMail.zimbra@peachymango.org>
Date: Tue, 10 Feb 2015 09:43:52 -0800
Message-ID: <CAL0qLwbRceiewRtaYLGE2wYqRMr=XYosK1zs_o7fhFG-=OJGJA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Franck Martin <franck@peachymango.org>
Content-Type: multipart/alternative; boundary=047d7bacb11e1a7893050ebf6ec3
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/v5GQol_CRiWFEvPAhcnIOcvneX0>
Cc: Tim Draegen <tim@eudaemon.net>, dmarc <dmarc@ietf.org>, ned+dmarc@mrochek.com
Subject: Re: [dmarc-ietf] interoperability draft for review
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, 10 Feb 2015 17:43:57 -0000

--047d7bacb11e1a7893050ebf6ec3
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 10, 2015 at 12:33 AM, Franck Martin <franck@peachymango.org>
wrote:

> > I don't believe the use of X-Original-From is described in any RFC
> currently.
> > If we're going to talk about it in section 4.3 we need to talk about how
> > it's actually used or refer to some place that does.
>
> it is RFC5703
>

That's Original-From, so I guess just mention that the X- version was the
pre-standardization name and might still be in use in some places.

Aside: I'm surprised that RFC5703 doesn't include the registration template
required by RFC3864.

-MSK

--047d7bacb11e1a7893050ebf6ec3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Feb 10, 2015 at 12:33 AM, Franck Martin <span dir=
=3D"ltr">&lt;<a href=3D"mailto:franck@peachymango.org" target=3D"_blank">fr=
anck@peachymango.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&g=
t; I don&#39;t believe the use of X-Original-From is described in any RFC c=
urrently.<br>
&gt; If we&#39;re going to talk about it in section 4.3 we need to talk abo=
ut how<br>
&gt; it&#39;s actually used or refer to some place that does.<br>
<br>
</span>it is RFC5703<br></blockquote><div><br></div><div>That&#39;s Origina=
l-From, so I guess just mention that the X- version was the pre-standardiza=
tion name and might still be in use in some places.<br><br>Aside: I&#39;m s=
urprised that RFC5703 doesn&#39;t include the registration template require=
d by RFC3864.<br><br></div><div>-MSK<br></div></div></div></div>

--047d7bacb11e1a7893050ebf6ec3--


From nobody Tue Feb 10 11:03:20 2015
Return-Path: <franck@peachymango.org>
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 C03771A1B5A for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 11:03:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 hqhkHidgu9BJ for <dmarc@ietfa.amsl.com>; Tue, 10 Feb 2015 11:03:15 -0800 (PST)
Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id E3B381A9068 for <dmarc@ietf.org>; Tue, 10 Feb 2015 11:03:00 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 7355E56419B; Tue, 10 Feb 2015 13:03:00 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6A8D760247; Tue, 10 Feb 2015 13:03:00 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU3S04qLIij1; Tue, 10 Feb 2015 13:02:58 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 213B860274; Tue, 10 Feb 2015 13:02:58 -0600 (CST)
DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 213B860274
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1423594978; bh=sfQO5ifSBJbJQjS1N5YshO/6/3+l6xhtAez5pRSaBCI=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=QqQQbwJO2GTw8Ssc1lB2JLXuoCSghH1SwoB8dalg9Hbl/MX7HdB4gnfKIYAZil/Ej r1L8YOHpvwMFKF+F9x+aQ27L14fDY812ri00N2uIKdHIzTfP133sPp8Seru5Xs90Lj qyAgcrVRQsAx5CVxPWbFaAxOt4DI4YV9HQhST7Kg=
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 114E66026B; Tue, 10 Feb 2015 13:02:58 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Rwm9XdvwuTjt; Tue, 10 Feb 2015 13:02:57 -0600 (CST)
Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id E82A660247; Tue, 10 Feb 2015 13:02:57 -0600 (CST)
Date: Tue, 10 Feb 2015 13:02:57 -0600 (CST)
From: Franck Martin <franck@peachymango.org>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Message-ID: <751783280.47157.1423594977717.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!1a2adf6fd1927d0251c1b637982014ecdf9ec3ddf68fb82354d710610e022de7d3550da08ea2d122f1eccf851fc57b63!@asav-3.01.com>
References: <E17F9594-A071-4DBC-B1A7-049CCC382DD7@eudaemon.net> <01PI0N0XDKNA000052@mauve.mrochek.com> <WM!988a9ef1983ebed63b8d744fcc42b2a46a51d47d665644da34da0fa1d4c893fdb8489757ff45032d36d9e21c9ad13869!@asav-3.01.com> <1062018335.31774.1423557232665.JavaMail.zimbra@peachymango.org> <CAL0qLwbRceiewRtaYLGE2wYqRMr=XYosK1zs_o7fhFG-=OJGJA@mail.gmail.com> <WM!1a2adf6fd1927d0251c1b637982014ecdf9ec3ddf68fb82354d710610e022de7d3550da08ea2d122f1eccf851fc57b63!@asav-3.01.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_47156_943266262.1423594977717"
X-Originating-IP: [10.1.101.178]
X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839)
Thread-Topic: interoperability draft for review
Thread-Index: csYzgLxzqoWIGXvbJjFuYkkHbXNo1w==
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/T-k-Sl6eHojINQF-eDW-uWp5Mvc>
Cc: dmarc <dmarc@ietf.org>, Tim Draegen <tim@eudaemon.net>, ned+dmarc@mrochek.com
Subject: Re: [dmarc-ietf] interoperability draft for review
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, 10 Feb 2015 19:03:17 -0000

------=_Part_47156_943266262.1423594977717
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

----- Original Message -----

> From: "Murray S. Kucherawy" <superuser@gmail.com>
> To: "Franck Martin" <franck@peachymango.org>
> Cc: "Tim Draegen" <tim@eudaemon.net>, "dmarc" <dmarc@ietf.org>,
> ned+dmarc@mrochek.com
> Sent: Tuesday, February 10, 2015 9:43:52 AM
> Subject: Re: [dmarc-ietf] interoperability draft for review

> On Tue, Feb 10, 2015 at 12:33 AM, Franck Martin < franck@peachymango.org >
> wrote:

> > > I don't believe the use of X-Original-From is described in any RFC
> > > currently.
> 
> > > If we're going to talk about it in section 4.3 we need to talk about how
> 
> > > it's actually used or refer to some place that does.
> 

> > it is RFC5703
> 

> That's Original-From, so I guess just mention that the X- version was the
> pre-standardization name and might still be in use in some places.

I'll check the text but there is something like this. 

> Aside: I'm surprised that RFC5703 doesn't include the registration template
> required by RFC3864.

It is listed here: https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers 

------=_Part_47156_943266262.1423594977717
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"font-family: arial,helvetica,sans-serif; font-siz=
e: 12pt; color: #000000"><hr id=3D"zwchr"><blockquote style=3D"border-left:=
2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:n=
ormal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sa=
ns-serif;font-size:12pt;"><b>From: </b>"Murray S. Kucherawy" &lt;superuser@=
gmail.com&gt;<br><b>To: </b>"Franck Martin" &lt;franck@peachymango.org&gt;<=
br><b>Cc: </b>"Tim Draegen" &lt;tim@eudaemon.net&gt;, "dmarc" &lt;dmarc@iet=
f.org&gt;, ned+dmarc@mrochek.com<br><b>Sent: </b>Tuesday, February 10, 2015=
 9:43:52 AM<br><b>Subject: </b>Re: [dmarc-ietf] interoperability draft for =
review<br><div><br></div><div dir=3D"ltr">On Tue, Feb 10, 2015 at 12:33 AM,=
 Franck Martin <span dir=3D"ltr">&lt;<a href=3D"mailto:franck@peachymango.o=
rg" target=3D"_blank">franck@peachymango.org</a>&gt;</span> wrote:<br><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><span class=3D"">&gt; I don't believe the use of X-Original-From is de=
scribed in any RFC currently.<br>
&gt; If we're going to talk about it in section 4.3 we need to talk about h=
ow<br>
&gt; it's actually used or refer to some place that does.<br>
<br>
</span>it is RFC5703<br></blockquote><div><br></div><div>That's Original-Fr=
om, so I guess just mention that the X- version was the pre-standardization=
 name and might still be in use in some places.</div></div></div></div></bl=
ockquote><div>I'll check the text but there is something like this.<br></di=
v><blockquote style=3D"border-left:2px solid #1010FF;margin-left:5px;paddin=
g-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:=
none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div><br></di=
v>Aside: I'm surprised that RFC5703 doesn't include the registration templa=
te required by RFC3864.<br></div></div></div></div></blockquote><div>It is =
listed here: https://www.iana.org/assignments/message-headers/message-heade=
rs.xhtml#perm-headers<br></div><div><br></div></div></body></html>
------=_Part_47156_943266262.1423594977717--