Hi Day,
Hi Heimo,
Hi Howard E.,
Hi Howard S.,
About "16-Bit OS, dealing with Graphics and this mail-list" of
February 6, 7, 8 and 9; "survpc, dos, & mailers" of February 7 (2);
"eList via SOUP/QWK OLMR" of February 8 and "Is there a QWKMAIL email
website host?" of February 9:
HE> As far as I know, the terminating dot is never transmitted.
HC> ...that's part of the mail and POP3 RFCs. The mail (receiving)
HC> agents rely and depend on it.
MS> It may not come naturally but refering to the relevant ~RFC~s...
MS> Perhaps the dot is sometimes shown and some other times it isn't?
HC> RFC 822 is the basic one...
I checked ftp://ftp.isi.edu/in-notes/, it's there. I also tried to
search from http://www.rfc-editor.org/rfcsearch.html but many references
other than that came out... I collected ~RFC~s related to ~SMTP~, ~POP~
and ~IMAP~; i DownLoaded the ~STD~ documents as well. A search for one
of these strings was usefull: "single-line"/"dot-stuffed", "CRLF.CRLF",
"termination octet". The dot matter seems to be important for the ~POP~
and ~NNTP~ protocols but i didn't see anything significant in the ~IMAP~
protocol. As far as i'm concerned, i was under the impression that this
dot problem was a Unix thing; or perhaps, a Unix client/server thing...
I guess it's possible it became part of the protocols because this was a
"de-facto" practice in the early days when users were still ~TelNetting~
a lot? Anyway, ~STD~ #53 (around line 145) explains the dot convention.
HC> Brussels http://www.revobild.net
MS> ...seen BelgaCom somewhere else and i'm curious, has the FrancoMedia
MS> or any other `Fido'-like amateur messaging network survived?
HC> I have no idea, never had contact with the FIDOnets around here.
Ho? Fine, i thought there was nothing to be lost by just asking...
;^)
HC> I'm indeed subscribed to this legacy branch of the SurvPC list on an
HC> old "free" Belgacom (ex- and still very monoplistic nat.telco).
Ha. "Monoplistic" is a word which comes naturally when BelgaCom is
involved, it seems your people isn't too happy with it i would say! 8-o
HS> I thought they almost had me (i.e., the winblows people) with the
HS> new ``Auth'' authentication dialogues to authenticate yourself...
I'm not certain but the few little readings i made about ~IMAP~ are
telling me that it may be superior in terms of security because of ~TLS~
(i don't know what that is, actually)... The very existance of hackers,
the tentation for ~ISP~s to block ~IP~ port #25, maybe that's the reason
why many free ~SMTP~ hosts began to "up-grade" to WebMail, for one! %-7
HS> I still use Yarn and Readmail in dos to read my text... Readmail
HS> still undigests digests best for me...
I got `ReadMail' (at ftp://ftp.let.uu.nl/pub/users/jeroen/readmail/
rm50b76.zip - 166 Kb) and i must thank you for this suggestion: easy to
use with a menu and an optional mouse! Oh, and it was the most "polite"
application i ever saw: crashes with the grace of a delicate feather...
:)
I'm sorry i can't help you much with your RealAudio/~MP3~ quest, in
return. The only thing which i can think of is something i collected on
a diskette back in '98: `RAX.ZIP' (133 Kb, authored by David Lindauer).
That's a "semi-complete Real Audio file decoder for MSDOS", according to
the `ReadMe.TXT' file. Also, "it will decode the original 14.4Khz files
and the 28.8Khz files, but does not know how to decode some of the other
file formats that real audio is capable of". My copy of `RAX' includes:
`Main.C'/`RA144.C'/`RA288.C', `RAX.EXE'/`PLAY.EXE' and `README.TXT'. It
was released to the PUBLIC DOMAIN and seems to be based on the `RADeCode
v1.1' Amiga RealAudio decoder of January 22nd, 1998. This was meant for
8086 PCs and up and a peek into `Play.EXE' indicates that it was written
in Borland C++ programming language. The documentation mentions a Sound
Blaster sound-card and the `BLASTER' DOS environment variable would seem
to be checked by that same `Play.EXE'. `RA DeCoder v1.1' (or `RAX.EXE')
takes a .RA file as its input and generates a .DAT file as the output...
`RA DeCoder v2' (the very same `RAX.EXE', it seems) is for 28K8 bps data
instead of 14K4, the output is in a 8 Khz 16-Bit audio format. I hope i
have succeeded in making this as much a "pre-emptive" reply as possible.
;-)
Most obviously, it doesn't compare with the current streaming audio
SoftWare; there's just no streaming audio support at all, anyway... It
may still be available on the Net but i'll leave that matter to you. :)
Let me know if you can't find it, i can UpLoad it to some BBS. ;-)
HE> When I telnet to port 25 and 'end with a "." on a line by itself',
HE> how do I know whether the dot is actually included in the message or
HE> simply signifies to the server that I am done entering the data?
You thought the same as i but the command and delimitor both appear
to co-exist, in that case. I say it's like the chicken and egg paradox!
:)
HE> ...if I telnet to the shell and look at my mailbox... ...this file
HE> is in unix mailbox format, without the terminating dot.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Just a wild guess, perhaps it's not there since the termination was
done already: i mean, your file is ready, waiting to be accessed again.
HS> ...a script/program combination that tried to emulate imap access...
DB> One thing I liked about Arachne, which is next best to your method,
DB> was I easily found how to tag all the spam and del it without
DB> bothering to open any of it.
I can retrieve the same message again and again if i ~TelNet~ to my
~POP~ server but what i get is the whole message, unlike ~NNTP~ where it
is possible to look only at a header and then decide what may come next.
`Arachne' may be showing you only a header but the whole message is
already using some of your Hard-Disk space, i'm afraid... I'll bet it's
going to be noticeable the day you happen to be short of that space. :)
HC> First, almost all replies from a POP(3) server are terminated by a
HC> "dot-line" (except the ERROR messages). ...why do they change the
HC> well-convened (RFCs) mail format by slashing that very dot-line...
HC> Because it's clearly some post-processing... It would be much
HC> easier... ...to comply with the RFC-defined standards.
Hummm... I won't check the ~RFC~s but i thought i saw something on
the "From" marker in there. I can't tell if it was about ~POP~, though.
HE> ...the question of converting unix mailboxes to SOUP was raised.
That's because the available ~OLMR~ SoftWare supported ~SOUP~ and a
program as `Yarn' or `ReadMail' can act as a bridge via the Unix MailBox
format. The mail-list comes to me through `NetMail for DOS v2.12' or as
a simple ~TelNet~ (to ~IP~ port #119) capture, euh... the later will be
particularily handy if `NetMail' is always failing at the same point, by
the way! ;-) I had one of those inflated/ill posts recently, again!...
Selective deletion of the offending message shure solved this problem, i
was even able to capture it before i tried `NetMail' again, euh... It's
somewhere in a file (if i forgot to delete it once read)... This should
be instructive, is it possible `NetMail' will choke on bad termination?!
8-b,
DB> ...it would make sense, rather than have each user convert his
DB> download to qwkmail, to have that already done for everyone...
The .QWK mail-packet could certainly be sent to us via ~E-Mail~ and
we might be able to return .REP packets the same way back as well. I've
used it on a BBS and i believe SoftCON happens to be a BBS, it seems!...
The mail packets don't have to be in ~QWK~ format, ~SOUP~ will do nicely
if you ask me! :) Euh... But this amount of convenience has its price
at the moment and i can't put the SoftCON people on trial for that. ;-)
DB> My email continually gets interrupted with notices that the ppp
DB> driver lost the carrier from the host. ...qwkmail solves it.
In my experience, the most sturdy method that i know is to use some
~TelNet~ terminal emulator program which offers a file transfer protocol
such as `ZMoDem', or preferably, `Kermit'. The other methods often rely
on Error Detection/Correction being done at the HardWare and/or SoftWare
level(s) and i did see data being droped using a ~PPP~ connection with a
SoftWare-driven Zoom `VFXV32 14.4EX' ~RPI~ (RockWell) 2400 bps MoDem, it
couldn't support ~V42.BIS~/~MNP~ because no DOS ~PPP~ packet-driver that
i know has the ~RPI~ support built-in. Anyway, the story is i found out
that `Kermit' and the same-name terminal emulator could/will ensure safe
transfers where ~SMTP~/~POP3~ are doomed to fail relatively to my data's
integrity... My second choice is ~FTP~ and ~WEB~ publishing comes right
after that (only if you can retry the file transfer until it works). :)
What's nice with BBSes is that your transfer can fail and this will
not be a concern because the pointers remain untouched until the file is
successfully received (euh... Well, that's true of most good BBSes)!...
;-)
In any case, there already are BBSes around where the `ZMoDem' over
~TelNet~ problem, known to some DOS INet/BBS users, appears to have been
managed correctly. From the top of my head, i can think of 2 such BBSes
which will let me -= READ =- the SoftCON `DOS-Discuss' mail-list thru an
area called `RIME_DOS'. BSS NetWorks and ChowDaNet both offer the users
to transfer mail-packets thru their respective .QWK ~OLMR~ doors but i'm
afraid `RIME_DOS' is a *READ-ONLY* echo - i.e., I can't post from there!
Should anyone be curious about any of these BBSes, they're included
in a tiny list which i try to maintain on my ~WEB~ site (the 8088 link).
;-)
A quick solution which comes to the mind naturally would be to make
us able to read *AND* write via the participating BBSes once registered.
^^^^^^^^^^^^^^^
Salutations, :)
www3.sympatico.ca/bicephale
a/s Bicephale
... Sometimes, the cost of new features is too high, really! Is it not?
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
