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

["Murray S. Kucherawy" <[e-mail]>]

On Tue, Mar 26, 2013 at 2:27 PM, Alessandro Vesely <[e-mail]> wrote:

> > 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.
>

So the goal then is to allow the authserv-id to encode arbitrary other
details, such as but not including the queue ID, and that one example has a
completely unspecified format.  This seems like a no-win situation.


>
> > 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.
>

If an ADMD chooses to use the authserv-id to encode details apart from an
ADMD identifier, contrary to its stated purpose, then you're absolutely
correct.  RFC5451 already talks about that.


>
> >>>> 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.
>

Again, there's nothing saying that it has to be a domain name.  It's merely
a string that the consumers expect will be set to a certain thing by border
MTAs within its own ADMD.  I get that it's a convenient construct, and it's
a good example, but there's no operational reason to limit it that way.


>
> >> 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...
>

Quite right.  Should this document be making that call?


>
> >>> 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.
>

Absolutely correct, and also absolutely not something that has to be
specified here beyond making it a "value".

I'd be happy to add text saying this specifically if necessary.


>
> >>>> 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.
>
> Exactly!
>
> > What for?
>
> Anything that it might be useful for.  If we think it isn't useful,
> then the spec should not allow it.
>

So why doesn't making authserv-id a "value" accommodate that case?


>
> >>>> 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.
>

The authserv-id doesn't have a version in the ABNF.  That version is the
version of the A-R specification as a whole.  It's a convenient place to
attach that information (e.g., "this ADMD is using A-R version 'x'"), and
consistent with use of versions on the method tokens.



>
> >>>> 6. examples of valid authentication identifiers are "example.com"
> >>>>    "mail.example.org", "ms1.newyork.example.com", 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.
>

Why is it quite complicated?  Trusted authserv-ids is merely a set of
strings.  If you're looking at an A-R header field whose authserv-id is in
that list, you've decided explicitly that its content can be trusted.
Anything else should either be ignored or removed (depending on which agent
is looking at it).

It only gets complicated if you choose to overload that field with your own
purposes by encoding other data in it.  If some people find that useful,
then great, but I don't think this specification should describe how to do
that beyond not explicitly blocking it.


> >>    Authentication-Results: "Murray's Authentication Service;
> >>       used with permission since version /1. ;-)" / 2;
> >>       dkim = pass header . d = example.com (...)
> >>
> >> 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?
>

The specific thing you're talking about, namely the occasional practice of
encoding queue IDs into authserv-ids, is already incompatible with
RFC5451.  This change adapts to current use.


>
> >>> 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 A-R-producer.my-host.my-ADMD/12345?  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.
>

Keep reading; the remainder of that section actively discourages the
practice.

There are a lot of things that standards enable but also say "You could do
this, but there are costs involved."  This is one of them.

-MSK