Subject: RE: Message-ID (was: RE: Take 2: References/In-Reply-To replaceme nt text)

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Tue, 1 Jun 1999 14:36:24 -0700

The cases where it is a bad idea are really simple - requiring FQDNs
precludes deploying an 822bis message generation algorithm on a network with
a flat name space.  This means that you would be unable to deploy an 822bis
based mail system on a large class of networks.  While TCP/IP is certainly
the dominant networking protocol deployed today, and DNS is the dominant
naming hierarchy, it is far from the ONLY one deployed.  

Even if TCP/IP and DNS ARE deployed, there is no guarantee that the DNS
deployed in a company be the same as the DNS deployed OUTSIDE the company.
As an example, for many years (pre-1994), Microsoft's internal DNS purposely
conflicted with the external DNSs (the reasons for this are obscure and had
to do with the way our firewalls were configured, we also used class A IP
addresses that were deliberately in conflict with external IP addresses).
This meant that it was entirely possible for a FQDN generated inside
Microsoft's firewall would conflict with a FQDN generated OUTSIDE the
Microsoft firewall, since there was no communication between the two naming
systems.  In such a configuration, the use of a FQDN is potentially
assertively harmful.

Just as a flat naming system sometimes precludes the existence of a FQDN,
similarly the potential for conflict renders the FQDN generated inadequate.
And this is EXACTLY the reason that we have a "SHOULD" option in 2119 -
there are really really good reasons for doing something, but sometimes you
gotta break those rules without being non compliant.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

> -----Original Message-----
> From: Matt Curtin [mailto:[email-masked]]
> Sent: Tuesday, June 01, 1999 2:29 PM
> To: Larry Osterman (Exchange)
> Cc: 'Robert Elz'; Pete Resnick; DRUMS
> Subject: RE: Message-ID (was: RE: Take 2: References/In-Reply-To
> replaceme nt text)
> 
> 
> >>>>> On Tue, 1 Jun 1999 14:10:19 -0700 ,
>       "Larry Osterman (Exchange)" 
> <[email-masked]> said:
> 
> Larry> The best we can do is to continue the practise as codified in
> Larry> RFC822 and 822bis - the RHS of a message ID SHOULD be a FQDN,
> Larry> and it is the responsibility for the generator to guarantee
> Larry> that the ENTIRE message-ID is unique across time and space (and
> Larry> generation algorithms).
> 
> I buy this in principle.  But I think that we can require (MUST) that
> the RHS be an FQDN, arguing that this is how we divide the namespace
> and prevent me from generating Message-IDs which will conflict with
> your Message-IDs.
> 
> If you still aren't going for it, could you please provide some
> examples of where this is a bad idea?
> 
> -- 
> Matt Curtin [email-masked] 
> http://www.interhack.net/people/cmcurtin/
>

---

From: Matt Curtin <[email-masked]>
Date: Tue, 1 Jun 1999 18:09:08 -0400 (EDT)

>>>>> On Tue, 1 Jun 1999 14:36:24 -0700 ,
      "Larry Osterman (Exchange)" <[email-masked]> said:

Larry> The cases where it is a bad idea are really simple - requiring
Larry> FQDNs precludes deploying an 822bis message generation
Larry> algorithm on a network with a flat name space.

Ah, this is definitely the point of disagreement.

Larry> While TCP/IP is certainly the
Larry> dominant networking protocol deployed today, and DNS is the
Larry> dominant naming hierarchy, it is far from the ONLY one
Larry> deployed.

Well, it's the ONLY one deployed on the Internet and DNS will remain
_the_ naming hierarchy for the forseeable future.

As this is an Internet standard that we're attempting to draft, that's
all that really matters.

Larry> Even if TCP/IP and DNS ARE deployed, there is no guarantee that
Larry> the DNS deployed in a company be the same as the DNS deployed
Larry> OUTSIDE the company.

