Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly

Alessandro Vesely <vesely@tana.it> Tue, 23 April 2013 16:17 UTC

Return-Path: <vesely@tana.it>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82FA21F96F1 for <spfbis@ietfa.amsl.com>; Tue, 23 Apr 2013 09:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.419
X-Spam-Level:
X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, 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 rQXOMB9DKaSV for <spfbis@ietfa.amsl.com>; Tue, 23 Apr 2013 09:17:10 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0774F21F96F4 for <spfbis@ietf.org>; Tue, 23 Apr 2013 09:17:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366733829; bh=t4JaKq+vi6pLAHONKtq4s7KXPE+uXQQPnl7XrkIK+tE=; l=1110; h=Date:From:To:References:In-Reply-To; b=N/9IgA62H8SnDoDM7PCuwf/FNz3l+xZ//Gog86jnc7RrTD881soM0kt5mP1uV10/J MAM0duEeoKeBd9QdqrvWpGxigW8/9/3O0TBF+4Pz/rwFe/FU4emfSzjhVPAwmGDz3W bhH3QqCAnD0BbXuHCmAoj1VdEwsqqiy7ss8S+i0Q=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 23 Apr 2013 18:17:08 +0200 id 00000000005DC039.000000005176B404.00003501
Message-ID: <5176B405.3010109@tana.it>
Date: Tue, 23 Apr 2013 18:17:09 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: spfbis@ietf.org
References: <51726641.7070606@tana.it> <CAL0qLwY=3ePi+z=pWA=bpnAt5wpzGTZJXNCsj9gsZYO8ybY=yA@mail.gmail.com> <51763F51.3020608@tana.it> <1478526.K9TjTEXC2I@scott-latitude-e6320>
In-Reply-To: <1478526.K9TjTEXC2I@scott-latitude-e6320>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spfbis>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Apr 2013 16:17:10 -0000

On Tue 23/Apr/2013 11:52:42 +0200 Scott Kitterman wrote:
> On Tuesday, April 23, 2013 09:59:13 AM Alessandro Vesely wrote:
>> 
>> OLD:
>>  [...] Typically, such checks are done by a receiving MTA,
>>        but can be performed elsewhere in the mail processing chain
>>        so long as the required information is available and reliable.
>>  [...]
>> 
>> _Note_ that I'm not proposing that change.  I'm asking if a change
>> like that would clear this issue.
> 
> I don't see where it helps and it loses the point about doing the check in the 
> MTA being better than post-processing, which I think is important, so -1 from 
> me.

Yes, I left it off because it has nothing to do with the rest of the
definitions.  I agree it is an important point, but it is covered in
Section 2.5 "Location of Checks", not Section 2.4.

The issue here is that it is not crystal clear what are the SPF
results.  The introduction of the terms primary/secondary is probably
bad.  However, where do we say that the following line is wrong:

   Authentication-Result: spf=pass
      smtp.mailfrom=postmaster@helo-name.example.com;
?