In article <[EMAIL PROTECTED]>,
Chuck Simmons <[EMAIL PROTECTED]> writes:
>
> RFC1036 states that to conform to RFC822, a message-ID must contain the
> host domain where the message entered the network. This does not suggest
> server generation but rather client generation. RFC1036 otherwise does
> not state whether message-ID's should be client or server generated.
Yes and the domain the message entered the network is _not_ yahoo.com
or gmx.net. Thus the message id may not use any of these domain
names. IMHO, it was acceptable nonetheless with the explicit consent
of the owner of the name space, but that is usually not the case for
mozilla's message ids. At least, i have certainly no permission by
GMX to generate message ids within the domain gmx.net.
> Server generated ID's may be ambiguous to the client user. For example,
> many news servers providing leased access for customers of ISP's may
> have many aliases. However, the alias is defined at the ISP's DNS and
> not at the local DNS for the server. Thus the server will provide
> message ID's having nothing to do with the domain or network of origin.
> This is because the server simply does not know what alias was used to
> contact it since it is likely unaware that the aliases exist. Remember,
> the aliases are arbitrarily defined on the ISP's network. For example,
> when I used futureone.com, news.futureone.com was aliased to one of many
> *.supernews.com servers. The question here is whether messages I sent to
> news.futureone.com should have had <unique>@futureone.com for ID's (as
> indicated by RFC1036 or <unique>@supernews.com message-ID's?
Yes, but this doesn't matter, as long as the server that generates the
message id is allowed to do so and guarantees uniqueness within the
name space it uses. There is no need for having the message ids in
the name space of the hostname that the user used to contact the
server.
--
Rolf Krahl <[EMAIL PROTECTED]>