Irrelevant.  (Humor me a moment; I'll explain myself below.)

Larry> As an example, for many years (pre-1994),
Larry> Microsoft's internal DNS purposely conflicted with the external
Larry> DNSs (the reasons for this are obscure and had to do with the
Larry> way our firewalls were configured, we also used class A IP
Larry> addresses that were deliberately in conflict with external IP
Larry> addresses).  This meant that it was entirely possible for a
Larry> FQDN generated inside Microsoft's firewall would conflict with
Larry> a FQDN generated OUTSIDE the Microsoft firewall, since there
Larry> was no communication between the two naming systems.  In such a
Larry> configuration, the use of a FQDN is potentially assertively
Larry> harmful.

With all due respect to you as an individual, Larry, that's
Microsoft's own darn fault and a direct result of hubris,
incompetence, ignorance, or perhaps some combination thereof.
Especially before 1995, Microsoft has not enjoyed the reputation of an
Internet-friendly or especially clueful organization.  At that time,
your colleagues were running around promoting "good enough software",
claiming that MSN was the only network that would matter, and propping
up Bill Gates to say things like "the Internet is the frothiest thing
I've ever seen".  Microsoft's corporate misconfiguration is not of
interest to the Internet community.

Now, above I boldly claimed that a company's internal networks and
naming schemes are irrelevant to the problem of Message-ID generation.
The reason I assert this so confidently is because there is already a
need to provide a globally-unique, DNS-dependent identifier for mail
to work, that is the user's address.  So it isn't like there isn't a
globally-unique domain that an MUA can't recognize as its own.

If the sender's address isn't world-unique, then there are bigger
problems at hand, and/or that mail isn't going over the Internet, in
which case it's of very little interest in Internet Engineering Task
Force documentation.

I say again, RHS "MUST" be an FQDN.

(You and I might not be able to reach an agreement here so it might be
best to see what others have to say and see whether there is consensus 
in either the case of MUST or SHOULD.)

-- 
Matt Curtin [email-masked] http://www.interhack.net/people/cmcurtin/

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Jun 1999 19:38:05 -0400

--On Tuesday, June 01, 1999, 14:36 -0700 "Larry Osterman (Exchange)"
<[email-masked]> wrote:

> precludes deploying an 822bis message generation algorithm on a network
> with a flat name space.  This means that you would be unable to deploy an
> 822bis based mail system on a large class of networks.  While TCP/IP is
> certainly the dominant networking protocol deployed today, and DNS is the
> dominant naming hierarchy, it is far from the ONLY one deployed.  

Larry,

The above is mostly an argument for requiring not only an FQDN, but an FQDN
that is resolvable in the global Internet's DNS hierarchy.   I suspect such
a requirement would be more trouble than it is worth (hard to enforce) but,
like Matt, I have little sympathy for warping an Internet standard to
permit things that don't work on the public Internet (e.g., operate in
private protocol or name spaces)  to claim conformance.   

IETF just does not, and should not, be attempting to do protocols for
private networks/ name spaces/ protocol suites.   If some IETF work can be
usefully adapted for such environments, then that is great.   But it should
be the obligation of the private environment to describe its variations or
profiles to the extent that its proprietors find that appropriate.

     john

---

From: Keith Moore <[email-masked]>
Date: Tue, 01 Jun 1999 21:39:42 -0400

> a flat name space.  

strictly speaking, no it does not.  Internet standards only apply to the
Internet.  what you do in the privacy of your own network is your own 
business.  heck, you can even run microsoft software if you really want to.

as a practical matter, many companies do not want their internal
(fully-qualified) domain names exposed even if they have 
delegated authority for those names in DNS.  so even if ietf wants
to impose this requirement, it's going to be violated in a large
number of cases.

it's better to recommend that all message-ids be globally unique, 
than to insist on something that won't fly in practice.

Keith

p.s.

> systems.  In such a configuration, the use of a FQDN is potentially

sure, but a site that doesn't keep its own namespace consistent
violates all manner of assumptions about how DNS works, and deserves
whatever it gets!  we certainly don't expect IETF standards to work in
the face of complete operational brain-damage.

---

From: Matt Curtin <[email-masked]>
Date: Tue, 1 Jun 1999 23:09:32 -0400 (EDT)

>>>>> On Tue, 01 Jun 1999 21:39:42 -0400, Keith Moore <[email-masked]> said:

