qwk mail

Sep 9 22:40 UTC 1995

has grex ever considered qwk mail?

response 2 of 40:

Sep 12 02:40 UTC 1995

I think that if qwk were used for cf participation, then it would instead
ENCOURAGE joining the Grex community.  .QWK was used a few bbs's here at Va
Tech (boo BC!), and the format for a TG bbs isn't ALL that different.  They
might be unable to get onto new items using .QWK, tho, and either separate
calls per cf or some modification MAY be necesary for those in more than one
cf at a time.

response 4 of 40:

Sep 12 06:56 UTC 1995

        Hey, with as little participation as the cf's have, what could
it hurt?

response 6 of 40:

Sep 13 06:35 UTC 1995

My (admittedly imperfect) understanding is that QWK logs in for you, reads
discussion veryvery fast (essentially as fast as the host will send it) and
disconnects (the first time you use it).  On subsequent calls, YOUR responses
are uploaded at high speed, and new responses (since your last call) can be
retrieved.  In between calls, you read the retrieved responses, and make YOUR
responses.  I'm not sure if it has been, or even CAN, be addapted for
Picospan, and I'm not sure how much support for it is required at the host
end of the connection.  So far as I know, it IS available for DOS teminals,
and I'm pretty sure that at least one guy had it available at a bbs running
under OS/2.
  That is about all I know, but I *may* be abel to find out more, if no one
else knows who to talk to about it (NO guarentees).

response 8 of 40:

Sep 14 02:12 UTC 1995

Yes, it should.

response 10 of 40:

Sep 15 00:33 UTC 1995

   We've talked about offloading mail to another machine, but
the only way we can reasonably do that is to make sure we have
pop clients of all the popular mailers, such that people won't
have to get to another machine to do mail.  Having to do that
would be worse than what we have now, I'm afraid.  People are
confused enough as it is.

response 12 of 40:

Sep 15 03:03 UTC 1995

   I think that ultimately, the major subsystems will go onto
their own machines, news and mail being the top two.  There is
software for news already that makes inter-machine communications
just about seemless to the user, and I keep on hearing that pop
clients like pop-elm will be coming out soon.  With that in place
news and mail could go onto different machines.
   Now, as to the priority, I can't say...

response 14 of 40:

Sep 15 07:01 UTC 1995

Putting news on its own machine won't relieve the load on Grex,
it will only prevent the load from increasing. The load from news is 0 now.
Nevertheless, as STeve points out, this is straightforward and will be done.

Moving mail to its own machine is a great idea, but it will break
the custom filters that some people are running. We will have to
discuss this more. I think we need to do it. I thought a pop version of
elm was available already. I admit I don't know for certain.

response 16 of 40:

Sep 15 12:22 UTC 1995

Possibly.  It depends on how things are set up.

response 18 of 40:

Sep 16 04:19 UTC 1995

If we move the mail-transport function to a separate machine,
then it will run a POP server. One would have to run a mail client
on Grex that used POP. Some of our mail clients do not support POP, and
have no variant that does. Also one could no longer filter the mail
at the server as one can today.

Eudora is a POP client that runs on Macs and PCs. If we permitted
connections to the mail server over the internet, then the answer
would be yes. I personally favor permitting this also.

response 20 of 40:

Sep 16 09:24 UTC 1995

Running mail on a separate machine does not necasarily have to be implemented
with a POP server. There are several other methods that would work too.

response 22 of 40:

Sep 17 19:02 UTC 1995

I was only describing the most popular plan for this, coming from recent staff
meetings. Of course there are other ways. Even if we do POP, we can prevent
its use except from Grex's subnet, so the questions of (1) allowing POP
access from the internet to Grex, and (2) moving mail to another machine,
remain independent.

response 24 of 40:

Sep 22 05:57 UTC 1995

It all depends on what part of mail processing you're trying to move.
Very generally, mail processing could be divied into the following types
of load:
        outgoing mail shipment (sendmail)
        incoming mail shipment (sendmail)
        user specified mail processing (procmail)
        user inbox processing (inc)
        user mailbox reading (any mail browser)
        user mail composition (pico, comp, vi)
        user outbound mailing (post)
As normally used, pop ships the mail to the reader's machine, whereas
imap leaves the mail on the mail machine.  So, whereas imap splits
"mailbox reading" between the mail server and the client, pop puts
"mailbox reading" on the client machine.  On the other hand, that kind
of "mailbox reading" is actually done quite efficiently on one machine,
and pine is notoriously unkind.  From a system load perspective, it
would be much better to read mail locally using elm, than to use pine to
read it remotely.  Indeed, it's difficult to imagine any case where
reading mail remotely is of significant advantage.  Imap has a richer
set of semantics to support leaving thigns on the mail machine,
including the ability to create multiple mail folders and more.  That
makes it particularly well suited for use by heterogeneous mail clients
that don't share the same file space.  On the other hand, since all the
mail stays in the server, it means more network traffic to the mail
server.  If we don't plan to deploy direct network access to the mail
server, then imap's better support for heterogeneous mail clients isn't
of much use.  If we do plan to deploy direct network access, then we
better give careful consideration to the best use of our limited network
bandwidth.

Another additional consideration is this: with imap, we'd *have* to
treat the imap server as another permament file storage system that
deseves to be backed up just like grex; and that probably means another
tape unit or some sort of scsi a/b switch, & add'l staff administrative
time.