Quoth Philip Hazel on Thu, Oct 28, 1999:
> That is why message ids usually have the host name after the @. There
> has been much discussion on various lists as to how to generate suitably
> unique message ids when you don't have a unique host name available.
The problem is that message IDs are created by the MUA. You
cannot change what Netscape Mail, for example, generates. And
the MUA doesn't know whether you are connected to the Net. So if
you are not, there is high probability that your MUA will
generate Message IDs which are not world-unique (e.g., have
"foo.local" after @ -- you don't know how many people will decide
to call their machine "foo.local").
So the job of making the Message IDs correct falls, I guess, on
MTA's shoulders. Perhaps it would be easy to do it using the
system filter, e.g.,
if "${if def:h_Message-Id {yes}}" is yes and
$h_Message-Id matches "@.*\\\\.local$" then
headers remove Message-Id
headers add "Message-Id: <${local_part:$h_Message-Id:}@${lookup{${domain:$h_Message-Id:}}dbm{/var/exim/data/msgid-hosts}{$value}}\n"
endif
and /var/exim/data/msgid-hosts contains lines such as:
foo.local: foo.remote.dom
bar.local: quux.another.dom
The ideal way is to choose "hostnames" in existing domains whose
admins you know, and you will be sure that no hostname ending
with ".nonexistant.friendly.dom" will ever appear on this planet,
not even on someone else's message IDs.
Another ideas include putting after your hostname things like:
.972.2.6412694.phone
.29.32.columbia.street.jerusalem.96583.israel.addr
.1122.3576.3847.1446.visa.01.2002.expiration.date.vadim.vygonets.name.credit.card
NOTE: The above snippets of system filter are not tested.
Vadik.
--
To the systems programmer, users and applications serve only to
provide a test load.
