Subject: [domainrep] email vocabulary / draft-ietf-repute-email-identifiers-02

From: Dave Crocker <[email-masked]>
Date: Wed, 28 Mar 2012 07:30:53 +0200

draft-ietf-repute-email-identifiers-02

Just to add some grist, possibly for the meeting...

> IDENTITY:  A token indicating the source of the identifier; that is,
>       where the subject identifier was found in the message.  This MUST
>       be one of:

Is there any utility in defining RFC5321.HELO ?

Same question for RFC5321.Sender...

>    RATE:  A token that recommends an overall message acceptance rate for
>       the subject domain.  This is expected to be a value tailored to
>       the requesting agent; for example, the reputation service would
>       use this to indicate that, based on the data reported by the
>       requesting agent, the service recommends a particular message
>       limit for that agent.  The value is an unsigned decimal value.

"tailored to the requesting agent" cooupled with "unsigned decimal value" 
essentially means there is no standardization to this.  Having a standardized 
label without a standardized meaning associated to it -- where 'meaning' is in 
the definition of the value -- isn't really standardization.

>    A reply that does not contain the IDENTITY or SOURCES extensions is
>    making a non-specific statement about how the reputation returned was
>    developed.

It sounds as if they are making no statement at all about the 'development' of 
the reputation.  Or perhaps I'm misunderstanding what is meant by development.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 28 Mar 2012 12:59:45 +0200

On 3/28/12 7:30 AM, Dave Crocker wrote:
>>       where the subject identifier was found in the message.

Maybe the phrase "[...] was found in the message" should be rephrased, 
as some of the identifiers mentioned in the list, are not part of the 
message but are part of the envelope (RFC5321.MailFrom) or part of the 
SMTP session (RFC5321.EHLO) or part of the transmission path (IPv4, IPv6).

>>   This MUST

I don't think so for the following reason. There are two scenario's for 
the HELO/EHLO parameter:

  * the parameter matches via the source IP address of the connection
    (either via a DNS A/AAAA/CNAME or directly if the parameter itself
    is an IP address) with the IP address
  * the other scenario is, that it doesn't match the source IP address

In scenario 1, the HELO/EHLO parameter identity doesn't add any value to 
the IP address, that is already known from the connection.
In scenario 2, there's little we can say about the authenticity of the 
identifier

On the other hand...

The key question here is: when is a part of a message (or transmission) 
suitable to be used as an identifier? What criteria do apply? In theory 
any of the identifiers mentioned in paragraph 4.1.4 of RFC5598 are 
candidates to be used here. However, some of them are not easily 
verifiable. Do we exempt them from the list of 'MUST be one of...' or do 
we add an additional phrase to the MUST like:

"This MUST be one of [...]

and MAY be one of the identifiers mentioned in par. 4.1.4 of RFC5598"

leaving the _authentication part of the puzzle_ to the reputation 
client, that may have specific information about the level of trust they 
have in the part of the message they want to use as an identifier.

> Same question for RFC5321.Sender...

I assume, you mean RFC5322.Sender?

/rolf