----- Original Message -----
From: "Paul Robinson" <paul(_at_)iconoplex(_dot_)co(_dot_)uk>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
However, the question rised was whether another system use this "tag"
for
distributed mail dupe processing as well:
"sorry, this message was already received"
But as the security around message-id's is quite weak, (IIRC they're
normally based on a hash of the current date/time with the server name
attached), I could just send you a load of mails with message-ids I know
will be valid from the server I hate over the next few hours... then
you're
rejecting mail in the misguided belief you've already seen it.
Again, that depends on the implementation and in this case, the network. No
one has SAID that a message id can not be used for dupe processing in
Internet EMAIL, in fact, it is quite possible. Now in the case if it was a
part the system and your system was broken (or you were goofing around with
the files) and you resent mail into the network, well, where I come from,
you would be yelled at and if it was a common situation would you, you would
be excommunicated, blocked or black listed. :-)
So, if you do this, message ID's need to become harder to spoof than TCP
sequence numbers. Or need to be signed with the sending server's key.
People are not going to spoof message-id, well, I don't see a reason for it
because you can already create unique ids.
Now, on the other hand, if we had a system where it was used for dupe
processing, if a spoofer tried to it and didn't follow you particular
server serialization, it can be used to detect a dupe or out of sequence
number.
This is OLD and PROVEN technology Paul. Just because it wasn't done in the
"Internet Email" does not mean it was ever discovered in other forms of
"netmail", designed, debated and implemented successfully. :-)
I personally believe if XML is considered, that it would be used as a
"wrapper" concept because as it was the case with the internet RFC 822
emergence as the new standard, there will be a big emphasis in the
"gateway" market to make it all possible. We can not assume that
everyone
immediately will change their systems to the new format. Converters
will be
written as the most feasible way to implement or integrate into the new
system or network.
I think that we should think completely freshly and as if no other
messaging
system had ever existed for now. Once we come up with the ideal protocol
as
we see it, then backfit what we need to make it easy to convert to, take
in
knowledge of what we know from the implementation of 821/822, etc.
If you will, allow me to give an analogy from the field of Political
Philosophy. ....
I understand your point.
You can design a home with doors and windows. Some people will lock them.
Some people live leaving them unlock or you may some people where Mom use to
say:
"Hey, What do you think this is? a FARM? Close the door!"
The point is, you still design the home with doors and windows and the
potential to lock them. How people live in them is another issue,
non-techical in nature.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com