Keith> as a practical matter, many companies do not want their
Keith> internal (fully-qualified) domain names exposed even if they
Keith> have delegated authority for those names in DNS.

True.  However, the fact of the matter is that they *are* exposed
(usually through Received headers), at least in the case of mail, to a
much greater degree than what they would be through a Message-ID
header.  (I recognize that gateways can mangle Received headers in
ways that we do not want Message-IDs to be rewritten or otherwise
mangled.)

Also, a requirement for a Message-ID's LHS to be an FQDN doesn't
necessarily mean it must go to the level of a host.

One of the ideas that was floated for Message-ID generation (probably
on USEFOR) was to have Message-IDs generated by having the timestamp
and other input prepended to the (poster|mailer)'s From: address, so a 
Message-ID that my client generates might look something like:
  <[email-masked]>

Thus, we satisfy the requirement for a resolvable RHS and even take a
step further to prevent collision within the domain by different
clients.

This is just one of many ways to generate Message-IDs as I am
advocating in a way that will both keep clients within their own
namespace and prevent internal hostnames from leaking outside.

I am in agreement that wherever Message-ID is defined, the security
considerations section should include both UUID-type and leaking
hostname warnings.

Should all of this Message-ID business be part of DRUMS itself, or
would it be possible to have a seperate document that details
Message-ID generation and usage, published with DRUMS?  (If we get
into that level of detail, I would actually prefer a seperate document
since there is also news applicability.)  I already have an I-D on
this and would be happy to do the work to have it see the light of
day.

---

From: Keith Moore <[email-masked]>
Date: Wed, 02 Jun 1999 00:24:57 -0400

> step further to prevent collision within the domain by different

what operational purpose does this serve?  

> Message-ID generation and usage, published with DRUMS?  

probably the latter.  DRUMS is already in last call
(waiting for me to review it!) and the community is almost
certainly better off if we don't hold it up for this reason.

Keith

---

From: Matt Curtin <[email-masked]>
Date: Wed, 2 Jun 1999 01:50:31 -0400 (EDT)

>>>>> On Wed, 02 Jun 1999 00:24:57 -0400, Keith Moore <[email-masked]> said:

>> like: <[email-masked]>

Keith> what operational purpose does this serve?

It's just an example of a "safe" generation scheme that would allow:
 o division of the namespace by Internet domain name.
 o calculation of the correct Internet domain name without having to
   use something that could potentially be an internal host name
   (which might be the case if we use a gethostbyaddr(), hostname,
   etc.)

On USEFOR, some complained that it's a very bad for Message-IDs to use
blindly the host-part of the sender's address, as extremely large
domains with a *lot* of clients out there (aol.com, hotmail.com, etc)
generating Message-IDs could collide with others in the same zone.

Sticking the user name at the end of the LHS would effectively
eliminate that complaint--though it wasn't clear that there was
consensus that it was something that had to be handled.

It does have some interesting and useful side-effects, like making
scoring easier...

Anyway, it was just an example, possibly more complicated than I
should have offered.

>> Message-ID generation and usage, published with DRUMS?

Keith> probably the latter.

