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

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Wed, 2 Jun 1999 16:13:54 -0700

Brad, there's no need for ad-hominum attacks, it's totally unprofessional,
and I'd like to believe that we're all professionals here.  I've not
slandered AOL or *nix, or any other vendors products, and don't intend to,
it's totaly inappropriate for any forum (public or private).

My claim (and no-one has contradicted me) is simply that in the absense of a
carefully crafted message-id generator that is purposely defined to attack
the Exchange message-id generation algorithm FOR A PARTICULAR DATABASE ON A
PARTICULAR MACHINE (as Robert Elz proposed), the Exchange message ID
generation is just as unique as any other general purpose message-id
generation algorithm.  And I also claim that the quality of the exchange
message-id generation algorithm is totally irrelevant to the purposes of
this discussion.  This discussion is just about what goes on the RHS of the
@ in a message-id.

I completely agree that the presence or absence of a FQDN in the RHS of the
message-ID CAN make it more unique, however I further claim that it is not
sufficient.  Even the algorithm proposed in msg-format-07 fails to work on
many operating systems, even in the presense of a unique RHS.

I believe that Robert Elz (and several others) hit ir exactly on the head:
If the LHS of the generator generates sufficiently unique message-IDs, then
the RHS might as well be a constant.  It certainly does not need to be an
addressable host, since the reality is that such a thing won't always happen
- internet mail IS generated on hosts behind firewalls and will continue to
be generated behind firewalls.  And if it ain't an addressable host, then
any string of characters works.

All I'm trying to do is to get the semantics of message-id that were
specified in RFC822 and that exist in the current msg-format-07 draft to
continue.

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: Brad Knowles [mailto:[email-masked]]
> Sent: Wednesday, June 02, 1999 11:02 AM
> To: Larry Osterman (Exchange); 'Matt Curtin'
> Cc: 'Robert Elz'; Pete Resnick; DRUMS
> Subject: RE: Message-ID (was: RE: Take 2: References/In-Reply-To
> replaceme nt text)
> 
> 
> At 10:26 AM -0700 6/2/99, Larry Osterman (Exchange) wrote:
> 
> > The message ID generation algorithm that exchange uses 
> isn't at issue here,
> > suffice it to say that it's unique enough.
> 
> 	That's simply not true, but this is obviously a point that we 
> will never be able to get pounded through your thick skull.
> 
> >                                              As a result, 
> it's POSSIBLE that
> > exchange's message-ID's will NOT have a FQDN on the RHS of 
> the message-id.
> > And I just want to ensure that Exchange isn't rendered non 
> compliant simply
> > because of this misconfiguration.
> 
> 	Sounds to me like yet another client software bug that 
> needs to be fixed.
> 
> -- 
>    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 13:32:44 +1000

Date:        Wed, 2 Jun 1999 16:13:54 -0700 
    From:        "Larry Osterman (Exchange)" <[email-masked]>
    Message-ID:  <01D6C7224936D211BA450000F805D5380542169D@TOTO>

  | My claim (and no-one has contradicted me) is simply that in the absense of a
  | carefully crafted message-id generator that is purposely defined to attack
  | the Exchange message-id generation algorithm FOR A PARTICULAR DATABASE ON A
  | PARTICULAR MACHINE (as Robert Elz proposed), the Exchange message ID
  | generation is just as unique as any other general purpose message-id
  | generation algorithm.

You seem not to be noticing the contradictions, so let me make this
quite plain.

I contradict you.

Or more correctly, what you have said in the paragraph above is just fine,
but it is not to the point.   What is important is that the scheme you
defined can easily fail, with no malicious intent, if someone defines
some other algorithm, also believes that it is "good enough as it stands"
and so just puts "any old junk" (but syntactically correct) on the RHS.

Just imagine another mailer on Windows/NT hosts which uses some other
generation technique, and also just does "@gethostbyname(...)" to make
the RHS.    It doesn't need to be on the same host, just any other host
that happens do have the same string as its hostname (isn't "pc1" still the
most popular host name (after "www") on the internet?)

  | And I also claim that the quality of the exchange
  | message-id generation algorithm is totally irrelevant to the purposes of
  | this discussion.

That's true - but on the other hand, I have not seen any messages that
relate to its quality - other than to assume it is as good as you say.

  | I completely agree that the presence or absence of a FQDN in the RHS of the
  | message-ID CAN make it more unique,

