Re: [apps-discuss] The authentication server id, was rfc5451bis

Alessandro Vesely <> Tue, 26 March 2013 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F143721F8AE3 for <>; Tue, 26 Mar 2013 05:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1eADN3ejvB+q for <>; Tue, 26 Mar 2013 05:41:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 841E521F8ACE for <>; Tue, 26 Mar 2013 05:41:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; t=1364301671; bh=91H1aya8cVLAY3euL7gmY4zL9oulYLUjzl0JczwMvjo=; l=6961; h=Date:From:To:References:In-Reply-To; b=RgZTdpQp2dEydF2mPlJfS01WHM+59lKEfA4BWhSjF4AYDOlPdbBRpacDrW73TvW4x bFI+YGaA92fnkl29zYHPmLYIIY54CCRv4p6PetYW109ahZlcbujtC0pTeVEib8wqO5 X5128HP37xkU+BEabewNLfWnz35kde1UeLjReY8w=
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by with ESMTPA; Tue, 26 Mar 2013 13:41:11 +0100 id 00000000005DC047.0000000051519767.00005AF9
Message-ID: <>
Date: Tue, 26 Mar 2013 13:41:11 +0100
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Mar 2013 12:41:15 -0000

On Mon 25/Mar/2013 19:54:25 +0100 Murray S. Kucherawy wrote:
> On Mon, Mar 25, 2013 at 5:19 AM, Alessandro Vesely <> wrote:
>> On Sun 24/Mar/2013 22:06:41 +0100 Murray S. Kucherawy wrote:
>>> Since in the prose we talk about authserv-id being a domain
>>> name in the typical case but basically also say it could be
>>> anything the operator wants to use, I think "value" is the 
>>> right thing there.
>> Besides the parsability point (quotes), the intended use of this piece
>> of data is rather overloaded.  Let me recap some requirements:
>> 1. Identification of the ADMD for assessing trust relationships
>>    (and possibly also for POP3 MUAs to send back complaints,
>>    per Section 5.3 of RFC 6650),
> I don't see a reference to this work there.

That possibility was voiced in the ASRG and elsewhere, but never
formalized --which is why I put it in parentheses.  AIUI, the
authentication server identifies the ADMD responsible for receiving a
message.  The means of identification, usually a registered domain
name, is consistent with the way each method identifies the ADMD(s)
responsible for /sending/ the message.

>> 2. uniqueness of the identifier,
> This is key for identifying your own, but it doesn't speak to a
> necessary syntax.

I'm dumbfounded by that statement.  How can a piece of software be
configured by an ADMD so as to determine whether A-Rs "have been added
within its trust boundary"[Section 5] if that software is unable to
distinguish the server id from, say, the queue id?

>> 3. similar in syntax to a fully-qualified domain name,
> There's nothing saying an ADMD can't use a simple word or even a
> single punctuation here (so long as it fits the grammar).  Ideally
> it's most useful when it's in this form, but an ADMD could use "---"
> as an authserv-id and still get results useful to it.

"---" doesn't match "domain-name".

> A complete sentence would also be valid.

If you use "value", yes.  However, the methods to determine whether
two sentences identify the same ADMD are not part of the common practices.

> I can't think of a good reason to restrict this to look like a domain
> name if it doesn't actually represent a single DNS domain entity.

Well, one could use, e.g,  In that
case, those common practices might suggest that
belongs to the same ADMD.  RFC 5451 does not impose such method,
presumably to allow implementers to experiment different ways.

> One ADMD could be doing authentication service for lots of domains,
> but it's still one ADMD.

It's their choice whether to masquerade or not.

> If I run a service that does email authentication for tons of
> domains, why could I not use "Murray's Authentication Service" for
> an authserv-id?  Or even the empty string?  As long as the producer
> and consumer are consistent in their uses of it, all of your stated
> requirements are met.

In principle, I agree.  However, producers and consumers can consist
of software developed by several independent programmers.  Those
agents can interoperate only if programmers agree on a common syntax,
so that agents can be configured in ways compatible with one another.

>> 4. transport tracing data such as the SMTP queue ID or a timestamp
>>    (semantic hints would also go here, e.g. "all signatures checked
>>    but failures not reported" vs "checking stops on first success"),
> This also doesn't appear to me to demand a specific format (as above).

It is unspecified how a consumer would use a queue id or a verifier's
configuration version.  Consonant producers and consumers can carve
out a space where to pass useful data from one to the other.  The
important point is that they don't step on another agent's toes by
invading the id proper.

>> 5. version identification,
> That's not part of the authserv-id itself.

Right, it's similar to #4 in this respect.

>> 6. examples of valid authentication identifiers are ""
>>    "", "", and "example-auth".
> The last string in that list is not what most people think of as a
> fully-qualified domain name, but as you point out, it's perfectly
> acceptable.

Yes, albeit that may preclude A-Rs produced that way to cross domain

>> Bullets #3 and #6 are compatible with "domain-name".  By using domain
>> names in the traditional ways, even though they are not required to be
>> in the DNS, operators can easily implement #1 and #2.  Conversely,
>> we'd need production rules to parse a "domain-name" inside the rest of
>> the "value" if the grammar were relaxed that way.
>> Alternatively, we can meet #4 and #5 by relaxing or extending the
>> "version".  [example omitted]
> I think we're wandering off into some bikeshedding here.  I'm curious
> to know if anyone else supports this more complicated notion.  I
> certainly don't agree with making the "separator" be anything other
> than "/".

The text is not stringent:

   appending a delimiter such as "/" and following it with useful
   transport tracing data

I'd prefer a fixed separator too.  How about this:

   "Authentication-Results:" [CFWS] domain-name
              [ [CFWS] "/" [CFWS] dot-atom ]

> The overall grammar is pretty clean right now: break on unescaped
> semicolons and you get paragraphs of useful information; the first
> paragraph is the authserv-id stuff, and everything else is
> "method=result" followed by relevant method parameters; any unescaped
> "/" followed by a number is a version.  Is there a reason to
> complicate that?

My attempt is for simplifying, not complicating.  The "value" syntax
would allow:

   Authentication-Results: "Murray's Authentication Service;
      used with permission since version /1. ;-)" / 2;
      dkim = pass header . d = (...)

You'd have to extend the acid test in C.7 to account for that.

>> Semantically, allowing "anything the operator wants to use" conflicts
>> with the requirement that a parser explicitly knows it, in the new
>> Section 2.4.  IMHO, unrecognized ex-versions could just be ignored, as
>> the format is determined by the field name.
> How does it conflict?

For example, assume my MTA is set up such that I can tell from the
queue id whether a message arrived to port 25 rather than 587, and I'd
like to use that info downstream, e.g. for logging something.  It is a
hack, admittedly, but the A-R producer I use happens to let me
configure it for appending the queue id, so I use that and roll my A-R
consumer hack.  Now, I also run another A-R consumer, for example
spamassassin, which is --will be, hopefully-- able to use existing
results rather than computing them from scratch.  What should it do
when it finds  If that is a
version number that it knows nothing about, it should discard the field.