Alright.  I'll need to update my proposal in order to articulate
requirements for the Message-ID on the Internet more formally (i.e.,
RHS MUST be FQDN, as opposed to a casual "use of an unqualified
hostname...would be foolish").  I'll post it here and mail it to the
drafts editor when done (tomorrow?)...

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Jun 1999 07:42:47 -0400

--On Tuesday, 01 June, 1999, 23:09 -0400 Matt Curtin <[email-masked]>
wrote:

>...

This seems to me to be the germ of a good idea...   How about we do 822bis
narrowly, focusing on getting an FQDN there, stressing the uniqueness goal and
that it doesn't have to be the FQDN of the originating host, and identifying
the security issues.   Then we could do a separate, informational, RFC on "some
ideas for generating Message-IDs" that would explore these other options by
example, without the requirements of specifying what is standard or not,
preferred or not (as long as all of the examples fall within the "conforming"
space).

      john

---

From: Keith Moore <[email-masked]>
Date: Wed, 02 Jun 1999 09:35:28 -0400

no, what I want to know is - what operational purpose does it serve
to require that the message-id contain an fqdn, especially if you
don't require that fqdn to be that of the host that generated the
message-id?

suppose we were to define a message-id.net domain (haven't checked
to see if it's taken yet...) and then allow anyone in the world to
create message-ids of the form [email-masked], where UUID is
a hex representation of a locally-generated UUID   would that
satisfy your criteria?  and how would this be better than using
a non-fqdn as the domain, say UUID@uuid (the latter "uuid" being
a literal string)?

I think you are making this too difficult for no good reason.

Keith

---

From: Matt Curtin <[email-masked]>
Date: Wed, 2 Jun 1999 10:28:49 -0400 (EDT)

>>>>> On Wed, 02 Jun 1999 09:35:28 -0400, Keith Moore <[email-masked]> said:

Keith> no, what I want to know is - what operational purpose does it
Keith> serve to require that the message-id contain an fqdn,
Keith> especially if you don't require that fqdn to be that of the
Keith> host that generated the message-id?

The FQDN is how we limit the damage that any single Message-ID
generator can do.  In an optimal situation, each Message-ID generator
would have a unique domain token, or all generators using a given
token would be cooperating.

I'd like to require that the FQDN be the real FQDN of the generating
host, but I recognize that isn't possible, especially where the
generator could be a disconnected client whose name isn't necessarily
the same as when it's plugged back into the network.

In order to accomplish the same objective as a unique domain token for
each generator, we can use the sender's address as the basis for the
Message-ID.  Assuming any reasonable LHS generation algorithm, using
only the domain part of the sender's address would probably work
except for domains that cover a huge number of users.

Using also the sender's user-id as input for the Message-ID would
allow us to generate a Message-ID that will correctly identify a
unique Message-ID generator, that is, the user, and have other stuff
in the LHS to guarantee a unique Message-ID for that message.

Keith> I think you are making this too difficult for no good reason.

I hope I was able to alleviate that concern.

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Jun 1999 10:22:47 -0400

> to see if it's taken yet...) and then allow anyone in the world to

Keith,

Let me see if I can partition your question enough to answer it (or maybe some
of Matt's or Larry's) -- not sure we disagree here..

(i) Are globally-unique message-IDs useful?

    Experience so far is that we've been insufficiently effective at defining
interoperable and widely-implementated syntax and semantics to make the answer
"yes".   There is, IMO, a case to be made for just deprecating the things as
having fallen into uselessness through bad implementations and general abuse.
They are a strong argument for the principle that we need to make anything we
are about mandatory and to define it with as few options as possible.

But, assuming that answer is "yes"...

(ii) Can a system that uses an FQDN on the RHS and that assumes/requires that
the LHS be unique within whatever space is defined by the RHS be made to work
and guarantee uniqueness and to do so with minimal disclosure of whatever
security isn't compromised in other ways?

Answer to that is clearly "yes".  

The flexibilities of "some FQDN" might be surrounded --although I don't know
whether better in a standard or in the sort of informational doc Matt
proposed-- by some language about binding of administrative responsibiity for
uniqueness to the domain chosen and its administration.  Any serious notions of
administrative responsibility would probably make a global message-id.net
useless, but, much as I hate messing with these things, I might easily decide
to fix my application gateway so that messages arrived with
[email-masked] message-IDs and transformed them into 
   hash(string,user-host)@mci.net
ones that would prevent an outsider from deducing my topology but preserve
uniqueness, and responsibility for it, for my SLD domain (rather than that of
user-host.mci.net).   And I suppose that sites that wanted to take message-IDs
they received really seriously would rapidly start constructing lists of
domains they trusted more than others, but that is, unfortunately, nothing new.

(iii) Could we devise another scheme that would meet the uniqueness and minimal
disclosure objectives as well or better than RHS FQDNs do?  And might it be
better?

Of course.  We almost always can, especially when the older mechanism to which
we are comparing dates from a network with different constraints and ways of
looking at things.  But, if the new mechanism doesn't use at least the syntax
of an FQDN, we are going to break some benighted existing implementations that
try to use message-IDs.  And, while we could clutter the world up with
pseudo-TLDs or -SLDs as you suggest, all of those things impress me as kludges
that will probably mess up our lives if we aren't careful.   They are worth the
risk if we have no other rational alternatives, but here, we do and we have it
in something for which there is already some claim to standardization and
deployment, so why mess.

     john

---

From: Robert Elz <[email-masked]>
Date: Thu, 03 Jun 1999 00:32:17 +1000

Date:        Wed, 02 Jun 1999 09:35:28 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | suppose we were to define a message-id.net domain (haven't checked
  | to see if it's taken yet...) and then allow anyone in the world to
  | create message-ids of the form [email-masked], where UUID is
  | a hex representation of a locally-generated UUID   would that
  | satisfy your criteria?

That would be fine - just as long as that domain name has a particular
defined algorithm for message-id generation which guarantees unique
messages ids (where "guarantees" means "makes it very likely in normal
circumstances") no matter where they're generated.   The microsoft algorithm
as described here soulds like one where that would be true, and hence a
static fixed domain name on the RHS of all message-id's it generates would
be fine (just provided it is a fixed domain name that is properly their
perogative to add).

  | and how would this be better than using
  | a non-fqdn as the domain, say UUID@uuid (the latter "uuid" being
  | a literal string)?

No difference at all, provided that "uuid" is defined that way, and is
defined so that if it is used, no-one else can ever use it any other way.
That more or les amounts to reserving the TLD "uuid" for this purpose,
exactly as has been done with "MHS".

If that isn't done, then anyone can stick "@uuid" on the end of any message-id
(and quite properly, violating no standards or conventions at all) and all
hope of uniqueness is gone completely.

Using the longer domain name seems like it is simpler, more flexible, and
less prone to political bunfights all around.

But whatever we do, the message-id RHS *must* serve to disambiguate the
algorithm used to generate the unique string n the RHS.   Exactly how the two
work together is flexible, but for this to work, one of them (at least) needs
to use a defined assignment method (everyone generate a random string doesn't 
work).   Using the DNS, which already has all themechanism we need, seems like
the simple solution - it is also the solution that is used now, and has been
used for many years (since back before the DNS existed, and it was the NIC 
HOSTS.TXT file that was used).

kre

---

From: Brad Knowles <[email-masked]>
Date: Wed, 2 Jun 1999 17:22:24 +0200

> exactly as has been done with "MHS".

	This is why the RHS of "version.product.vendor.domain.example" 
works so well.  No one could rightly claim any RHS in or under 
"vendor.domain.example", unless they were producing a legitimate 
product or service for or on behalf of that vendor.

	However, since the spectre of X.400 has been brought up with MHS, 
and the possibility of using TLDs as an RHS has also been mentioned, 
I think this is a clear indicator that we need some sort of a 
message-id registry scheme, except for those vendor proprietary 
message-id schemes which they choose to use as pseudo-domains under 
their legitimate Internet DNS domain names.

	So, "@uuid.microsoft.com" would be a perfectly valid RHS that 
could be tacked on to each and every message that gets sent out with 
a Microsoft product and which uses the UUID scheme to generate the 
LHS.  And would also have the advantage that it wouldn't need to go 
through any sort of central registry (assuming that such existed), 
etc....

-- 
   These are my opinions -- not to be taken as official Skynet policy
  ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News & FTP Admin      Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
   Unix is very user-friendly.  It's just picky who its friends are.

---

From: Robert Elz <[email-masked]>
Date: Thu, 03 Jun 1999 01:42:49 +1000

Date:        Wed, 2 Jun 1999 17:22:24 +0200
    From:        Brad Knowles <[email-masked]>
    Message-ID:  <v04205106b37afb852ddf@[195.238.1.121]>

  | 	However, since the spectre of X.400 has been brought up with MHS, 
  | and the possibility of using TLDs as an RHS has also been mentioned, 
  | I think this is a clear indicator that we need some sort of a 
  | message-id registry scheme, except for those vendor proprietary 
  | message-id schemes which they choose to use as pseudo-domains under 
  | their legitimate Internet DNS domain names.

No, I don't think so, the DNS is enough, we don't want two competing
schemes.   If someone wants to use something else odd, they can just
reserve a TLD for the purpose...  (which can, or could, in theory anyway,
be done by writing a standards track RFC which defines the new TLD).

kre

---

From: Jacob Palme <[email-masked]>
Date: Thu, 3 Jun 1999 03:08:33 +0200

> are about mandatory and to define it with as few options as possible.

Shortcoming of existing software should not limit
ourselves. Globally unique Message-IDs can perform many
useful functions, if they were correctly used:

- Coordination of duplicates of the same message
- Loop control
- Commands for users to recognize and traverse threads

The fact that many mail systems today do not provide these
very useful systems is because most mail systems do not
recognize the fact that mail, for many users, is in fact a
data base system. An increasingly large part of a person's
knowledge is stored in his/her set of mail messages, and
people often complain that many mail systems do not give a
good enough support to organize this important data base. I
am quite sure that mailers in the future will more often
support data bases of messages in a better way, and that
this will make it easier for users to organize and find
messages.

This is not a comment on the general issue of using
FQDNs to generate Message-IDs. For the record, I strongly
support this principle, but what I write above is only
a comment on John's statements about the uselessness of
Message-IDS.
------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Jun 1999 21:24:51 -0400

> - Commands for users to recognize and traverse threads

In case it isn't clear, I completely agree with all of this.  If
Jacob and I disagree about any of it, that disagreement probably
lies in...

> a comment on John's statements about the uselessness of

In principle, I think they are a great idea, and I'd like to see
much wider support of exactly the sort of facilities Jacob 
identifies.   In practice, there have been so many sloppy 
practices in implementing and inappropriate copying or 
rewriting of Message-IDs that I'm a little pessimistic about the
use of the current mechanism, especially in the absence of 
heuristics to untangle and clean up the messes.  That, in turn, 
leads to an entirely pragmatic inclination to abandon 
"Message-ID:" and replace it with "Message-ID2:" with an 
associated very clear set of rules, semantics, requirements, and
expectations.

None of which has much to do with the question in front of DRUMS.

   john

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Jun 1999 15:02:47 -0000

From http://pobox.com/~djb/proto/immhf/thread.html:

   The Internet mail address encoded in Message-ID is required to be a
   unique worldwide identifier for this message.

   It is the writer's responsibility to obtain authorization from the
   owner of the domain used in Message-ID. It is up to the owner to
   decide how to allocate a different box part for each new message.

Certainly Microsoft is shirking its responsibility here.

On the other hand, the people saying ``Horrors! My Message-IDs might
accidentally collide with your random 128-bit number!'' are being silly.

Keith proposes setting aside message-id.net for anyone to use. But
that's not a complete proposal. How are the Message-IDs allocated in
that new domain? There has to be some randomness.

I'd suggest setting aside, e.g.,

   [email-masked]
   
where T is an approximate timestamp showing seconds since the beginning
of 1970, and R is a string containing at least 128 bits of randomness.
Other *.id.int formats can be allocated later if necessary.

---Dan

---

From: [email-masked] (Kai Henningsen)
Date: 06 Jun 1999 18:31:00 +0200

> a non-fqdn as the domain, say UUID@uuid (the latter "uuid" being

First, "uuid" *could* be a FQDN. It currently isn't, of course, but "com",  
for example, certainly is a FQDN, if not a very useful one. An FQDN  
doesn't need to contain any dots, though most of them certainly do.

Given this, if you can guarantee that there never will be a FQDN colliding  
with your chosen RHS, that would be fine operationally. The easiest way to  
do that, of course, is using a (possibly unregistered) FQDN that you have  
administrative control over. (For example, I could certainly use  
messageid.khms.westfalen.de, given that I have administrative control over  
*.khms.westfalen.de, even though no host by that name exists - well, the  
DNS does happen to have a wildcard MX, but I could use the same if that MX  
wasn't there.)

Or to put this another way, make sure that the TLD UUID will always be  
available for this, then you can use it that way. (Personally, I'd  
recommend <type of uuid>.uuid or something similar instead.)

> I think you are making this too difficult for no good reason.

This may be a matter of perception.

MfG Kai