cz at alembic.crystel.com
Wed Oct 7 18:50:46 CDT 2020
CC:Mail could run in two ways. For the longest time it was just a shared
file on a network server that all the clients pointed to. Well, a
directory, and this is part of the reason it got corrupted as hell.
Rebuilding CC:Mail usually required shutting down the PO (writing a file
that told the clients to go away) and rebuilding. That's why the gateway
systems worked, they just talked to the same folder and stuck files in
the input and output directories. The SMTP tool required a unix box to
send mail (it was too stupid to really do it by itself) and to CC:Mail
it looked like a "foreign" post office.
I think at the end they had a true client-server model, but by that time
Notes was a much better solution.
The other fun email system at the time was WordPerfect Office. That one
ran as an NLM and once again it was file based from the client but
corrupted a lot less. And once again SMTP was a foreign PO, and in fact
Crystelcom was founded as a way to use the Wordperfect Async Gateway to
hook up to a modem to the client's server that would call my house every
hour and deliver internet mail to my post office which also had a copy
of Wordperfect plus a SMTP gateway. And pick up their mail, at 14.4kbps
with compression it was pretty quick. A pair of Sun 386i's (beaker and
bunsen) then served as DNS servers for the client's domain as well as
smtp servers for outbound and inbound mail. I did the same thing for
Microsoft mail, but it sucked more and to be honest that was why I was
loathe to support CC:Mail.
For $100 a month it was a steal for a lot of small companies and
nonprofits to communicate on the Internet. And for me it was simple as
dirt, I just needed a pair of phone lines to handle the incoming calls
and mail would queue up. Outbound internet was a Trailblazer modem to my
ISP of the time running ppp from one of the 386i's.
If two clients called at the same time one would get a busy and would
call back later (5m). If the mail server crashed mail would just queue
and be delivered when I rebooted it. It was literally a "open mailbox,
hello check" and paid for a good chunk of the down payment on the house.
Oddly enough the most valuable thing was that companies registered their
domains (through me) years before the great rush. This is why a lot of
small non-profits have domain names that reflect their initials as
opposed to crap. I never charged a transfer fee when they finally got
their T1 lines, that would have been evil.
Ultimately closed it down when the web got popular. I thought of getting
big by going into massive debt and hooking in T1's to the customers but
the company was profitable, simple, it served its purpose and I was ok
with letting it go. Probably a wise decision, my ISP actually made a
Ah those were the days.
On 10/7/2020 4:13 PM, Gavin Scott via cctalk wrote:
> My recollection of the cc:Mail SMTP Gateway (that now sounds like the
> right name to me) was that it was definitely bidirectional with
> respect to SMTP/internet traffic. There were differences in that
> inbound and outbound processing were rather different internally IIRC,
> but that was pretty much transparent to the user. My recollection of
> cc:Mail itself was that it was indeed a full server that clients
> interacted with over a network connection. I *think* we ran it on
> Netware with IPX/SPX as the client network transport in those days
> (but again my memory could be faulty), and eventually got the SMTP
> Gateway to get internet gateway connectivity and it ran on a minimal
> PC system as a dedicated server. I seem to recall waiting a year or
> more for the SMTP Gateway to finally become available. It seemed like
> a rather half-assed solution compared to the Lotus Notes gateway etc.
> which I think may have run as native Netware NLMs rather than needing
> the kludgy PC gateway. This would all have been in like 1990-95-ish
> give-or-take I think.
> On Wed, Oct 7, 2020 at 2:57 PM Grant Taylor via cctalk
> <cctalk at classiccmp.org> wrote:
>> On 10/7/20 1:46 PM, Tomas By wrote:
>>> Well, theoretically, you could have another program that emulates
>>> the PO server side.
>> I think that we have different understandings of what the Post Office is
>> in older email systems.
>> To me, the Post Office, is a collection of files that live in a
>> directory structure. Said file / directory structure is then directly
>> accessed by the email client. As in the email client reads from and
>> writes to files, meaning that it does not talk to a program / daemon /
>> service across the network. It's just that this collection of files &
>> directories lived on a common network drive.
>>> It does not need to anything other than get the mails and talk to
>>> the client
>> But, based on my understanding, the cc:Mail client doesn't talk to a
>> server. It reads / writes files directly. Hence the need to have
>> something else, e.g. the gateway, communicate between the P.O. and the
>> rest of the world.
>> I don't see how you can avoid the P.O.'s file / directory structure.
>> Maybe I'm wrong.
>>> (over PC serial port).
>> Hum. That make make things more entertaining.
>> Is the serial port for communications between the cc:Mail client and the
>> cc:Mail P.O.? Or is the serial port how you will need <what ever> to
>> interface with the rest of the world?
>>> My understanding is that the SMTP gateway is out from PO only.
>> I don't know. The MS-Mail SMTP gateway that I messed with was both
>> inbound from the world and outbound to the world. But the cc:Mail
>> gateway could easily have been different. Of course, SMTP is not the
>> same thing as pulling from POP3 or IMAP. But, fortunately fetchmail (et
>> al.) can act as the gateway between POP3/IMAP and SMTP to talk to
>> another gateway between SMTP and cc:Mail P.O.
>> Moving parts (read: things that can go wrong), there are a lot of them. ;-)
>> Grant. . . .
>> unix || die
More information about the cctalk