Re: Stupid Software Problem

[Stefan Jeglinski <jeglin@4PI.COM>]

> Now that I have learned that some folks on this list use e-mail software
> that doesn't allow them to edit their work, maybe I can also learn why
> mine seems to send two copies of my messages to this list. At least, my
> inbox contains two copies of the messages I upload to Phys-L. But it has
> only one copy of messages I send to other addresses.
>
> I use Netscape Communicator 4.51 operating under WinNT4.0 on a Micron
> Millennia Pentium II PC. I would think that any setting under
> Edit/Preferences/Mail&Newsgroups would apply to all outgoing messages.
> Not so?
>
> Do any of you receive two copies of my notes? Please don't answer that
> unless you can suggest a remedy. I appreciate it.


Here is a general theory (BTW, I am my company's e-mail admin, and so
I see a lot of e-mail-admin-list traffic regarding this kind of
question). This is very long, if you aren't interested, delete now!

Sorry to go to this kind of boring detail, but once you hear it, the
world of e-mail becomes much less mystifying. Apologies to those who
already know this. And although it's off-topic, I figure at least a
few would be interested in some details. I hate to say it, but it is
even a little fascinating. But also keep in mind, I am presenting a
simplistic discussion.

Anyway, to use the correspondent's example, when sending mail with
NC4.51, the browser must "open a connection" with a mail server. If
you are on a dialup link, this connection is to your ISP's server
through your modem/phone. If you are at a University, this connection
is likely to be to a university mail server through your ethernet
connection. Either way, opening a connection consists of a series of
rather dumb clear text transmissions from both the browser (client)
and the server (almost literally "hello, I am client Bob, who are
you?" "I am server John, nice to meet you." "great, I have some mail
for you." "super, give it to me." [send message] "thanks." "thanks."
"bye." "bye."). What these transmissions *should* be is described in
RFC821, an internet "standard." What these transmissions *are* in the
case of NC4.51 is the result of the mad programmers of NC4.51.
Likewise, the mail server is a part of these transmissions also. Most
writers of server software are pretty darn savvy about RFC821
(because most of those programmers were also the writers of RFC821),
but there are exceptions (we'll get to that later).

to read up on RFCs, see

<http://sslmit.unibo.it/hitchhikers.guide.html#RFCs>

and for the specific one here,

<http://www.bookcase.com/library/rfc/rfc-index-08xx.html>

Anyway, once a mail server successfully receives an e-mail from
NC4.51, it then parses the headers to figure out where it goes. If
the e-mail is to another local account, the server doesn't send it
anywhere, but when the other local client makes a connection, the
server delivers it. If it is to go outside, the server opens a
connection with another server out there (as described above), and
delivers the mail to that other server. All mediated by the rather
dumb clear-text handshaking.

Before continuing, let me add that a crucial component is the
so-called TCP-IP stack. A lay explanation of this is simply the
software embedded in your operating system which mediates traffic
between all your clients (mail included) and the outside internet. As
a general rule, clients don't talk to the internet, they talk to
their TCP-IP stack and are unaware of the internet's existence. I'm
taking certain liberties here, but the concept is sound. What's
important is that the TCP-IP stack is responsible for creating a
legal packet for transfer through the internet. Among the many things
required to create this packet is a parameter called TTL, time to
live. This is roughly the number of router hops the packet is to take
in trying to get to its destination. Each router that gets the packet
reduced the TTL by one and passes it on. If a router gets a packet
whose TTL is reduced to zero, the router does not pass it on, the
packet dies, and the TCP-IP stack has to send it again. If the
internet, that twisted mass of whatever it is out there, is causing
your packets to go all over Hades, one distinct possibility is that
your TTL is too small for current internet conditions. If you are a
geek, you know how to change this, but there are reasons to leave it
alone.

So, with this groundwork, here's the setup: Some client programmers
believe that once their message is delivered to the server, they
don't necessarily have to do the "thanks" "thanks" "bye" "bye" (ttbb)
part. This is called "broken client." Then there are some servers
that may have the same affliction. Much more rare, this is called
"broken server." Then, you have your TCP-IP stack. it has to properly
handle all server-client traffic, not just mail-related, and resend
packets whose TTL has expired etc. If it doesn't do this too well, it
is called "broken TCP-IP stack."

And now the punchline: some servers receive the mail, and if they are
dealing with a broken client or are broken themselves, somebody will
try to be smart and decide when they can send on a message anyway.
But there is no protocol for additional discussion of this. You may
therefore have a client, which because it -thinks- that its
connection was broken before ttbb (and maybe it actually -was-), it
will send it again (invisibly to you). Likewise in server-to-server
communication, a similar thing may happen. This is just one possible
explanation of your problem. There are further possibilities, many of
which are not due to broken clients or servers. This is known as
"broken internet."

And now for some religion :-)

Browsers have never been known as really good e-mail clients. Not
only are a number of them broken in one way or another (some minorly,
some majorly), but they have tended to further such cuteness as html
e-mail instead of plain text e-mail. If you really want to do it up
right, use a "real" e-mail client. Eudora comes to mind. And, if you
were to follow e-mail administrators' discussions, you will find a
lot of talk about other broken behaviors, from clients to servers to
TCP-IP stacks. Like it or not, a lot of this discussion revolves
around a variety of pseudo-proprietary sometimes-barely-compliant
software from a certain massive Software Company headquartered in the
NorthWest.

Since you imply the problem is consistent, the issue is not likely to
be internet conditions. Since you also imply it is related to this
list, I suspect it is a direct result of some client-server-OS
interaction, some of which may be on your machine, but only when
interacting with certain servers and/or certain OS versions. Since
you don't control the list server, your remedy is to get either a
different client or a different connection to the internet. Extreme
cases can be solved with a different OS.


HTH. Apologies to those who don't appreciate the long off-topic post.



Stefan Jeglinski