IETF Logo Mail Archive

Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-00

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 16 May 2013 23:54 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E32F11E80A3 for <apps-discuss@ietfa.amsl.com>; Thu, 16 May 2013 16:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.966
X-Spam-Level:
X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 BMajmTFIbH5G for <apps-discuss@ietfa.amsl.com>; Thu, 16 May 2013 16:54:23 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1EC21F8616 for <apps-discuss@ietf.org>; Thu, 16 May 2013 16:54:22 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id p57so1788443wes.32 for <apps-discuss@ietf.org>; Thu, 16 May 2013 16:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rMFV0odB9nsrPIm/nQDJNeEveVT9c8AtRVoeHjCgdXw=; b=MbdEHIpnV8d3HPk35k1UbO2p3NIPNALaFHcwqGwGvkuMztmZJKHji0ArUzjq3G+YEk jHLkh/zTIuG4aAPXtlHuKNCbvinjYdgWImZHneJ7hR+7XdIBsEunZbiiJIr3LyiDvzIS 9n6o4M7tQLGv+ZX/wL3cz5Fr0xiFvgUTQv0Rn5KMFKFI80r/BP3Otpr7dDlU4AGUGN8c Jhh0e+6Y4+atRRTCWGidbl7sZsY103JoWvfQYUA7wB55UE6P/GmsFWF/t/mhjNcDCyZl jkKi2XT39gCsn7bIrFeOpReK+dDpGLeXzHxAdxddm+j3hKmLMGMkCg6yePCSQLp/nhh5 d8YA==
MIME-Version: 1.0
X-Received: by 10.180.82.74 with SMTP id g10mr29356220wiy.10.1368748461997; Thu, 16 May 2013 16:54:21 -0700 (PDT)
Received: by 10.180.14.34 with HTTP; Thu, 16 May 2013 16:54:21 -0700 (PDT)
In-Reply-To: <5194F9A7.8090003@tana.it>
References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <51923CFB.8090702@isode.com> <CAL0qLwbF3CUfChe9C2yASW_FaOtEQwVA7+vyrU2OKpXbdXzZyw@mail.gmail.com> <67D63FBF-D54E-4C99-9A5C-F74FDD635226@isode.com> <CAL0qLwYWfUcBA7UkQFPuxxQGbM3C0wR58jysaTS5ynALSjeQBA@mail.gmail.com> <5194DE26.1000702@tana.it> <CAL0qLwbHKgDE913UfXmG7RJ+OQX5Pm9FdpKrAh35W-c=UDYF6A@mail.gmail.com> <5194F9A7.8090003@tana.it>
Date: Thu, 16 May 2013 16:54:21 -0700
Message-ID: <CAL0qLwbHy2wNd2BxkNj40Wrr_f3gGZKFcMmi2gn_ss8cMAMyfg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Content-Type: multipart/alternative; boundary="f46d04426742dd483b04dcde9575"
Cc: Sam Varshavchik <mrsam@courier-mta.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 May 2013 23:54:24 -0000

On Thu, May 16, 2013 at 8:22 AM, Alessandro Vesely <vesely@tana.it> wrote:

> That's not a client IP, but the return value of the lookup.  Passing
> that value to downstream filters is the whole point of adding this
> header field, otherwise it would have to be looked up again.  Details
> such as DKIM's key length, IMHO, are often in a comment because they
> are of minor importance, not because they are not a visible part of
> the message.)
>
> The policy.txt is important as it contains a domain name.  Albeit A-R
> is not intended to be restricted to domain-based authentication,
> that's by far the most common case, a granularity that was settled
> many years ago.  By indicating a "somewhat responsible" entity, the
> method is semantically consistent with that strategy.
>
>
What does the reply encode that downstream agents need?  If I know that, I
can suggest something more in line with how A-R was designed to operate.

v2.29.0 | Report a Bug | By Email | System Status