At 00:31 2002-12-10 +0100, Ruud H.G. van Tol wrote:
LuKreme skribis:
> Jefferis Peterson:
>> Is there any time a LAN Ip would be or could be used as a legitimate
>> message ID? What if someone operated their own server?
> even if you operated your own server (as I do) the message-id should
> properly be formed from your domain name. (the message ID on this
> message will be <something(_at_)kreme(_dot_)com>).
On Usenet, a Message-ID should be globally unique, for at least a few years.
Uh, how did usenet creep into the picture?
FTR, a properly generated MessageID should *ALWAYS* be unique. In sensible
systems, the jumble of letters and numbers before the @ typically integrate
a timestamp component. Take the following from a recent post of mine to
this list:
Message-id:
<5(_dot_)1(_dot_)1(_dot_)6(_dot_)2(_dot_)20021209102542(_dot_)0877ee50(_at_)mail(_dot_)professional(_dot_)org>
^^^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
1 2 3 4
1 = mail client version #
2 = YYYYMMDDHHMMSS
3 = unknown, but it is a changing value
4 = mail host name
I could send another message two years from now, and there shouldn't be the
slightest chance that it'll have a conflicting messageid.
Back to the topic of IP-address hostname components in a messageid. If
someone is operating a private server on their own NAT LAN in compliance
with RFC1597, and let's say, they don't have a registered domain and/or
know that it is fruitless to set a hostname to point to a nonrouteable IP
address, so they don't bother setting a hostname WHICH CANNOT BE RESOLVED
AND THEREFORE WOULD BE REJECTED BY VERY BASIC SENDMAIL RULES, so instead,
they simply connect to their ISPs actual mail server to then relay the mail
(and to fetch mail, say using fetchmail, down to their local server), and
leave the local host with an IP rather than an actual host/domain. This
person would be masquerading their email to use their ISP email account on
sent mail, but that doesn't mean that they can use their ISP domain on
their local mail host (esp. since you can't connect to it from the outside
world at the address which it believes it is running at on the local net).
As such, RFC1597 addresses are *NOT* a reliable indicator of spam. If an
individual chooses to use them for that purpose, so be it -- but I don't
believe anyone here should encourage this behaviour.
Also note that the email client may compose the MessageID when it submits
the message to the mail server (so even if the mail server has a hostname,
if the MessageID is already present, it won't necessarily rewrite it), and
if the mail client usees the local host ip, you'll get this sort of result
as well. Note that neither RFC822 or 2822 dictate what host must generate
the MessageID, merely that it be unique according to the generating host:
4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID
This field contains a unique identifier (the local-part address unit)
which refers to THIS version of THIS message. The uniqueness of the
message identifier is guaranteed by the host which generates it. This
identifier is intended to be machine readable and not necessarily
meaningful to humans. A message identifier pertains to exactly one
instantiation of a particular message; subsequent revisions to the message
should each receive new message identifiers.
RFC2822 says pretty much the same thing. In fact, it provides the
following in the examples section:
From: John Doe <jdoe(_at_)machine(_dot_)example>
To: Mary Smith <mary(_at_)example(_dot_)net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234(_at_)local(_dot_)machine(_dot_)example>
This is a message just to say hello.
So, "Hello".
Note the Message-ID field doesn't contain a resolveable hostname/domain
portion.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail