IETF Logo Mail Archive

Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec)

Franck Martin <fmartin@linkedin.com> Sat, 06 July 2013 08:14 UTC

Return-Path: <prvs=892313021=fmartin@linkedin.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C010D21F99CD for <dmarc@ietfa.amsl.com>; Sat, 6 Jul 2013 01:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.179
X-Spam-Level:
X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t6Skv-goCxJ for <dmarc@ietfa.amsl.com>; Sat, 6 Jul 2013 01:14:25 -0700 (PDT)
Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id C251221F8825 for <dmarc@ietf.org>; Sat, 6 Jul 2013 01:14:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1373098465; x=1404634465; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8zPHK7bGnr9W+lv8nQGKClol/LyjswsXEcsLjV/1F4Q=; b=Bs1EplYhtI+TjSfz63gFPKnv1Lr35O3IYLgZi9hxNZ20eRklIzmYbX27 MXWeeWgqPQEbF/OS77NUJ9TbmDI59jNHfxKu2MTg82aU3GNpBA0xDM26r OtXHYRdc2mnyopxeoroiYxUcUkZKi1qem5B25SYZGe9b+Xzu4dBeDlzqu w=;
X-IronPort-AV: E=Sophos;i="4.87,1008,1363158000"; d="scan'208";a="54864665"
Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Sat, 6 Jul 2013 01:14:09 -0700
From: Franck Martin <fmartin@linkedin.com>
To: SM <sm@resistor.net>
Thread-Topic: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec)
Thread-Index: AQHOebVpplPe5sX1+kqIOKlzOpGV35lXw5CA
Date: Sat, 06 Jul 2013 08:14:08 +0000
Message-ID: <77426B543150464AA3F30DF1A91365DE53A77D0C@ESV4-MBX02.linkedin.biz>
References: <519B47DC.20008@cisco.com> <CAL0qLwYZOp1FNVSAmzXYkZG_O3Yv+EQrAKKLpRiE5svcOMamTA@mail.gmail.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <CAL0qLwYT6BS=HGLX1-u80aqaJWefipT5tcg5Ut_549y4rOej9g@mail.gmail.com> <6.2.5.6.2.20130705091238.0be05400@resistor.net>
In-Reply-To: <6.2.5.6.2.20130705091238.0be05400@resistor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.18.46.252]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8AB2391EFE6B4740AE386A06290D2BC3@linkedin.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<dmarc@ietf.org>" <dmarc@ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>, Eliot Lear <lear@cisco.com>
Subject: Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 06 Jul 2013 08:14:31 -0000

On Jul 5, 2013, at 11:05 AM, SM <sm@resistor.net> wrote:

> Hi Murray,
> At 01:34 05-07-2013, Murray S. Kucherawy wrote:
> 
>> In Section 15.8:
>> 
>>  "Many systems are able to scan the SMTP reply text to determine the
>>   nature of the rejection, thus providing a machine-detectable reason
>>   for rejection allows automated sorting of rejection causes so they
>>   can be properly addressed."
>> 
>> I don't think that it is a good idea to discuss about that as part of a protocol specification.
>> 
>> Why?
> 
> The draft getting into heuristics.  This takes you away from protocol specification to things people do because "it works for them".  The straight answer is that I don't really know as it is a matter of whether the heuristics not working is really an edge case or something to seriously consider.
> 
There is not much standardization of response codes from MTAs. There are extended response codes, but then you cannot deduct from them, if the problem is due to DMARC or other security policies. If I'm not mistaken, take the case of Facebook, refusing an email because you are not a friend of the recipient... Or the same error code could indicate SPF or DKIM or other protocol failure... Having the word DMARC in the text of the error message gives a lot of information for debugging a specific email. Consider also the error could be generated after a forwarder is trying to send an email... Without a proper hint of what is the reason of the reject it is very hard to know what really happened for a specific email.

v2.14.0 | Report a Bug | By Email