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

Alessandro Vesely <> Tue, 26 March 2013 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 023C421F8DBF for <>; Tue, 26 Mar 2013 12:27:23 -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 xp3H05o72C5f for <>; Tue, 26 Mar 2013 12:27:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7A9A621F8DC1 for <>; Tue, 26 Mar 2013 12:27:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; t=1364326040; bh=mTrb3Ze2tHb4VnIW3WwHA0bExbIB1zIKctGykViIRus=; l=7839; h=Date:From:To:References:In-Reply-To; b=mCBnD/BDA+Zh+VHCsmM12DqFtL6R9r7STHhykgVN4a05nAvLXjmyy4RJjO6q0dBh/ Nzkr47kcvW/PHFgrbRZlirTk/Q4YJLe4mSHlDUyKm2PAdcOcfzk+GaEucR1lD1ZyA6 izE2J5O3aDtyBLZmTVz+oZ0M+OQRFVfGwxM27D00=
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by with ESMTPA; Tue, 26 Mar 2013 20:27:20 +0100 id 00000000005DC039.000000005151F698.00003B41
Message-ID: <>
Date: Tue, 26 Mar 2013 20:27:20 +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 19:27:23 -0000

On Tue 26/Mar/2013 16:35:28 +0100 Murray S. Kucherawy wrote:
> On Tue, Mar 26, 2013 at 5:41 AM, Alessandro Vesely <> wrote:
>>>> 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.
> My point is that RFC6650 Section 5.3 says nothing about allowing POP3 MUAs
> to extract a reporting address from the Authentication-Results header
> field's authserv-id, so I don't understand why you used it as a reference.
> Such was never the intent.  It's fine to talk about it in ASRG or anywhere
> else, of course, but that's not in my view a good impetus for now adding
> that possible meaning here.

Point taken.  I mentioned it to stress that there are cases where
authserv-id is consumed outside the ADMD where it was produced.

>>>> 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?
> That logic presupposes that queue IDs have a known syntax, but they don't.
> I know of one that uses slashes and hyphens in its queue IDs, for example.

Yes,the queue id is just an example.

> But to answer your question directly, any software inside an ADMD seeking
> to use this field would be configured to look for a particular string right
> after the header field name and up to the first semicolon, and if that
> string matches the string it's looking for, then the field can (presumably)
> be trusted.

It has better be careful to exclude the queue id from the comparison.

>>>> 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.
>> [...]
> There is no obvious reason to preclude the possibility of not using a
> domain-name there either.

A domain name can be used effectively only if the consumer knows it is
a domain name.

>> 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.
> Indeed.  And there's no reason to constrain such masquerading to
> "domain-name", is there?

There are pros and cons.  Similar arguments hold for the choice of
domain that an ADMD uses as d= to sign messages...

>>> 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.
> Isn't that the point of publishing a standard, i.e., this entire exercise?

Yes!  My point is that is a producer is allowed to stuff a queue id
somewhere besides the server id, then the consumer has better to
expect that possibility.

>>>> 4. transport tracing data such as the SMTP queue ID or a timestamp
>>>> [...]
> You seem to be advocating for giving the queue ID its own token in
> the header field different from the authserv-id in a normative
> sense.


> What for?

Anything that it might be useful for.  If we think it isn't useful,
then the spec should not allow it.

>>>> 5. version identification,
>>> That's not part of the authserv-id itself.
>> Right, it's similar to #4 in this respect.
> Then I don't understand you claimed it as a separate requirement.

They are both specified.  I think it is difficult and useless to have
them both to coexist.  I'd drop the authserv-id's version.

>>>> 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
>> boundaries.
> I don't understand.

It is quite complicated to let trusted domain's A-R pass through.
Using identifiers that are not domain names forces an additional level
of indirection, and I'd figure average admins would rather remove them.

>> > 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:
> I don't see how the additional grammar you proposed previously (which was
> half a page long on my screen) simplifies anything.

Importing grammar from external sources doesn't make it simpler.

>>    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.
> I'm fine with extending the convoluted example to show this possibility.

And the (possibly minor) incompatibility with RFC 5451?

>>> 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.
> Attaching the queue ID as part of the authserv-id means you're effectively
> using a new authserv-id for every message, which is clearly not the
> intent.  It's incumbent on the consumers to figure out what that means.  I
> don't think that (or any hack) should be encoded into the document.

But then why do you write:

                                              Moreover, some
 implementations have considered appending a delimiter such as "/" and
 following it with useful transport tracing data such as the [SMTP]
 queue ID or a timestamp.

You can allow or prohibit that, but not both at the same time.