Re: [Asrg] "Affiliation"

Alessandro Vesely <vesely@tana.it> Tue, 23 June 2009 06:01 UTC

Return-Path: <vesely@tana.it>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5A228C1BE for <asrg@core3.amsl.com>; Mon, 22 Jun 2009 23:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level:
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6h4a9IxHAQG for <asrg@core3.amsl.com>; Mon, 22 Jun 2009 23:01:35 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id E6F363A6E3F for <asrg@irtf.org>; Mon, 22 Jun 2009 23:01:34 -0700 (PDT)
Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 23 Jun 2009 08:01:48 +0200 id 00000000005DC031.000000004A406FCC.00003783
Message-ID: <4A406FE2.1020800@tana.it>
Date: Tue, 23 Jun 2009 08:02:10 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <C8F0F10E-E1A4-4D25-AF20-31E3F0DB68DF@mail-abuse.org> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <FED77586-8800-4BA6-99EA-30A1D9C089B6@mail-abuse.org> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <B5252B96-F0AB-4D4A-A0DA-8314AA8E038F@mail-abuse.org> <4A3D366E.2020304@tana.it> <BD23C7D8-9E95-45CA-93F3-80F9726F889C@mail-abuse.org> <4A3F63BE.1030303@tana.it> <20090622175230.GA57980@verdi>
In-Reply-To: <20090622175230.GA57980@verdi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] "Affiliation"
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Tue, 23 Jun 2009 06:01:36 -0000

John Leslie wrote:
>> [CSV] didn't help retrieving the responsible domain, though.
> 
>    CSV intended to use the EHLO string _as_ the responsible domain, even
> though it might be one of several subdomains under a single management.

Large organizations are often partitioned into (proper) subdomains, 
more or less independent from one another. OTOH single mailout hosts 
names may also be considered a (degenerate) subdomain.

>> Furthermore, it didn't do ranges, thus making it laborious to deny
>> sending to a bunch of hosts.
> 
>    I agree it didn't "do ranges", since it seemed appropriate to allow
> separate reputations for separate EHLO names.

Interesting. However, it is useless to separate reputation of 
different EHLO names belonging to an array of mailout hosts where a 
specific one is chosen based on traffic optimization and may even 
change on retries.

>> AFAIK, all discussions eventually reach the conclusion that the 
>> receiving server does not know which domain administers the client 
>> MTA.
> 
>    CSV was intended to address exactly that problem. We felt that the
> vast majority of domains _could_ get by with half a dozen IP addresses
> returned by a A)ddress record, and that for those that couldn't, the
> ability to have separable reputations was an _advantage_. For a
> reputation service, more than one reputation record per domain actively
> sending (reasonable) email seemed simple enough.

OTOH, it is more difficult to track subdomains. A spammer can easily 
add new names at incredible rates. What about DKIM's distinction 
between domain (d) and identity (i)? As clever as DKIM may bee, I 
never noticed mail messages altered in transit, and would be curious 
to know how many filter look at its signature headers for the sole 
purpose of extracting the affiliation.

>    I agree that "affiliation" was not the best choice of words in
> draft-ietf-marid-csv-csa-02. "Affiliation" should be multi-valued,
> with an individual sending MTA able to affiliate with multiple
> entities.
> 
>    OTOH, "identity" isn't quite right either. Though it is the term
> used in RFC 2821, that RFC in no sense requires that the "identity"
> identify a single server.

John K. has been very clear on that point. Section 2.3.5 says

  The domain name given in the EHLO command MUST be either a primary
  host name (a domain name that resolves to an address RR) or, if
  the host has no name, an address literal, as described in
  Section 4.1.3 and discussed further in the EHLO discussion of
  Section 4.1.4.

It is true that section 4.1.4 specifies that giving the affiliation 
instead of the host name cannot be punished by rejecting messages. 
However, that wording obviously implies that no reliable affiliation 
information can be derived from the EHLO name. John himself 
suggested to use VHLO if affiliation is required. In his words

    Although I'd predict that you'd have trouble
  getting it off the ground, another possibility would be to
  propose to replace EHLO with a validated-hello command, VHLO,
  which would be just like EHLO except for support for a different
  argument architecture.
[http://www.imc.org/ietf-smtp/mail-archive/msg05444.html]

>> Declaring the affiliation is VHLO's raison d'etre.
> 
>    Hmm... I still think "affiliation" deserves to be multi-valued...

In what sense?

In the vhlo draft[1] I define two domains compatible if they share 
at least one primary mail exchanger. Would that be a 
multi-affiliation example?
[1] http://tools.ietf.org/html/draft-vesely-vhlo