This is the problem.    Not "CAN" make it more unique, but "is essential
for it to have any expectation of being unique at all".   Just understand
that the FQDN that appears does *not* have to be the FQDN of the host
generating the message, and in many cases is perhaps better not to be.

  | however I further claim that it is not
  | sufficient.  Even the algorithm proposed in msg-format-07 fails to work on
  | many operating systems, even in the presense of a unique RHS.

Of course, but this is just as irrelevant as the quality of the exchange
LHS algorithm.    For the present purposes we have to assume that the
algorithm which is used to generate the LHS is adequate for the purpose.
If it isn't, that's simply a bug that has to be fixed.   If the text in
the draft describes a buggy algorithm (or a potentially buggy algorithm)
then, of course, that should be fixed too.

  | I believe that Robert Elz (and several others) hit ir exactly on the head:
  | If the LHS of the generator generates sufficiently unique message-IDs, then
  | the RHS might as well be a constant.

Yes.   But not just "any old constant".   It needs to be the one specific
constant that identifies the particular algorithm in use, and won't ever
identify any other (malicious users ignored).

  | It certainly does not need to be an addressable host,

No it doesn't.    But no-one (that I recall) is asking for it to be so.
"FQDN" does not in any way relate to "addressable host".   Sure, most
(but not all) addressable hosts will have FQDNs associated with them,
but it is trivial to make a whole set of FQDNs which have no hosts, no
A records, perhaps not even any DNS entries at all.   I control the domain
"munnari.oz.au".   Currently that domain has just A and MX records (maybe
HINFO, I forget).   But as it is my domain, I can make as many sub-domains
as I like, and for this week, I hereby allocate exchange.munnari.oz.au to
all microsoft exchange products, to use in any way they see fit - and I
prohibit anyone else from using it.   There, now you have a domain to use
(just for a week, but I suspect you have other sources of more permanent
domains if you need one).  There are no DNS entries at all for that domain,
and won't be - but it is allocated to you to use as you please, it will not
conflict (for that week) with any other FQDN in the universe.  You can
make sub-domains of it to your heart's content.

  | And if it ain't an addressable host, then
  | any string of characters works.

NO!

This is your misconception.   The name there MUST be a FQDN (whether it
exists in the DNS or not - no-one ever looks up a message-=id FQDN in the
DNS, so it doesn't need to be represented there - but it MUST be correctly
allocated).   And it MUST be yours to use for the purpose, either because
it is your own domain to start with, or because it has been "loaned" to
you for the purpose by the system on which the software is running (usually
by implication).   Even in the latter case, simply using the host's FQDN
(where it does have one) is not usually going to really be good enough,
unless this is to be the only message-id generating software on the system.
That is, if it is in a generally accessible (and used) library, which all
mailers actually use, or where there is only one message-id generating
piece of software on the host (which amounts to the same thing).  In other
cases, the FQDN of the host should probably be sub-domained to one sub-domain
for each (different) application which can generate message-ids (mail and
news).   So probably, I should really be generating "@sm893.munnari.oz.au"
or similar.   It happens that in my peculiar case I can get away without
that, as I control all the mailers and news systems (of which none remain)
on munnari.oz.au so I can ensure by other means that they will never
duplicate message-id's, but that's a luxury that can't normally be assumed.

  | All I'm trying to do is to get the semantics of message-id that were
  | specified in RFC822 and that exist in the current msg-format-07 draft to
  | continue.

You're missing the motivation for DRUMS.  If all we wanted to do was
rewrite 822, we wouldn't be bothering to do any of this at all.   The
aim here is to set down all the "extra stuff" that you have to know in
order to correctly implement SMTP as defined in 822 - all the little
bits of information that are missing from the 822 spec, but are known
to the general implementor community.   Correctly generating message-ids
(that is, the requirements on any implementation such that this is
an aim that can be achieved - not actually specifying how it must be
achieved beyond that) is certainly one of the issues that ought to be
dealt with.

The semantics of the message-id are one of those issues - it was always
the case that the RHS served to allow the algorithm that generates the
LHS string to only need to be defined within the domain of the RHS.
This is not new, but it was just always assumed that everyone would
"just know" that.

If you recall my first message in this thread, I said something like
"does anyone not understand that the FQDN on the RHS has to be a MUST
for the algorithm to work" ?   That's because I really didn't think that
(in drums anyway) there could be any possible doubt about that.  It seems
that I was wrong - which only emphasises the need for the draft to be
very explicit in setting out exactly what is required here, and not to
simply leave it to anyone who believes "my algorithm is good without the
RHS, so I won't be too worried about what gets put there" to totally
break the global message-id scheme.

kre