Re: [Asrg] SPF's helo identity as a reporting target

Alessandro Vesely <vesely@tana.it> Sun, 13 May 2012 17:21 UTC

Return-Path: <vesely@tana.it>
X-Original-To: asrg@ietfa.amsl.com
Delivered-To: asrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51AB21F854B for <asrg@ietfa.amsl.com>; Sun, 13 May 2012 10:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.597
X-Spam-Level:
X-Spam-Status: No, score=-4.597 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 H0I0C1JN6S7P for <asrg@ietfa.amsl.com>; Sun, 13 May 2012 10:21:47 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A13AE21F8546 for <asrg@irtf.org>; Sun, 13 May 2012 10:21:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1336929704; bh=tKh6ojeda06CU/YkEgZ1MF6RmfYatepOLEOfrCPUyqs=; l=1735; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OAeCwxyvmzPMlu80ahzNqktGsXF5yOicy7yo9WqknERd289PR/PoomjxtZ6XCPCyd sfJwY72go5nlr0wOnOIqrNSaKjV52cmD4n1ziOZ0LdaekOMcURgGSTe6XDzR9mAjJR GIw50PFeX4qCxiT7gcgonQzhhvf+Do1VX14S5k48=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 13 May 2012 19:21:44 +0200 id 00000000005DC035.000000004FAFEDA8.00000C1A
Message-ID: <4FAFEDA8.4090009@tana.it>
Date: Sun, 13 May 2012 19:21:44 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: asrg@irtf.org
References: <4FA8FBCA.3050904@tana.it> <4FAE187B.9030902@tana.it> <4FAEA20F.8090302@mustelids.ca> <4FAF85D0.8050305@tana.it> <4FAFD34F.6010301@mustelids.ca>
In-Reply-To: <4FAFD34F.6010301@mustelids.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] SPF's helo identity as a reporting target
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 May 2012 17:21:47 -0000

On Sun 13/May/2012 18:59:23 +0200 Chris Lewis wrote:
> On 12-05-13 05:58 AM, Alessandro Vesely wrote:
>> On Sun 13/May/2012 11:07:45 +0200 Chris Lewis wrote:
>>>
>>> It would be nice if it could be made usable.
>>>
>>> This would tend to make a large organization having all of their servers
>>> helo exactly the same way, which flies in the face of industry BCP (eg:
>>> MAAWG), and even if it wasn't specifically RFC5321-illegal, clearly
>>> violates its intent.
>> 
>> I see nothing wrong if an organization uses the same helo name for all
>> its mailouts.  A helo name does not have to be a label of any DNS
>> record. 
> 
> Uh what?
> 
> RFC5321:
> 
> Section 4.1.1.1:
> 
>    These commands are used to identify the SMTP client to the SMTP
>    server.  The argument clause contains the fully-qualified domain name
>    of the SMTP client, if one is available.

This has been discussed so many times that we don't need to do it once
more.  For one (John Klensin on Jan 2009):

  The 1123-imposed requirement (carried forward into Section 4.1.4
  Paragraph 6 of 5321) that messages not be rejected on the basis
  of a validation failure with the EHLO argument would presumably
  remain even if we deprecated 821 and client use of HELO.
  http://www.imc.org/ietf-smtp/mail-archive/msg05420.html

> Yeah, I suppose you could make all your outbounds have the same name (up
> to whatever limit DNS imposes), but clearly this violates the intent.
> 
> And it's also very explicitly counter to industry practises/BCP.

I'd agree that violating intents and/or practices is not a good start.
That seems to imply that it is necessary to use scripts to keep helo
names, IP addresses, and SPF in sync.  Would that be worth?