DECUServe Journal March issue
Sharon Frey
=====================
March, 1994
Table of Contents
-----------------
Technical Information ................................. 39
Article
Is fiber optic cable truly immune from tapping? .... 2
You know you've been hacking too long when... ...... 5
INDEXF Ownership (init'ed without /SYSTEM) ......... 8
Sessions Notes on CD! .............................. 11
General Mail Confusion ............................. 18
March, 1994 The DECUServe Journal Page: 2
Is fiber optic cable truly immune from tapping?
-----------------------------------------------
The following article is an extract of the DECUServe Security
conference topic 270. The discussion occurred between
October 26, 1993 and October 28, 1993.
By Terry Kennedy, Matt Holdrege, Shawn Allin, Jeffrey Sue, Mark Shumaker,
Jorma Tapola, Jean-Francois Mezei, David Mischler, Dale Coy, Don Boelling
(10/26/93 Kennedy)
------------------
A recent issue of "Cabling Installation & Maintenance" (June/July 1993)
has an advertisement (inside front cover) for one of those headsets that works
over fiber optic cable that installers use. So far, nothing new. However, the ad
goes on to say "Simply clip onto single mode fiber for instant communication
without accessing the fiber end" and the body copy says "tap anywhere onto your
network to establish communication!". The picture shows a long skinny device
with a slit labeled "push up to insert fiber". The company is EXFO
Electro-Optical Engineering at 418-683-0211 (that's in Canada) or 800-663-EXFO.
If this isn't a hoax, it implies that fiber optic cable may in fact not
be as immune to tapping as [I for one] previously thought. While there is a big
difference between 3Khz audio and (for example) T3 data rates, the fact that it
apparently works for audio may be enough to encourage development of systems
that can tap high-speed fiber.
(10/27/93 Holdrege: Curious)
-----------------------------
I saw a similar ad in Lightwave and I too was skeptical. Fiber optics work
by reflecting light along the inner surface of the cable. I don't see how you
could "tap" it unless you used a repeater.
Maybe it does some kind of modulation of the exterior of the cable?
(10/27/93 Kennedy: Got me... )
-------------------------------
Yup - that's what I thought. However, it might be possible to inject enough
light into a dark fiber by putting a sharp kink in the fiber. However, that
wouldn't explain how it gets the received audio.
>Maybe it does some kind of modulation of the exterior of the cable?
Got me. They're claiming 120Km (what is that, about 75 miles?) range with
one of these beasties. I don't know of anything that will go that far on the
outside of the cable (including tying the cable to a bulldozer and pulling
8-).
March, 1994 The DECUServe Journal Page: 3
(10/27/93 Allin: Might be possible)
------------------------------------
I read an article a couple of years ago that reported on devices being
developed by the "good" and "bad" guys that could eavesdrop on a fibre link in a
non-intrusive fashion. As I recall it involved placing the cable into a jig
that bent it enough to allow a small percentage of the light to escape, but not
enough to be noticed. No idea what the progress has been since, though.
(10/27/93 Sue: which bits are the important ones?)
---------------------------------------------------
Just make sure that the percentage of light carrying my paycheck reaches
it's proper destination.
(10/27/93 Shumaker: _Nothing_ is completely secure.)
-----------------------------------------------------
I was listening in on the fringes of an informal discussion about tapping
fiber optic cable (conducted by some of our Cable group R&D people) some months
ago. The consensus was that any fiber transmission scheme which requires 100%
internal reflection (or nearly so) at the surface of the fiber could be tapped
for reading by making a small scratch, allowing a small amount of light to leak
out (onto a light sensor of some type). Fibers of the type which have a core of
one type of glass with a cladding of a different type, and which rely on
internal reflection at the interface, would be less affected by a surface
scratch. The discussion didn't address tapping for transmission; so I can't
comment on this even second-hand.
(10/27/93 Tapola: It can be done)
----------------------------------
This is my favorite subject!
Basics of Fiber optic cable (for those who don't know it yet):
Light inside cable sees walls of cable as mirrors. That based on physics;
When light move from one material to an other, with different optical density,
it reflect about 100% when angel is large enough. Angel depends on the optical
densities of the material. You can see this effect on aquarium walls.
First fiber optic cables where homogeneous material, and light bounched
only from the walls. That caused interference, which reduced usable frequencies
in the cable.
Newer cable are made out of multiple layers, with different optical
densities. That will minimize interference, and also concentrate light in the
middle of the cable.
Eavesdropping in the homogeneous cables is easier to do and explain, but
similar kind of methods could be used also in the newer type.
By bending the cable you theoretical will reach point where light wount
reflect anymore back to cable, but you could 'help' cable to reach that point
before it breaks, by using suitable material with close optical density to the
cable it self. You could also use gel to have good connection between cable and
receiver. Also 'scratching' a small layer of the cable could be used. After you
got light out from the cable you could 'read it' and reflect it back to it.
March, 1994 The DECUServe Journal Page: 4
One way to make those long cable lines secure, is to wrap them in high
voltage lines, used to transfer electricity. I'll guess that eavesdroppers are
reluctant to put taps in those;-)
(10/27/93 Mezei: Are we worrying about this for nothing ?)
-----------------------------------------------------------
I am aware that no transmission medium is totally secure.
However, should we worry about fibers not being quite 100% secure ?
Are there many occurences of people tapping copper lines ? Are there
occurences of people tapping fiber lines ? Since most data that requires
security is usually encrypted as it leaves a secure building, I do not know if
worrying about the security of fiber or copper is woth it.
Am I wrong is assuming that the risk of eavesdropping even on copper is
minimal ?
(10/27/93 Mischler: Some people worry about tapping...)
--------------------------------------------------------
I know of a place that used copper cables in soldered conduit that was
pressurized, and had pressure drop alarms. I don't know if they still do this.
They might be using fiber now. Maybe because they were told it couldn't be
tapped (since disproven).
Of course, this was the kind of place where you needed a "funny" clearance
and the guards had automatic weapons.
(10/27/93 Coy: How much is it worth?)
--------------------------------------
>Are there many occurences of people tapping copper lines ? Are there
>occurences of people tapping fiber lines ? Since most data that
Yes, Yes.
>Am I wrong is assuming that the risk of eavesdropping even on copper is
>minimal ?
Yes.
(10/28/93 Sue: I thought copper didn't need intrusive tap)
-----------------------------------------------------------
Do you even need an intrusive tap with copper? I'd always heard that they
could be picked-up from a distance with a good receiver & what-not - basically
stuff that anyone with $$$ could get.
(10/28/93 Boelling: Eavesdropping does happen!)
------------------------------------------------
From someone whose job it is to investigate incidents like the ones
in question above. Yes it does happen. No, most data that should be protected is
not encrypted, because of the cost factor. (Which is getting better with new
March, 1994 The DECUServe Journal Page: 5
technology) And yes you are wrong. The risk is high.
Electronic eavesdropping is easy, cheap and is usually done be an employee
already working for your company. You won't find too many "spies" coming in and
attaching monitoring equipment to your fiber or copper, however it does happen.
Most eavesdropping is done by an employee who already has access. He may be paid
by someone else or is looking to "get the goods" on somebody or many other
reasons. But eavesdropping does happen and is a concern.
(10/28/93 Mezei: Is fiber immune to inside jobs ? NO !)
--------------------------------------------------------
So, the risk of eavesdropping does not reside outside the building but
rather inside the building and done by an insider, right ?
So, if the risk is within the company, is it worth the trouble of protecting
data communiocations lines that link buildings ? Would the folks likely to
eavesdrop now, also have the equipment and access to the cables even with fiber?
I agree that using fiber does make it harder to tap, but if the risk of
eavesdropping resides within the company, and by people who currently have
access to the info/cables/equipment to do so, is it worth the trouble to instal
fiber for the sole purpose of protecting the data ?
(10/28/93 Coy: Risk is not a simple subject)
---------------------------------------------
I don't know quite how we got from a discussion of fiber to generalized
discussion of communications security.
> So, the risk of eavesdropping does not reside outside the building but
> rather inside the building and done by an insider, right ?
No, that is not correct. Therefore, your other conclusions and questions
have no basis.
You know you've been hacking too long when...
---------------------------------------------
The following article is an extract of the DECUServe Shop_Talk
conference topic 120. The conversation occurred between
December 16, 1993 and January 6, 1994.
By Charlie Byrne, John Gorentz, Rob Brown, Gail Walker, Sharon Frey, Dan Wing,
Michael Baydoun, Larry Kilgallen, Rick Carter, Terry Kennedy, Kevin Amgley,
Brian Tillman, Rob Brooks, Joe Crum, Jane Furze, Richard Norman
(12/16/93 Byrne)
----------------
You know you've been hacking too long when...
I was driving home last night after 14 straight hours of intensive activity
on multiple Motif windows. So I start thinking about something, and then a
minute later I start thinking about something different. And then I say to
myself, "Gee what was that I was just thinking about a second ago" and my mind
March, 1994 The DECUServe Journal Page: 6
says to me: Grab the mouse, switch to the other window, drag that old thought
and paste it into the current window. But I instantly realize of course there is
no mouse or other window or anything, just my silly brain playing tricks on me.
:-)
(12/16/93 Gorentz: in your dreams)
-----------------------------------
I've done similar things with mice when half dreaming, half awake.
But here's another story. In my pre-VMS days I was working on a piece
of software for a grad student - an "optimal foraging" model. It was one of
those things you want to be right when the results are published - or someone's
career reputation could be damaged.
One night I dreamt that I found a problem in the program -- some boundary
condition I wasn't handling right, or something of the sort. When I woke I
remembered the dream, though some of the details were starting to become
indistinct. I went to work, looked at the code, and sure enough, there was a
serious problem that needed fixing.
I'm glad that nowadays grad students do their own programming. It helps
me sleep easier.
(12/16/93 Brown)
----------------
In 1978 I was deeply into RSX assembler programming.
I bought a new car. I short time later, I noticed that the odometere
was at 7777 and thought "Wow! Rolling over 10000 already."
Working in octal too much I guess.
(12/16/93 Walker: bugs in dreams)
----------------------------------
> One night I dreamt that I found a problem in the program -- some
> boundary condition I wasn't handling right, or something of the sort.
I had some similar experiences years ago when I worked on my first project
on my first job after college. On 2 separate occasions I dreamt about a bug in
my program. When I woke up I did remeber the dream and was able to determine a
likely solution before going back to sleep. The second time this happened, I
thought about possible fixes (some complex) and didn't fall back to sleep until
I realized that there was a simple fix. In both cases, the dreams were accurate
and I fixed the problems the next day using the fixes I'd thought of right after
the dream. Both bugs were ones I was not aware of before the dreams.
This was in 1976-77 - I don't think it's happened since. Perhaps I've
gotten better at realizing something is wrong sooner, or perhaps I now don't
realize it at all!
(12/16/93 Frey: Connection anxiety)
------------------------------------
I frequently find myself wanting to do ^T to see what time it
is...
... in shopping malls and such.
March, 1994 The DECUServe Journal Page: 7
(12/16/93 Baydoun)
------------------
And I have this urge to call work whenever I hear a beeping noise
(12/16/93 Wing: different strokes for different folks)
-------------------------------------------------------
My urge is to throw little black devices with LCDs on them....
(12/16/93 Kilgallen)
--------------------
Dreams at night about character manipulation...
with specific TECO commands...
...and getting the commands right.
(12/16/93 Carter: Slight tangent about famous dream discovery)
---------------------------------------------------------------
I can't recall his name, but the guy who figured out the structure of
benzene (it's a ring of carbon atoms) just couldn't figure out how they could go
together for months. Then one night he had a dream about a snake eating its own
tail.
(12/16/93 Kennedy: Sewing machine, too, I think)
-------------------------------------------------
I seem to recall that the person who invented the sewing machine (after
struggling with various designs for a long time) solved the problem after having
a dream about natives with spears with holes in their tips...
(12/17/93 Angley: Digressing even further on accidental discoveries)
---------------------------------------------------------------------
The guy who figured out how to make synthetic fibers more comfortable to
wear did so after many, many hours of frustration and note-taking and
calculating on a legal pad. As each idea hit a roadblock, he crumpled up the
paper and tossed in the trash can. The more frustrated he got, the tighter he
tended to crumple the paper.
Finally, sunk in his chair with despair, he heard noises from the trash
can. He noticed the papers were unravelling a bit. Fascinated, he took wads of
paper from the can, and tried to flatten them out. Try as he could, and even
using presses and irons and such, he could never get the paper to return to its
original shape - it always had some degree of texture. So was born the process
of textured polyester - the thread is crumpled up tightly and then uncrumpled to
give it some variation in texture.
(12/20/93 Tillman: Happens in the movies, too.)
------------------------------------------------
These sound like a scene right out of "Lorenzo's Oil".
March, 1994 The DECUServe Journal Page: 8
(12/21/93 Brooks)
-----------------
> I can't recall his name, but the guy who figured out the structure of
Kekule.
(1/4/94 Crum: better late than never)
--------------------------------------
I had been working on a curve-fitting program algorithm for several days
(on my first job in 1975 or so), but had been unable to get it right. I started
to drift off to sleep one night, and the solution appeared in my mind. I woke
myself up (was not quite asleep yet), and wrote it down, then tested it the next
day and it worked. Strange.
I know this thread is a little stale, but what the heck.
(1/5/94 Furze: Don't underestimate your unconcious mind)
---------------------------------------------------------
A few years back I did some research into non-verbal communication. A well
known hypnotherapist I studied with frequently taught people to use 'dream time'
for problem resolution. A common technique was to set yourself a task of
finding the answer to a problem just before you go to sleep. When you wake up,
think about what ever you last remember dreaming. You often have to think
'between the lines' because the unconcious mind is very comfortable
communicating in analogies.
It took some practice to get a handle on the skill but now I find that with
regular practice, it is quite effective for me. If I'm serious about the
problem and wanting to find a solution and the quesiton is realistic for me to
resolve (ie. not a question like "What is the meaning of life?") I frequently
find the answer 'comes to me' when I first wake up or sometime during the next
day.
(1/6/94 Norman)
---------------
Somebody posted a top ten list recently on this subject. The one that rang
true for me was:
You know you've been hacking too long when the resale value for computer
gear is more than for your car.
Also, in my case my insurance rider for my computers is more than for my
house, since I live in a MoHo.
INDEXF Ownership (init'ed without /SYSTEM)
------------------------------------------
The following article is an extract of the DECUServe VMS
conference topic 1039. The discussion occurred between
August 7, 1990 and August 9, 1990.
By Linwood Ferguson, Mark Hyde
March, 1994 The DECUServe Journal Page: 9
(08/07/90 Ferguson)
-----------------
How can I change the ownership of the INDEXF file on a volume?
I've noticed some volumes we have were initialzied without the /SYSTEM, and
are owned by another user. It's possible to SET VOLUME/OWNER and SET FILE/OWNER
for each file, but INDEXF is always open.
This seems to permit that person to have read/write access to the INDEXF
file even though they may not be able to access other files on the disk at all.
Are there other implications I may have missed (e.g. that the SET VOL/OWN and
SET FILE/OWN didn't fix that INIT/SYSTEM would have)?
Is there some way to fix this short of recreating the contents of the disk?
Or writing a program (I suspect I might be able to do this with ACP calls?).
(08/08/90 Hyde: 2 possibilities)
---------------------------------
You can do an image backup of the disk to a save set, re-initialize it with
/SYSTEM etc, then restore the backup without the /IMAGE qualifier. Something
like:
$ BACKUP/IMAGE disk: device:saveset.bck/SAVE_SET
$ DISMOUNT disk:
$ INITIALIZE/SYSTEM disk: label
$ MOUNT disk: label
$ BACKUP device:saveset.bck/SAVE_SET disk:[*...]*.*;*/OWNER=ORIGINAL
The brave can explore the ACP QIO functions and change the owner with a
program. DSNlink should have an article that discusses this.
(08/09/90 Ferguson: Spare time can fix anything)
-------------------------------------------------
Right. That one I knew. I hoped there was some simple way I was missing.
>The brave can explore the ACP QIO functions and change the owner
And those with lots of spare time, which right now I lack.
(08/09/90 Hyde: time-saver)
----------------------------
Here's an example I found in our database. It may also be one of the
examples in DSNlink. I just used and it worked on my 5.3-1 system.
; SET_OWNER.MAR
;
; This program uses the ACP QIO function to modify the file
; ownership of INDEXF.SYS to UIC [1,4]. Before running this
; program, modify the line that contains "<<<--" to specify the
; disk that needs modifying.
;
March, 1994 The DECUServe Journal Page: 10
;
.title set_owner ; set non-interlocked ownership of file
$atrdef ; Attributes definition
$fibdef ; File Information Block Definition
$fiddef ; File ID definitions
$iodef ; I/O Function codes
fid: .word FID$C_INDEXF ; File ID of INDEXF.SYS
.word FID$C_INDEXF
.word 0
UIC: .word ^O4 ; Member UIC of [1,4] (octal)
.word ^O1 ; Group UIC of [1,4] (octal)
atr_list: ; User attributes list
.word atr$s_uic ; length
.word atr$c_uic ; code
.address uic ; buffer Address
.long 0 ; End Of List
fib_desc: ; FIB Descriptor
.long fib$c_accdata ; Short block (access data)
.address fib
fib: .blkb fib$c_accdata ; Only need the short block
iosb: .quad 0 ; Status of IO
Channel: ; Channel to the device
.word 0
Disk: .ascid /DISK$LIBRARY:/ ; <<<-- Insert disk name here
; Main Entry point of Code
;
.entry set_owner, ^m<>
$assign_s chan=channel, - ; Assign a channel to the disk
devnam=disk
blbs r0, 10$ ; Check for errors
5$: ret
10$: movl #fib$m_write!fib$m_nolock,-
fib+fib$l_acctl ; Allow write and nolocked access
movl fid, fib+fib$w_fid ; Set the File Id In question
movw fid+fid$w_rvn, fib+fib$w_fid_rvn
$qiow_s chan=channel, - ; Perform the QIO function
func=#io$_modify, - ; to modify the file
iosb=iosb,- ; return status
p1=fib_desc, - ; This file
p5=#atr_list ; These attributes
blbc r0,5$ ; set the final condition
movzwl iosb, r0 ; code (worst error)
brb 5$
.end set_owner
March, 1994 The DECUServe Journal Page: 11
Sessions Notes on CD!!!
-----------------------
The following article is an extract of the DECUServe
Symposia_Public conference topic 275. This discussion
occurred between October 7, 1993 and October 22, 1993.
By Hal Dell, Larry Kilgallen, Howard Siegel, Jeff Killeen, Pierre Hahn,
Dale Coy, Bret Wortman, Pete Sivia, Steve Denning, Mike Durkin,
Rick Wrigley, Bill Mayhew, Petri Backstrom, Charlie Luce Jr., Dave Gudewicz,
Bob Melford, Bart Lederman, Michael Baydoun, Gary McCready, Steve Cordiviola
(10/07/93 Dell)
---------------
I wanted to introduce a new product which will be available for this
upcoming Symposium in December: Session Notes on CDrom.
DISCLAIMER!!! Please note the following is the current list of deliverables
for December, as the symposium gets closer the content and features will firm up
as with any DECUS volunteer activity. I just wanted to point out what I say now
my not be what I devliver in V1.0.
THE MARKET
===========
Clearly the world has begun the shift, or maybe the grinding of gears, to
electronic media. Of course many issues remain to be solved like
copyright, usage of material, document exchange and media format.
DECUS too has been in the business of producing Tapes and CD's, through
the Library, for the exchange of programs. As far as I know this project
is the first attempt to provide digital non-program documents to the
DECUS community. I have many ideas about what can be placed on the
CD given the 600mb capacity... Other ideas include Audio and Video...
However, we will save that disucssion for another time.
Everyone is talking about getting a CD drive on one kind of system
on another... DEC will only deliver software on CD media on AXP plaforms.
Also, I can help seeing more and more publications being made available on
CDrom... Just take a look at what Ziff-Davis is doing... In this months
issue of PC Mag. I've noticed a advert. campaign with a range of CDrom
products.
Not only can you read them at afforable prices (~$300 for bare drive) but
Cdrom recorder have become an off-the-shelf consumer product!! At the
symposium in December we will be using a network capable Cdrom writer which
will be provided by Virtual Microsystems. The product is an enhanced
InfoServer 1000 with additional hardware to support CD recordable.
THE DECUS PRODUCT
=================
The CD will contain the same material provided by Session Note Editors to
the Session Notes In Print/On Demand Print process. The CD will contain
images of scanned pages and stored in at least TIFF format. Other formats
March, 1994 The DECUServe Journal Page: 12
of interest are PS (postscript), and WMF (Windows MetaFile). Given
my limited capability I'm looking providing support for Windows 3.1
and probally OpenVms character cell terminals. I'm open to assistance
for someone to take the software an compile, test and debug under AXP.
The program will be written in DEC C.
Under Windows 3.1 you will be able to view on-line and print the
Session Notes to any printer supported by Windows. As above the format will
be TIFF and possibly WMF. The program will be written in Visual Basic
3.0 which will provide an easy to use and easy to maintain user interface.
Access to the documents will be searchable via a database containing
the Author, Title, Date/Time of presentation, and Abstract content.
I may, if time allows, perform an image-to-text conversion of the
Session Notes for content based retrevial.
Under VMS there will be much less support given my lack of knowledge
of Motif. A terminal interface will be available to select and print
a document if you have a PS printer. Also, the interface will tell you
the name of the file such that you can view the document in a Motif
window if you have a PS viewer. In the future I would like to store the
documents in one format, probally, TIFF and convert the documents on the
fly to PS. Or maybe the other way round. Some software from GNU, Gohost
Script, would do this very nicely. I would be interested in anyone who
would like to collaborate with me to provide a Motif interface and/or
terminal interface so that I could concentrate on the Windows interface.
Of course I am very interested in keeping the interfaces look and feel the
same!
PRICE and AVAILABILITY
======================
The CD will be available for $50 via the Library. Delivery will be 4-8
weeks after the close of symposia.
I will also be doing a BOF about this process sometime during the week.
And if there is interest I'll turn it into a session for next May/June.
As you know my success depends on the material, that is published by
the Session Note Editors, provided by the speakers. If you are a
speaker I envite you to send you handout materials to your Session Note
Editor on time.
If you have any ideas, questions, concerns or comments I would be
interested to here about them.
thanks for your support,
hal dell...
Session Notes ON Demand / ON CD Coordinator
March, 1994 The DECUServe Journal Page: 13
(10/07/93 Kilgallen)
--------------------
To me the priority of interfaces would be:
Motif
Macintosh
===================
Windows (not a contender)
We have _considered_ getting a CDROM drive for Macintosh, but have plenty of
CDROM drives for VMS.
(10/09/93 Siegel: Another plug for the Mac)
--------------------------------------------
Yes. For me Windows is an also ran. And with Apple really pushing into the
multimedia area, CD drives on Macs are becoming much to common to ignore.
(10/09/93 Killeen: A vote for windows)
---------------------------------------
(10/09/93 Hahn: WINDOWS vote)
------------------------------
For me MAC is something I eat, WINDOWS is what I need.
(10/09/93 Coy: Motif)
----------------------
Since we seem to be voting...
(10/09/93 Wortman: Ditto)
--------------------------
In order, to my mind:
Motif
Windows
Mac
I love Macs too, and hate Windows, but let's face facts.
(10/10/93 Dell: Limited Platform Support for Version 1.0)
----------------------------------------------------------
Thanks for your votes todate... I do invision support for many platforms and
GUI's in the future... However, I've been unable to make arrangements with any
commerical software company (Including Digital) the could provide software that
would allow the database to be shared across multiple platforms and GUI's.
So at this point, unless other volunteers step forward, the software to be
delivered for the first version of the sessions notes on CD will be Windows 3.1
and VAX VMS Character Cell point and print...
March, 1994 The DECUServe Journal Page: 14
What do you think about DEC Bookreader? Would you by a MAC or PC bookreader
if one existed? Would you like a bundle with Bookreader for your MAC/PC with the
sessions notes? I had some discussions with Digital around using the Motif based
Bookreader!!!
Other then type of platforms.. What kind of printers are popular out there..
Postscript? HP Laser XXX? DEC LN*?
What kind of file format would you use for storing images? TIFF? CDA? ODA?
WMF? GIF? What's good on MAC?
(10/10/93 Sivia)
----------------
This is a great idea! Many thanks for working on it.
As to...
>What do you think about DEC Bookreader? Would you by a MAC or PC
>bookreader if one existed? Would you like a bundle with Bookreader
>for your MAC/PC with the sessions notes? I had some discussions with
Bookreader access is a nice idea, but lower on my overall priority scheme
than MS-Windows, then Motif CDA access. However, a bundle with Mac and/or PC
Bookreader plus session notes? Yes!! (Suppose this would mean Digital would
allow us to use the Mac and/or PC Bookreader with things other than the session
notes??)
>Other then type of platforms.. What kind of printers are popular out
>there... Postscript? HP Laser XXX? DEC LN*?
PostScript. PostScript. PostScript.... Even our HPs don't stick around
long without a PostScript cartridge stuffed in the front of 'em.
(10/10/93 Denning: One more vote)
----------------------------------
Responses apply to me personally only.
>What do you think about DEC Bookreader? Would you by a MAC or PC
>bookreader if one existed? Would you like a bundle with Bookreader
>for your MAC/PC with the sessions notes? I had some discussions with
I don't have Bookreader, and have no plans to purchase any kind of Mac or PC.
>Other then type of platforms.. What kind of printers are popular out
>there... Postscript? HP Laser XXX? DEC LN*?
I use an HP LaserJet IIP. I don't use Postscript at all. I recently
checked into upgrading my IIP to accept Postscript, and learned it would cost
$700, which I can't justify for DECUS things only.
>What kind of file format would you use for storing images?
>TIFF? CDA? ODA? WMF? GIF? What's good on MAC?
March, 1994 The DECUServe Journal Page: 15
I'd prefer TeX or LaTeX files. If these aren't available, I'd prefer ASCII
text.
(10/10/93 Dell: Questions on format!?!?!?!)
--------------------------------------------
I'm not sure I quite understand....
>I'd prefer TeX or LaTeX files. If these aren't available, I'd prefer ASCII
>text.
The Session Notes are scanned in as images... Does TeX or LaTex have
some kind of image format? I thought *Tex* was a page layout system?
What do you mean by I'd prefer ASCII text? I don't have access to the
source documents... Just the scanned Image!!!
(10/10/93 Denning: formats)
----------------------------
Probably I don't know what an image is in this context. A few people use
Tex to produce their handouts, most use something else.
I guess the larger point is, many DECUS folks work for large companies and
have access to the latest expensive hardware and software. I work for myself,
and I don't. In general I can't afford to buy things from Digital, I have to
plug into the market for used equipment that is several years old, and would be
considered by some to be outmoded. As for buying layered software from DEC,
forget it.
(10/11/93 Wrigley: Another vote for windows.)
----------------------------------------------
I too would vote for Windows 3.1.
FWIW, should we consider HPGL with a 150 dpi density for those folks who
have laserjet printers with no extra memory.
(10/11/93 Durkin: Here's some info on Mactivity)
-------------------------------------------------
FWIW, the folks responsible for building the Mactivity CDROM, containing
most of the slides/presentations from the sessions, saw an opportunity. They
convinced some software companies to distribute pared down versions of their
software to enable attendees to view the material in the comfort of their own
Mac. They also provided demo software from a number of 3rd Party Software
companies. They also provided the 3.2 release of Disinfectant and some other
nice utilities.
It is quite possible the show organizers request any potential speakers to
develop their presentations using one of the packages provided on the CDROM ?
Then again, they might import flat text and tailor themselves after the show ?
Whichever, you might consider contacting them yourself to determine how they
built their CDROM.
Winehouse Computer Company
20 North Santa Cruz Avenue
Los Gatos, CA 95030-5917
(408) 354-2500
I have no affiliation with this outfit, other than being a satisfied
Mactivity attendee and consumer of their CDROM package. ;-)
March, 1994 The DECUServe Journal Page: 16
(10/11/93 Mayhew)
-----------------
I *think* I saw an announcement about 3 months ago for a Bookreader for
MS-Windows product from Digital. I remember it being "inexpensive". I have not
seen a thing about it since then.
(10/11/93 Coy: The question is "image viewers")
------------------------------------------------
>What do you think about DEC Bookreader? Would you by a MAC or PC
>bookreader if one existed?
But in any case, the session notes are not going to be in Bookreader
format.
The following is "at first approximation", and not universally true, but
close enough for this discussion.
Session notes are submitted ON PAPER. Therefore, for electronic access
they get SCANNED. The result is some kind of IMAGE file(s).
Even if you asked for them to be submitted "as prepared", you would get
everything from typewritten hardcopy, through 100 various wordprocessors and
presentation packages on desktop platforms, etc...
(10/11/93 Sivia: 'twas here, now gone)
---------------------------------------
>I *think* I saw an announcement about 3 months ago for a Bookreader for
>MS-Windows product from Digital. I remember it being "inexpensive".
Actually, I recall it being the other way around. The product was out
then killed about 3 months ago.... Ah, yep, found my internal notes about this.
It was Bookreader for Windows. License, Media and Doc part number of
QB-0HNAA-SA, with just the license being QL-0HNAW-AA and the documentation being
QL-0HNAA-GZ. And as of at least August 20, 1993 (and rechecked a few seconds
ago), the bloody part numbers come up invalid even tho the SPD (45.22) for V1.0
still exists on DSNlink (SPD database). The same SPD is now gone from the
E-store.
(10/12/93 Backstrom: It was almost released)
---------------------------------------------
The product was finished, even demoed, went to "SSB" (acronym stands for
Software Supply Business, which in practice means "manufacturing" ;-) but it
never shipped as far as I know.
It was pulled from manufacturing, and will probably not be resurrected
(unless some other Digital groups takes it over; the group that did it has no
funding for it).
The SPD on DSNlink shouldn't be there, because the product isn't for sale.
(10/13/93 Luce: Windows is the best choice for me as well)
-----------------------------------------------------------
March, 1994 The DECUServe Journal Page: 17
(10/15/93 Gudewicz: Windows vote)
----------------------------------
Another Windows vote....
(10/15/93 Melford: Mac Vote!)
------------------------------
(10/16/93 Lederman: Mac first, VMS 2nd)
----------------------------------------
(10/16/93 Birmingham: Macintosh and VMS)
-----------------------------------------
(10/18/93 Baydoun: Windows > Motif)
------------------------------------
(10/18/93 Dell: Product Features???)
-------------------------------------
Other then the platforms....
Is the product features ok?
I've not seen much comment on features?
Do we then all agree?
(10/18/93 Coy: Seems fairly simple)
------------------------------------
>Is the product features ok?
Rather than comment on that, let me say what I would _like_ to be able
to do (aside from on-line-viewing).
1. Search the session abstracts for material. That means - keywords
within the abstract text, as well as subjects, authors, (and probably
date and time and session number).
2. Retrieve and view *OR* print the session abstracts.
3. Given an abstract (session number), print the session notes on a
PostScript printer.
(10/20/93 McCready: Session notes, and a lot more?!?)
------------------------------------------------------
To be a more "complete" record of the symposium, I'd like to see the
following (perhaps in text form) on the CD as well: The directory of abstracts
as it appears (by SIG) in the Symposium program now, including "stream"
breakdowns. The updated list of sessions (adds, deletes, etc.) An updated
March, 1994 The DECUServe Journal Page: 18
audio-tape availability list, along with ordering info. Text of the keynote
address. The week's worth of UPdate.Daily On-site notes conferences The
trade-show program. ATTENDEE Contact info (for those who want to release it - I
understand that it would not be possible for this CD, and might open a can of
worms suitable for another note, but this is done at other conventions (i.e.
the ABA)) Any DECUS info and forms (the hotel reg form for the next symposium,
the DECUServe sign-up form, etc.) that logically could be needed by a DECUS
member, including the list of LUGS and the latest library catalogue. Perhaps
these could be in simple (ASCII) printable-by-anything format. Even photos of
what went on (well...maybe not "* Magic") to give those who did not attend what
it was like. Gosh, maybe even have a multi-media display to entice future
attendance... ;-)
But my main idea is the CD should be a record of the symposium, as much
as possible within volunteer resources. A lot of the above stuff, though, could
simply be scanned in. I would also suggest selling it at a higher price to
non-attendees. But, just simply providing the session notes is still wonderful!
(10/21/93 Cordiviola: More help required to get everything in...)
------------------------------------------------------------------
> To be a more "complete" record of the symposium, I'd like to see the
When first proposed, the ide was to have a drop-off box at the GIB where
people can drop paper to be included on the CD. We also wanted to collect
pertinent information from the DIGITAL Exhibit hall floor.
The problem is not scanning the stuff in, it really lies in INDEXing the
material. This requires volunteer help. One person cannot turn all of this
around in the week of symposia or soon thereafter.
General Mail Confusion
----------------------
This article is an extract of the DECUServe Internetworking
conference topic 210. The discussion occurred between
February 3, 1994 and February 19, 1994.
By Barb Wulff, Matt Holdrege, David Mischler, Joe Matuscak, Dale Coy,
John Osudar, Richard Norman, Jean-Francois Mezei, Terry Kennedy, Pete Sivia,
Bob Tinkelman, Kevin Roels, Jorma Tapola, Brent Hutto, Charles Smith Jr.,
John Briggs, Brian Tillman, Harry Flowers, Gail Walker
(02/03/94 Wulff)
----------------
Well I think I am confused due to the magnitude of information here on mail.
I have pulled down lots of note streams from decuserve that I am in the process
of reading. Stuff on SMTP,MX router, mailbus, cc:mail, TCP/IP, Ucx, etc.
However most of these are very specific and detailed. I need a better overall
understanding of mail over a wide area.
March, 1994 The DECUServe Journal Page: 19
We are in the process of trying to select a mail protocol to use in
connecting to our corporate network. They have an HP running an X.400 MTA but
they also have a newly configured SMTP to X.400 gateway. Now the questions are,
which should we use as our mail protocol and which clients should we use to talk
to that protocol.
As I understand it the possibilities are use MX Mail Router and talk SMTP
or use Mailbus and talk X.400. Either way I think we could use CC:Mail as our
client (I have a new boss who loves CC:Mail from his last life). I don't know
the pluses or minuses here of the two protocols nor do I know what else we can
use for clients that would be good.
Any pointers to reading material would be wonderful. I have pulled down
the mx mail from the Sig cd today and I will read the stuff there. I will
continue to wade through the notes streams. But what else should I know or what
other questions should I be asking.
(02/03/94 Holdrege: some ideas)
--------------------------------
You are not alone. Many of us are or have been confused by the number of
email options available. The great thing about mail theses days, is that you can
choose all methods and still be able to send to each other.
The internet is based on SMTP and the various SMTP-capable packages are now
very user-friendly. The addressing can also be user friendly. My address is
ma...@phs.com.
You already know about X.400. It has some support, but the addresssing is
not as user friendly. My X.400 address is about 4 times as long as my SMTP
address. I can't even remember what it is.
However, as an administrator, your job is to make it easy on your users,
so you have cc:mail and x.500 and DDS to make addressing easier.
My advice is to get a short list of products and try each of them out. Your
choice will depend on cost, how well it fits in your environment, and how easy
it is to use. Make sure that you have your key users try out each package too.
(02/03/94 Wulff: X.500 and DDS?)
---------------------------------
Thanks Matt. Now another quesion please. What exactly is X.500 and DDS.
I am assuming it is a Directory service to allow users to look up other peoples
mail addresses. Is that so? And if it is, is this available to both X.400 and
SMTP?
(02/03/94 Mischler: SMTP and POP3 get my votes)
------------------------------------------------
My company uses SMTP mail on pretty-much everything we have. We have 5
main sites: 2 in California, 1 in Tenessee, 1 in New Jersey, 1 in New York. We
have several small sites, too.
We run MX on VAXen.
We run sendmail on most Unix boxes.
We run MMDF on SCO Unix.
March, 1994 The DECUServe Journal Page: 20
We run popper on some Unix machines to serve POP3 clients.
We run Eudora (a POP3 client) on Macs and PCs running Windows.
We run Mercury mail transport or Charon to gateway Novell clients
running Pegasus mail into SMTP.
Most of this software is freely distributable.
We are growing more MIME-compliant systems all the time.
(02/03/94 Matuscak: Id vote for SMTP)
--------------------------------------
I'm starting to get the feeling that X.400 is looking like one of those
designed-by-commitee-boondogle type things. (Can you say DECnet Phase V ?) It
seems like SMTP and the Internet have won the mindshare wars over X.400. I saw
an article recently that claimed that the Internet was adding about the *total*
number of X.400 users in the world, each month. When was the last time you saw
X.400 mentioned in the Wall Street Journal? :-)
As far as clients, Im becoming pretty fond of Eudora. Its a tcp/ip mailer
that talks POP protocol to a smtp host. Its available for the Mac and Windows
and there are freeware and licensed versions (the licensed versions start at
about $60 each and go down with quantity). It is, as .-1 mentioned quite
friendly and very capable. It understands binary attachements and distribution
lists. Quite nice really.
All in all, I think an smtp solution is looking like the one that can talk
to the broadest number of people.
BTW, for Eudora information, you can send mail to sa...@qualcomm.com.
(02/03/94 Coy: A different view)
---------------------------------
Barb, as you know, we had all of this pretty much ready-to-go at Mt. Vernon.
We selected DECMailworks for most of our user agents. For your Pathworks
users, that may be a good solution. And for your VT users who are used to
VMSmail, the Mailworks interface will be very familiar.
You can make pretty-much anything work, of course. There aren't any "right"
or "wrong" answers.
I would start with what I had, and concentrate on getting appropriate User
Interfaces.
(02/04/94 Osudar: some thoughts)
---------------------------------
At our site, we have VMS, UNIX, MS-DOS, and Macintosh systems using mail
over DECnet, TCP/IP, Appletalk, and NJE (Bitnet). (We also an IBM mainframe
that runs PROFS and acts as an SMTP/Bitnet gateway :-) And we communicate with
a large variety of government, educational, and commercial sites over the
Internet -- so we have some experience with electronic mail. Here are some
comments and observations:
(1) X.400 -- not ready for prime time. Every time we have to
communicate with someone whose system uses X.400, I cringe. The
verbose, obscure addressing conventions are bad enough, but the
March, 1994 The DECUServe Journal Page: 21
software that's out there seems to be worse. (Maybe it's
misconfigured -- at every site that uses it?) Suggestion: wait a few
years and see if it's gotten better.
(2) ccmail, Quickmail, Eudora, Pathworks Mail, and other PC/Mac mail
systems -- these work OK within themselves. I get the impression from
each that it expects to be the only mail system around, so it does a good
job as long as both sender and recipient are on that mail system.
Talking to outside users (through various gateways) tends to cause more
problems. (For example, we had to implement a gateway of our own for
translating between the different methods used to encode attached files
or "enclosures".)
(3) SMTP -- With all its flaws, it's still the only common ground for
almost all mail systems. If a non-SMTP-based mail system doesn't have a
decent SMTP gateway, it's worthless. With recent extensions and
enhancements (e.g. MIME), SMTP is getting closer to being a universal
mail interchange protocol.
(4) User interfaces -- everybody likes something different. On VMS,
MAIL is so primitive, yet many of our users still rely on it. I've
seen Quickmail on our Macs and thought it was a nice GUI-based user
interface (though not perfect). The biggest user interface problem
comes up, again, when attempting to send files (or attach/enclose
files in messages). Electronic mail isn't supposed to be a file
transfer system, but so many people (and mail products) use it as one,
and each system does it differently. That can be extremely confusing
for both the end user and the person maintaining the conglomeration of
systems (i.e. someone like me or you :-)
I could say a lot more, but that sums up my personal opinions pretty
well...
(02/04/94 Holdrege: x.500)
---------------------------
>Thanks Matt. Now another quesion please. What exactly is X.500
>and DDS. I am assuming it is a Directory service to allow users
>to look up other peoples mail addresses. Is that so? And if it
>is, is this available to both X.400 and SMTP?
X.500 is an OSI standard like X.400. It is a directory service architecture
that can be accessed by x.400 and SMTP clients. I think that Microsoft and Lotus
are planning to have their clients access x.500 directories too. The Internet
has a few x.500 pilot projects running now.
AT&T won the contract from the NSF to build a world-wide x.500 directory.
However, AT&T will not build it themselves, they expect each of us to provide
our own x.500 directories to them to be included in the giant AT&T server
cluster. It is still in its infancy today.
DDS is what Message Router uses for addressing by Allin1 andd some of the
PC client mailers.
March, 1994 The DECUServe Journal Page: 22
(02/08/94 Norman: your not alone)
----------------------------------
NASA MSFC has a base x.500 directory up and running. It is still being
updated and populated, but you should be able to finger or query it. No
guarantee that your message will go to the mailbox the person prefers ( ie uses)
yet, but you can see the type of info available.
$multinet finger richard...@x500.msfc.nasa.gov
$mail
to: in%"qu...@mercury.msfc.nasa.gov"
subject: anything you want
body:
first.last
last
You'll get a mail message back with the matches and similar info to finger.
All the other NASA centers are working on building their databases too.
Hopefully the whole thing will be going by summer. Sorry I don't know any
details on the innards, but they are using several gateway products to support
CCMail, Quickmail, VMSmail, SMTP, etc. Thought you might want to try an x500
service out. There should be some x500 clients on the market to make directory
searches etc much easier.
Perpetually confused,
Richard
(02/13/94 Mezei: My own thoughts)
----------------------------------
.6 stated that with MIME, SMTP is becoming an universal mail platform.
Sorry to disappoint you, but MIME is hurting the internet at this point in
time. If you never use accented characters, it won't bother you. But if youare
outside the USA, or if you deal with folks outside the USA, forget using SMTP if
anyone in your network has MIME. Until MIME become a REQUIREMENT, it will
continue to cause havoc.
For instance, I send a mesage from here to a site in France. I do not know
if the remote site has MIME capabilities or not. Yet, I cannot escape the MIME
encoding because my message may containat least one accented character. Some
mime sites are (mis)configured to change a message to BINARY form whenever an
accented character is found, this makes the receied message a huge blurb of hex
digits. (This is the case of a DECUS machine of another chapter).
Another problem with SMTP is that of read-receipt (registered messages).
This is a serious lack in the protocol.
For as much as X.400 may seem more complicated, it can work well if
properly setup, and especially with the help of directory services such as DDS
or the new X.500 irectory service from DEC.
Also, if you wnat equivalent ease , make sure that X.400 users need not be
authenticated in the directory service so that any employee can send out, and
that anyone can send in. DEC's products usually suggest closing yoru X.400
gateway to only registered users. But makes yoru X,400 product much less "open"
for outside communications.
March, 1994 The DECUServe Journal Page: 23
At this point in time, X.400 services are more robust and complete than
SNTP. i would suggest an X.400 corporate backbone with a good SMTP gateway.
If your company is based entirely in teh United States, and if you do not
worry about making sure that a message was delivered/read, then SMTP is a good
solution.
The large document on the FIRP draft report stated that SMTP woudl move in
the next few years to match the X.400 functionality.
Frankly, I personally do not have high regards for SMTP, a system that still
assumes 1960's 7bit paths and causes binary files to double is size just to be
transmitted on a network that is 8 bit clean but still assumes only 7bit clean.
I do not think that MIME is the answer. They should have change the requirement
of SMTP to accept real messages instead of encoding messages in hexadecimal
format. Think of the additional CPU used whenever you send a message: each
content must be searched to see if there is at least one accented character, and
if found the message in then encoded. But each mesasge must still be searched,
even if they don't contain accented characters. Think of the additional
bandwidth used by the increased transmission of binary files.
(02/13/94 Kennedy: An opposing viewpoint)
------------------------------------------
I disagree with most everything said here. I'll comment on some specific
points.
>Sorry to disappoint you, but MIME is hurting the internet at this point
>in time. If you never use accented characters, it won't bother you. But
I correspond with folks all over the planet via SMTP mail. I've never had
a problem with a message I've received, and more to the point, nobody else
has complained about messages my [MIME-aware] system has sent. This includes
mail with 8-bit characters. Your experience may be different, but this isn't
the global disaster you make it out to be.
The alternatives are worse - see below.
>Another problem with SMTP is that of read-receipt (registered
>messages). This is a serious lack in the protocol.
This isn't an SMTP issue. The TP in SMTP stands for "transport protocol".
SMTP is not user interface, it's a transport. Read receipts need to be gener-
ated in the user interface. There are SMTP extensions for both delivery receipt
and read receipt, but it relies on the destination system supporting them in
the same manner as the originating system.
If you look at a package from a single vendor which includes both user agent
and [non-SMTP] transport protocol, they'll probably be well-integrated, at the
expense of interoperability problems with the outside world.
>For as much as X.400 may seem more complicated, it can work well if
>properly setup, and especially with the help of directory services such
>as DDS or the new X.500 irectory service from DEC.
I've reserved judgement on X.400 as a complete messaging system. However,
I am positive that as an addressing method, it is a failure. Some facility
March, 1994 The DECUServe Journal Page: 24
to associate user-generated nicknames instead of over-long text strings for
addresses would help greatly, but that falls down when I'm not on my local
system and I want to send mail to a nickname.
>At this point in time, X.400 services are more robust and complete than
>SNTP. i would suggest an X.400 corporate backbone with a good SMTP
>gateway.
I hope I've provided a good rebuttal to some of your claims about SMTP. I'd
suggest that others experience X.400 firsthand before making a final decision.
>If your company is based entirely in teh United States, and if you do
>not worry about making sure that a message was delivered/read, then
>SMTP is a good solution.
Neither of these are reasonable, as described above. For that matter, how do
you know that a FAX was read?
>Frankly, I personally do not have high regards for SMTP, a system that
>still assumes 1960's 7bit paths and causes binary files to double is
This brings up a number of points. First, not all hosts accept 8-bit data.
Some even crash when they get it in the SMTP stream. Second, SMTP is not a
file transfer protocol - FTP is the file transfer protocol. Before you say
that SMTP goes places FTP doesn't, not true. Both require the IP protocol
stack. SMTP can be gatewayed to other transports, while FTP can't, but it's
no longer SMTP at that point. Next, there are more compact encodings for
8-bit files than doubling. MIME has some that are approximately 4/3. Last,
there is processing which is always done, even on pre-MIME systems. An ex-
ample is that a period alone on a line must be escaped. Since the file is
already being scanned, it's trivial to maintain flags for things like "8-
bit character seen".
(02/13/94 Mezei: I don't disagree with Terry, but I always have problems)
--------------------------------------------------------------------------
Your points are well taken Terry. however, my experience with Internet
mail has shown me that very little of the world is MIME compliant and many folks
get garbage when I send them mail.
How many decuserve users have tried to forwards notes from me to their home
system and find that the text isn't the same because EISNER's MIME automatically
kicked in ?
I agree that Internet mail is much more widespread than X.400. The problem
I find with SMTP is that it is still SMTP: a SIMPLE mail transport protocol.
Instead of developping MIME, the Internet "virtual governors" should have
passed an edict that no software shoudl block 8 bit characters and that
ISO-LATIN-1 was to replace the antiquated USA-ASCII as the main character set.
Of course with UNICODE on the horizon, it will be interesting to see what
happens.
As far as read/delivery receipts, the fact that Internet/SMTP don't
specify this means that you cannot reliably use such a feature because you have
no idea if it is to be supported at the other end. This is where X.400 is
March, 1994 The DECUServe Journal Page: 25
better: it is a complete standard and you know that the other end is supposed to
comply with it.
What worries me about Internet MAIL is that it is based on an old standard
that uses very antiquated technology (7bit channels) as a basis and it is trying
to build on it instead of putting in a more robust foundation.
The same could be said of IBM's SNA which started off as very basic and new
features were added while keeping old stuff running (eg: upwards compatibility).
But SNA is today a very old and antiquated networking protocol. I woudl prefer
to see SMTP evolve instead of adding gadgets over it to make it do tricks it
wasn't designed to do.
As far as X.400 adressing, if you use a backbone directory service, then
your nicknames are available to anyone on the backbone. I agree that X.400
adressing isn't as short as INTERNET, but it is no worse than mailing labels:
name, department, company and country. With X.500 directories starting to
appear, a global X.500 directory will be reality before the end of this century.
At that point, whether the target person is an X.400 or internet address will
become irrelevant because of that global directory.
(02/14/94 Tinkelman: A luxury the Internet doesn't have)
---------------------------------------------------------
> Instead of developping MIME, the Internet "virtual governors" should
> have passed an edict that no software shoudl block 8 bit characters and
We can discuss how we'd design the Internet if we were starting fresh, today.
However, that would be a somewhat academic conversation.
It Internet started out as a network where you could count on a 7-bit data
path, not 8-bit. That's unfortunate. But it's reality. SMTP was spec'd
to count on an 8-bit path. Unfortunately some implementations didn't bother
to check to see if the date they were sending was 7-bit or 8-bit. Sometimes
this was fine. The receiving system accepted the data. Sometimes it stripped
the top bit. Sometimes it actually kept all 8-bits. But as Terry said,
sometimes it crashed.
Several things happened next. SMTP was extended to include 8-bit
negotiation. The sending and receiving mailers could negotiate with each other
to see if they (and the data path) were capable of handling 8-bit data. If so,
they'd transfer msgs, as is, even if they included 8-bit chars. Also, standard
encoding methods were specified, to be used to transport 8-bit msgs if the
transport supported 7-bit only.
This would have been a `perfect solution', allowing optimal use of the
various transports IF the `governers' you refer to were tsars. That is, *IF*
they could have decreed that *all* systems on the Internet must immediately
adopt the new standards, and *all* broken systems must be fixed immediately.
But that's fantasy. Older systems will be with us forever. And when a newer
system tried to negotiate with an older system, and the older system doesn't say
``Yes, I can handle 8-bit data,'' then the newer system must make the safer
assumption. It needs to encode the data before transmitting it. [The
alternatives are to strip off the 8th bit (changing the data) or to refuse to
transmit the msg.]
March, 1994 The DECUServe Journal Page: 26
(02/14/94 Mezei: For you its not a problem, but for me it is)
--------------------------------------------------------------
>data before transmitting it. [The alternatives are to strip off the
>8th bit (changing the data) or to refuse to transmit the msg.]
Sorry, What should be done is to convert accented characters (the offending
data) to their non accented counterpart. For instance, convert a é to an e, so
that the receiving system can display it to the user in a readable format.
(much more than teh MIME encoding which non only messes up accented characters
but messes up the whole text).
I think that by default, MIME equipped sites should NEVER MIME encode
outgoing messages unless it is going to a site known to have MIME.
I never have problems receiving messages here on EISNER because it is
"state of the art". However, people I send messages to often have problems
because they get messed up messages. Remember that since my name contains a ç,
almost all messages i send out are MIME encoded, so I know how often I get
complaints from people that my messages were all messed up (even if it was only
the last line that contained a ç).
Yes, I understand that this whole network is based on old technology.
Although there are fixes to the limitations of the internet mail, these are far
from widespread. Until they are, the limitations of the internet are , for me,
serious enough.
This having been said, the internet does reach a LOT of people, and often,
the limitations are not as important as the benefits. But I wouldn't want to
support a coporation that is based on SMTP with a mismash of mailers, some not
supporting accented characters unless i were in the UNITED STATES and the
company didn't export.
(02/14/94 Roels: Who knows....)
--------------------------------
What the hey, I'll toss in my two pfennig's worth....
We are in the midst of defining mail backbones for our company right now.
While we would have preferred X.400 (OSI) standards, we were hampered by a
couple of issues. It is a fact that there are not very many products out there
that implement all there is on X.400 without making you purchase proprietary
software to make it all work, HP and DEC included (we brought both in). Also, I
point to the fact that the EMA has a working group dedicated, at this moment, to
solving the attachment problems in X.400 as an answer to MIME.
We have defined our mail backbone to support both OSI and Internet standards,
as a means of picking the only two open standards available, and dealing with
that. I was VERY disappointed by all the claims of openess, etc., our potential
X.400 vendors made, and then promptly failed to deliver, in an "open" manner -
"Yes, we sell Open solutions, but they won't work with other open solutions
unless you buy these products and these third part gateways, too".
Compatibility issues aside, the Internet standards seem to be more workable.
We've been putting out both older and MIME-compliant SMTP mail to the Internet
for over a year, with none of the problems you've mentioned.
Some of this discussion may point to the biggest difference between the way
OSI and Internet standards are worked on and approved. You may notice, that,
for the most part, it takes 4-5 years for the final end-product from each group
March, 1994 The DECUServe Journal Page: 26
to come out. They just arrive there differently. The OSI folks will come up
with a concept for a standards, and work on it for four uears or so, until it is
perfect and can be released. The Internet folks will come up with an idea for
something, get an initial working standard developed, and release it then and
there, then work on perfecting it over the next four years. Same time, different
method.
I contend this issues will be (already is, in most circles) as 'religious'
as which word processor to use, etc. We won't settle this here. Very
intersting conversation though, kind of helps point out
International/Globalization issues.
(02/14/94 Kennedy: I still don't see the point)
------------------------------------------------
>Sorry, What should be done is to convert accented characters (the
>offending data) to their non accented counterpart. For instance,
You're being Western-language-centric. Please demonstrate the "non accented
counterpart" of this text:
[7m[ [27m$B$_$" [7m[ [27m( 22 [7m[ [27m$B$+$J$($i$$$V [7m[ [27m(B
>I think that by default, MIME equipped sites should NEVER MIME encode
>outgoing messages unless it is going to a site known to have MIME.
What do you suggest be done instead? Maintain translation tables from every
possible character set to every other character set, and guess which one is to
be used?
>I never have problems receiving messages here on EISNER because it is
>"state of the art". However, people I send messages to often have
Presumably those sites want to receive your message, and they know they have
8-bit characters in them. So why haven't they installed a MIME-aware reader or
an outboard conversion utility? These are available now for the majority of
platforms in use.
>Although there are fixes to the limitations of the internet mail, these
>are far from widespread. Until they are, the limitations of the
>internet are , for me, serious enough.
So, you're saying that even though the solution is available, because some
folks don't want to install it, nobody should send MIME? Sounds weird to me.
>wouldn't want to support a coporation that is based on SMTP with a
>mismash of mailers, some not supporting accented characters unless i
>were in the UNITED STATES and the company didn't export.
That's a bit drastic. Also, I'm not sure why a company would select a
"mishmash of mailers", especially since you're talking about SMTP mailers only
(presumably a gateway to a PC mail system would convert from MIME to whatever
format the PC mail system used). Seeing as how PMDF and sendmail support MIME
March, 1994 The DECUServe Journal Page: 27
now, that covers VMS and Unix, at least for people who are selecting software.
Sure, PMDF costs money, but if it isn't worth spending money on the MIME issue,
then it isn't an issue, right?
(02/14/94 Tapola: It could be fatal!)
--------------------------------------
>Sorry, What should be done is to convert accented characters (the
>offending data) to their non accented counterpart. For instance,
I know this is done in some cases, like X.400 mail, but it might cause
unfortunate mistakes. In Finnish there are two 8-bit character, and they are not
used as accented characters, but totally different than their non accented
counterparts. They are
a ä
o ö
Usually no confusion is caused by leaving those dots out, but sometimes it
could be fatal!
näin = saw
nain = marry (or F-word that you can't write on DECUServe)
(02/14/94 Norman: Well I started on topic ;-} )
------------------------------------------------
> I still don't see the point
I think what J-F is trying to say is that you should respect a non-MIME
machine the same way you respect a non-8bit machine. Since I don't know MIME, I
can't say whether this makes technical sense or not, but seems like a logical
request to me. Not sure how you'd implement it without sending additional mail.
Perhaps all that is needed is a /NOMIME switch for the send command. As pointed
out in one of the shop talk threads if you have a customer with a problem, then
YOU have a problem.
You can't upgrade the entire Internet overnight. Just because MIME is
available for a bunch of different platforms doesn't mean everybody has it yet.
Little things like procurement cycles tend to slow things down, not to mention
lag time for people to hear about it, and to realize WHY they can't live without
it. That's where I am: the "WHY do I need this" stage. This is NOT to say that
you shouldn't upgrade just because it makes it more difficult to communicate
with older technology.
_IF_ the new technology has *merit* then transition to it. This is the
way I feel about OSI. Most of the arguments I hear from the IP camp are based on
lack of marketshare and infrastructure. These are not good arguments IF the new
technology has long range technical benefits. IP didn't have marketshare or
infrastructure when it started out either. That is my biggest problem with the
FIRP report. It fosters inertia and herd mentality over technical benefits.
Let's all continue to torture ourselves with dos 640k limitations because the
March, 1994 The DECUServe Journal Page: 28
Joneses are. Again I don't know the technical details of IP or OSI, but I don't
like to hear policy makers basing their decisions solely on non-technical
issues. Hopefully the folks they assigned to recommend future networking goals
will do more than study the marketplace. I'm not in favor of going though the
painful process of transition to OSI unless it is technically superior in the
long haul. And yes, I'm well aware you CANNOT ignore the economic issues. I
like the FIRP's realization that more than one solution needs to be supported
for the near term, but I think they fall short on the long term. We need a
strong direction for the long term, and we need to start by building the
infrastructure regardless if there is anybody that needs to use it right away.
You can't build a superhighway _while_ people are using it. You build it then
open it. Once the the structure is there vendors will write better and better
tools for using it. You need to base your highway design on strong technical
merits, if you expect it to be here very long.
(02/14/94 Sivia: Allow for MIME conversion to be temporarily disabled)
-----------------------------------------------------------------------
The /NOMIME switch would be one way to do it, but I'd suggest rather a
process/job/group/system logical for this should be definable. So, it could be
set at a system level and over-ridden by the user if necessary.
I, too, have had a number of problems with MIME formated mail when I
forget it's not properly received on some systems. Unfortunately it's one of
those things you remember AFTER the fact ;-)
I understand why the encoding was done, in fact even argue it's probably
right, but to not have a switch to turn it off temporarily does strike me as a
bit odd. Simply put, not all systems yet have MIME working or available or
installed.
(02/14/94 Sivia: MIME outboard converter?)
-------------------------------------------
>an outboard conversion utility? These are available now for the majority of
>platforms in use.
Humm, an outboard conversion utility? Is there a public domain one for
VMS systems? If so, where/what is it, and if necessary, can it please be
posted? I'd take source in C, Fortran, Pascal, Basic ... DCL.
[I'm presuming that the outboard conversion utility would allow one to
take a MIME-encoded message received as email on a system that doesn't
understand to translate it inside email, extract it to a file, and do the
conversion after the fact.]
(02/14/94 Mezei: It is the protocol negotiation that is lacking)
-----------------------------------------------------------------
Well, MIME is just a stepping stone in the world of Internet mail. I am
sure that MIME does not respond to the needs of teh 21st century and that later,
something else will be added on top of it to enable virtual offices to be
e-mailed :-)
The problem is that the internet community runs a LIVE system at the same
time as it is thinkering/playing with it.
March, 1994 The DECUServe Journal Page: 29
MIME may provide the good functionlaity, but no provision was made to
provide a seemless installation of MIME over the years. As a result, those who
are mime equipped always risk sending jibberish to their correspondants who are
not (yet) mime equipped.
MIME should have, as part of its protocol, a negotiation with the remote
host and afterwards, encode the bloody message if the remote host has
acknowledged it can decode it, otherwise, do not decode it.
If MIME had been designed with the upgrade handling built-in, then I
wouldn't be complaining. I do not like INternet because there is no real
management of change. it is just implemented whenever people feel like it and
the change does not support upwards compatibility. Hackers who find way to
transport imaginative stuff over the net should be told that before their
methods are implemented, they must find a way to make sure that the recipient
can handle that new feature.
As far as the ANSI escape sequences Terry refered to, I am talking purely
of TEXT. For me, an é is just an ASCII character, the same as an ï or an ë or an
È. They are letters that are used in plain text. They are one byte, same as an i
e or u. I am fully aware that you should not expect control characters to be
transmitted through e-mail paths without a binary flag set (or encoding).
However, for text messages, I just do not see why there is an imposed 7bit limit
STILL IN EFFECT. The ISO-LATIN-1 standard has existsde for some time and there
si no reason that the Internet could not have adopted it over the years.
Also, I cannot understand why most americans consider an É to be a control
character just because its 8th bit is set. Control characters are in both 0-30
and 128-150 ranges. So if É is considered a control character, why is E not
considered one ?
(02/14/94 Hutto: Is Internet mail delivered directly or forwarded?)
--------------------------------------------------------------------
It's probably stupid for me to butt in where I have 1) no knowledge
and 2) no strong opinion and 3) in a rather emotionally charged conversation.
That said, let me butt in anyway...
>MIME should have, as part of its protocol, a negotiation with the
>remote host and afterwards, encode the bloody message if the remote
>host has acknoledged it can decode it, otherwise, do not decode it.
Don't most Internet mail messages get passed from place to place over
unpredictable routes and then end up at the right place? If so, how would this
protocol negotiation take place. There is no "circuit" set up for mail like
there is with an FTP or Telnet session, right? If so, the only way to do this
negotiation would be to send a meta-message, get a meta-message in reply and
then proceed with the actual message in whatever form was negotiated.
If I'm correct on this understanding, then what JF is asking for here
(as well as in an earlier posting about return-receipts) is something slightly
but significantly different than the commonly used Internet mail arrangement.
For instance, a delivery-receipt is a lot easier to implement and count on
functioning correctly in a mail system that uses actual circuit establishment
than in a forwarding arrangement.
So, Terry or whoever, do I understand how SMTP mail works or am I all wet?
Either way I'd like to know.
March, 1994 The DECUServe Journal Page: 30
(02/14/94 Tinkelman: What do you do when the other end won't negotiate)
------------------------------------------------------------------------
JF's suggestion regarding negotiation gets to the heart of the problem.
What do you do if the other party won't negotiate. Remember, the mailers that
know how to negotiate are the modern ones. There's no problem with them!
Say you're a state-of-the-art mailer, you have a msg to send that contains an
8-bit character, and the other end doesn't know how to negotiate with you to
tell you whether or not it can support receiving the msg. What do you do? If
you send it, as is, then 3 different things can happen:
(1) The msg might be delivered perfectly, 8-bit char intact.
(2) The msg might be delivered in a modified form. This might
or might not be acceptable to the users.
(3) The receiving system could die some horrible death.
Unfortunately, you don't know which will happen.
The alternatives to `send-it-as-is' are `encode-it' or `bounce-it'.
As a postmaster I am very reluctant to have my system blindly send
non-standards-compliant msgs which might crash software on other systems. [OK.
I'm more than reluctant. So far, I've refused.] I've made the judgement call
that sending a msg in encoded form is better than bouncing it. Remember that
the encoding we use is `quoted-printable'. So all the normal, 7-bit chars are
sent as-is. The msg is human-readable.
The software we're running on EISNER, PMDF V4.2, while not perfect, does
provide a bit of flexibility here. I've offered, when this subject came up
before, to maintain a list of systems which (1) run older software which can't
do the 8-bit negotiation of SMTP, and (2) want mail sent in 8-bit form anyway.
Mail sent from [eisner/topaz].decus.org to systems on this list would not have
their text encoded for the purpose of protecting 8-bit chars. For a system to
be added to this list, I just need to get an e-mail request from that system's
postmaster.
In the past I've made this offer via private e-mail. So far nobody has
taken me up on the offer. So now I'll make it in NOTES. [Maybe later, I'll
even move this note to the appropriate conference for that!]
(02/14/94 Smith)
----------------
> JF's suggestion regarding negotiation gets to the heart of the problem. What do
> you do if the other party won't negotiate. Remember, the mailers that know how
> to negotiate are the modern ones. There's no problem with them!
This reminds me quite a bit of the "good old days" when there were still
300 baud accoustic couplers around, most users had at least 1200, and the "state
of the practice" was 2400. Back in those days, one could STILL get a complete
newsfeed (the big 7 + alt) at 2400...
Traffic began to grow, and 9600 started to get reasonable; telebit gave
some incentives, and the march to a higher speed modems began. At first, 2400
was still the defacto standard. Then, slowly, there became less and less of
them. Peer pressure began to grow: Hey, don't tie up my fast modem with your
junky old 2400.
March, 1994 The DECUServe Journal Page: 31
Finally, the two or three remaining 2400 users were told to buy a real modem,
or live with mail only.
There's a moral here somewhere; finding it is left as an exercise to the
reader. :)
(02/14/94 Coy: I'm not responsible for someone else's bugs)
------------------------------------------------------------
OK, let me stick an oar in, with a SLIGHTLY-different viewpoint.
Bob Tinkelman says:
>If you send it, as is, then 3 different things can happen:
> (1) The msg might be delivered perfectly, 8-bit char intact.
> (2) The msg might be delivered in a modified form. This might
> or might not be acceptable to the users.
> (3) The receiving system could die some horrible death.
>Unfortunately, you don't know which will happen.
and
>As a postmaster I am very reluctant to have my system blindly send non-standards-
>compliant msgs which might crash software on other systems. [OK. I'm more than
I recognize the difficulty choosing between (1) and (2), but WRT (3), I
have no such reluctance. I do not believe that it is my responsibility to avoid
sending "just plain stuff", on the off chance that some recipient's system may
crash. There is no malicious intent here - just the attitude that *ANY* system
should gracefully accept *ANY* input, and either handle it properly or discard
it if unrecognized.
(02/14/94 Mezei: DEC doesn't have it now)
------------------------------------------
Correct me if I am wrong, but when system A sends to system B, once the
connection is established, A talks directly to B. Yeah, the path may go through
many hosts, but those should pass teh data transparently. Right ?
(I understand that establishing the connection involves A talking to a
few hosts before it reaches B).
Is that correct ?
In Canada, the telco e-mail systenm support accented characters. When you
send to a system which do not support ISO LATIN, the sender is given a warning
that his message was converted, and the text of the message contains a warning
that the original was written in ISO LATIN.
The problem with internhet is that MIME seems to be a gadget, and optional
facility instead of a standard that people should adhere to. And until it is
well entrenched, everyone should be aware that you cannot transparently send
e-mail messages is your first language isn't english.
Oh, and when Digital will adopt MIME itself, then I might beleive that
MIME is catching on.
March, 1994 The DECUServe Journal Page: 32
(02/14/94 Coy: Not quite that simple)
--------------------------------------
>In Canada, the telco e-mail systenm support accented characters. When
>you send to a system which do not support ISO LATIN, the sender is
>given a warning that his message was converted, and the text of the
>message contains a warning that the original was written in ISO LATIN.
Does the sender get that warning at the time he/she sends the message?
If so, that implies a connection made at the instant - rather than a
store-and-process-later system like PMDF.
Or does the sender get some kind of "return mail" at a later time?
>Correct me if I am wrong, but when system A sends to system B, once the
>connection is established, A talks directly to B. Yeah, the path may go
>through many hosts, but those should pass teh data transparently. Right?
OK, you're wrong. :-) There is no way to guarantee that the total,
end-to-end path, is a direct connection. As a simple "for instance", there may
be forwarding, "delivering", etc.
(02/15/94 Briggs: The bug stops here)
--------------------------------------
>have no such reluctance. I do not believe that it is my responsibility
>to avoid sending "just plain stuff", on the off chance that some
>recipient's system may crash. There is no malicious intent here - just
>the attitude that *ANY* system should gracefully accept *ANY* input,
>and either handle it properly or discard it if unrecognized.
Unfortunately, we live in the real world. We _DO_ have to accomodate
each other's bugs. I've just lived through an episode in which I discovered
that something like 70 to 80 percent of the mail packages on the Internet cannot
properly handle addresses containing commas or parentheses embedded within
quotation marks.
That includes Multinet and sendmail.
It was far simpler for me to change the gateways I used to route e-mail
into SMTP than it would have been for me to get everyone to fix their bugs.
JF:
I suggest that you download RFC821.TXT, RFC822.TXT, RFC1154.TXT, RFC1341.PS
(or RFC1341.TXT) and RFC1342.TXT from ftp.nisc.sri.com.
Some of these RFC's may no longer be current, please, someone, correct this
list if they are.
RFC821 describes SMTP -- the standard transfer protocol for Internet e-mail.
This is the component in which negotiation could be performed. (Not end-to-end
negotiation though -- .-1 is correct in ruling that out).
RFC822 describes a standard format to which e-mail messages should conform.
This is the (old) standard for encoding.
RFC1154 describes an extension to RFC822 that allows for encoded multipart
documents. As I understand it, this RFC was never formally adopted. Many
e-mail gateways use it anyway. It predates RFC1341 and was the only game in
town for some time.
March, 1994 The DECUServe Journal Page: 33
RFC1341 describes MIME. The subject matter is message encoding, not a
transport protocol.
RFC1342 describes a way in which non-ASCII characters may be used in message
headers.
(02/15/94 Tillman: Separation of transport and encoder)
--------------------------------------------------------
JF, you keep confusing Mail User Agents with Mail Transport Agents.
The _user agent_ does the encoding and hands it off to the transfer agent. The
encoder hasn't the faintest idea whatsoever that the destination system _even
exists_ let alone what it can or cannot accept. Nor does it care. That's the
transfer agent's job. Now, the transfer agent hasn't the faintest idea _what's
in the message_, how it's encoded or anything like that. Nor does it care. The
mechanisms you seem to want at the user agent level only apply to
non-store-and-forward mail systems such as VMS Mail over DECnet.
(02/15/94 Mezei: More thoughts
-------------------------------
As far as the TCP/IP connection os concerned. If I telnet or FTP, when
I establish the connection, don't I get the actual address and route to use to
get to the host, and once established, don't I talk directly to the remote host?
(eg: hosts between me and the destination become transparent) ?
If the above is true for FTP and TELNET, why does it not apply to SMTP ?
I understand that if you talk though a BITNET gateway or something, you
will be talking to the gateway instead of talking to the end host. (It is then
up to the gateway to do the proper negotiation).
And as far as ENVOY'S handling of accented characters, it will maintain them
if the destination is a known destination, and will convert if the destination
is unknown. When a gateway is setup, the profile indicates if it supports LATIN1
or not. So ENVOY looks at the gateway to determine what to do.
ENVOY is an MTA (as well as having a primitive user agent). And it does
send you a notification of character conversion is the confirmation of the
message being sent.
I understand the limitations of an MTA and user agent. Digital has/had
a product called the conversion manager which runs/ran at the MTA level which
had a table of who can accept what type of documents.
I can underst<and that Internet has technical limitations that may not
allow proper transmission of messages to ANYONE.
It is just a shame that the network of the 90's that is suppose dto be
able to handle multimedia is using 1960s technology and isstill limited to a
7bit character set and is forcing folks to find imaginative way to go around
that limitation (instead of removing that limitation).
It is interesting that a network of such proportions is not concerned
about the increased bandwidth requirement because anything that needs 8bits must
be encoded and thus takes up a lot of bandwidth. (try MAIL/FOREIGN and see what
the result comes out as in a non MIME compliant machine !)
Of course, the end result is that with MIME you CAN send stuff around,
provided you first ask your correspondants if they have MIME or not. And manmy
will argue that Internet does provide the ability to send all sorts of stuff. It
is true. It is just not a reliable system because you do not know if yoru
recipient is capable of reading your message (unless you do not have MIME, in
which case, recipients will always be able to read your message, but might not
be able to read theirs).
March, 1994 The DECUServe Journal Page: 34
(02/15/94 Hutto: I understand more than I can explain.)
--------------------------------------------------------
As I said before, I'm not *sure* about how SMTP mail works, but I've used
that sort of mail on a daily basis for 3+ years now, and the model of its
operation that I carry around in my brain is "no direct connect for Mail". What
I observe is always consistent with that model.
Look at it this way. I routinely send a message from my VAX in South
Carolina to, let's say, DECUServe's computer in Massachusets. If I look at the
mail-sending process on my VAX, it completes and goes back to sleep *before* the
message arrives in my account on DECUServe. This can be anywhere from a few
seconds to a couple of minutes. The Telnet connection between my VAX and EISNER
runs in "real time", but the mail message takes a while to get there. This is
why I deduce that there is no actual end-to-end connection used for SMTP mail
delivery while there is such a connection for Telnet sessions.
I wish someone would post a detailed explaination of what happens at each
step between my VAX handing off the message to whoever it gets handed off to and
EISNER receiving it from whoever receives it. I do think I understand it, but I
can't explain it "authoritatively".
(02/15/94 Hutto: I'm thankful for what Internet is (even if it isn't everything)
--------------------------------------------------------------------------------
> Of course, the end result is that with MIME you CAN send stuff around,
> provided you first ask your correspondants if they have MIME or not.
> And manmy will argue that Internet does provide the ability to send all
> sorts of stuff. It is true. It is just not a reliable system because
Somehow this reminds me of the endless steam of conversations I have
had with people in an organization for which we provide informal assistance in
the form of letting them use our computer. They are prone to call me up and ask:
"How do I send E-mail to John Doe over at the State Board for
Dithering and Redundancy?"
to which I reply:
"Well, does he have an account on a computer somewhere? I've never
heard of John Doe."
their reply:
"Well, if I knew that, I'd know how to send him mail."
my answer:
"Why don't you call him and find out."
their (invariable) reply:
"Never mind, it's not worth it."
and occasionally the real kicker:
"Heck, what good is E-mail if you can't send it to anybody?"
March, 1994 The DECUServe Journal Page: 35
In a perfect world, I could sit at my PC with nothing but the thoughts on
the top of my head and communicate with an arbitrarily chosen person anywhere
on the planet. In this same world, 7-bit and 8-bit and Unicode and so forth
wouldn't even be an issue. Everyone would be using software compatible with
everyone else's.
Given that such a world doesn't exist (notice I didn't say "yet exist",
it never will, IMHO) I have to admit to being amazed every time I get an
Internet mail message from a person I don't even know who is answering a
question I just posted to a newsgroup. I guess I'm just naive that way, but it
amazes *me* every time.
(02/15/94 Matuscak: "Because")
-------------------------------
>use to get to the host, and once established, don't I talk directly to
>the remote host ? (eg: hosts between me and the destination become
>transparent) ?
>
>If the above is true for FTP and TELNET, why does it not apply to SMTP ?
Sendmail, for example, is capable of doing both "direct" mailing and
store and forward. When you configure a sendmail, you tell it if you want it to
queue messages for periodic processing or to try to deliver mail immediately.
Even in the case of immediate attempts, if the destination system is unreachable
the mail gets queued.
(02/15/94 Flowers: A maze of twisty little passages, all different)
--------------------------------------------------------------------
You can't even count on talking to the target system when you send mail
via SMTP... you might be connecting to a system that has an MX (Mail eXchange)
record for the system you're trying to reach, and they don't have to be on the
internet to have an internet address. Basically, you can't assume very much
about an arbitrary destination.
(02/15/94 Sivia: Can't the users say /NOMIME when they email??)
----------------------------------------------------------------
But what if one is sending from a system that has MIME to a system known to
NOT have MIME support? Shouldn't there be at least a way for us, the users, to
say to the sending system "please, don't use MIME, I know what I'm doing?"
That's all I'm asking for in having either the /SWITCH=NOMIME or the logicals
that would disable it on a temporary basis.
(02/16/94 Flowers: I guess it's the face paint ;-))
----------------------------------------------------
So, what happens to the 8-bit characters when the mailer only supports
7 bits and you can't MIME encode them? Maybe insert the ASCII value in brackets
(like [147])? If the remote mailer is known not to "do MIME", then maybe you
shouldn't send any 8-bit characters?
March, 1994 The DECUServe Journal Page: 36
(02/16/94 Mezei: MIME is more than just accented char)
-------------------------------------------------------
Well, if MIME only replaced accented characters, it wouldn't be so bad.
But MIME also replaces TABS wit =08, splits lines at 72 characters etc etc.
In essence, the text may be semi-readable, but the message isn't.
Especially if you have tables built with tab characters.
I much prefer seing my é being read as an i (that is what happnes when
its 8th bit is chopped off) than to see my message reformatted. Ideally, mailers
in an overhwelmingly 7 bit world should have been built to change accented chars
to their non accented counterpart (é -> e) right from the start. Of course, it
is easy to say now, but back in the 60s when UNIX was developped, accented
characters on computers were unheard of. (Remember, backthen, people were
working on punched cards :-)
(02/17/94 Briggs: Those grapes are sour)
-----------------------------------------
>As far as the TCP/IP connection os concerned. If I telnet or FTP, when
>I establish the connection, don't I get the actual address and route to
>use to get to the host, and once established, don't I talk directly to
It does apply to SMTP. I repeat my suggestion that you download RFC821.TXT
from FTP.NISC.SRI.COM. And get the rest of the lot -- RFC822, RFC1154,
RFC1341 and RFC1342.
But SMTP isn't the whole story. As Joe Matuscak pointed out in .32,
your message may be stored locally for later transmission if the remote host
isn't immediately available. And, as Harry Flowers pointed out in .33, MX
records in the DNS may reroute your message to a host other than the one you
think you are talking to. There are legal address specifications that
explicitly call for multi-hop routes to the destination host. Such address
specifications are required in certain situations (such as routing to and from
MILNET where routing tables are not complete).
The SMTP protocol is a point-to-point transfer protocol. It prescribes
how you transfer a message to a remote node and how that node is to acknowlege
your transmission over a real-time TCP connection. The node at the other end of
your SMTP link may not be (for the reasons listed above) the actual message
recipient. Mail software on the receiving node has to examine the RCPT TO:
address specified in your message to determine if your message must be
forwarded, perhaps on another SMTP hop.
SMTP stands for "Simple Mail Transfer Protocol". It is simple because it
pays no attention to message contents. It's just a way to get a message, a from
address, a to address and a couple other fields from point A to point B. It's
designed as a tool for cooperating TRANSFER AGENTS. It is not intended as an
end-to-end channel for use by cooperating USER AGENTS. As such, message body
encoding issues are properly none of SMTP's business.
There is nothing in the MIME standard the prescribes the use of SMTP as
a message transfer protocol. Indeed, one could reasonably MIME encode for
transmission by DECnet, for local storage or even for transmission by mag tape.
It would be unreasonable for the MIME designers to specify a particular transfer
protocol and it would be unreasonable to constrain a MIME implementer to use a
particular transport.
March, 1994 The DECUServe Journal Page: 37
It would be foolish to mandate an Internet message transfer methodology
that would have the nodes at each hop through which a message is forwarded first
decode the message and then re-encode according to a negotiated
least-common-denominator format. Can you say "weakest link".
The fact that your messages have a single instance of an eight bit character
may reasonably allow you to say "I don't like MIME" or "MIME makes my life
difficult". It does not allow you to reasonably make the sour grapes claims
that have populated this thread.
(02/17/94 Sivia: Where's the un-converter?)
--------------------------------------------
OK, I guess there is to be no way that's going to allow a per message
turning off of MIME. Can I please get a copy of whatever it is that can run on
VMS systems and does the after-the-receipt un-translation from MIME to what we'd
see if MIME did exist on the system, like Terry K. said was around in .15?
(02/17/94 Kennedy: Here's how)
-------------------------------
Ok, here's the deal:
1) FTP to thumper.bellcore.com
2) get /pub/nsb/mm2.6.tar.Z
3) uncompress it
4) untar it
5) copy the files src/metamail/mmencode.c, src/metamail/codes.c, and src/
config.h to a handy directory on the VMS system. I used sys$login:
6) Run this .com file:
$ ! Build Nate's mmencode utility
$ cc mmencode/include=sys$login:
$ cc codes/include=sus$login:
$ link mmencode,codes
$ mmencode :== $sys$disk:[]mmencode
7) Remove all the headers from the message you want to process, after
noting if the content-transfer-encoding was BASE64 or QUOTED-PRINTABLE.
8) say "mmdecode -u -b filename" for BASE64 or "mmdecode -u -p filename"
for QUOTED-PRINTABLE. The data appears on SYS$OUTPUT:.
This code runs under Unixes, MS-DOS, VMS, and other systems. There's a lot
more to the METAMAIL kit, but this will let you decode messages.
(02/18/94 Briggs: RFC's in GATE3:[NET.INFO.RFC])
-------------------------------------------------
My apologies to anyone who looked there for those rfc's. They aren't
there any more. And they aren't on the host that you get referred to when you
look.
They are here though. In directory GATE3:[NET.INFO.RFC].
March, 1994 The DECUServe Journal Page: 38
(02/18/94 Walker: Terry, can you help with mmencode?)
------------------------------------------------------
> $ ! Build Nate's mmencode utility
> $ cc mmencode/include=sys$login:
> $ cc codes/include=sus$login:
> $ link mmencode,codes
> $ mmencode :== $sys$disk:[]mmencode
>
> 7) Remove all the headers from the message you want to process, after
> noting if the content-transfer-encoding was BASE64 or QUOTED-PRINTABLE.
> 8) say "mmdecode -u -b filename" for BASE64 or "mmdecode -u -p filename"
> for QUOTED-PRINTABLE. The data appears on SYS$OUTPUT:.
First, to get the link command to work, I needed to specify an options
file so I could link in the VAX C RTL. Okay, I did that.
Note that the commands talk about building "mmencode" but the instructions
for running it show you typing "mmdecode". Assuming that was a typo, I tried
following 7 & 8 using mmencode on a quoted-printable message (with all headers
removed) and got a few characters of garbage followed by %NONAME-W-NOMSG,
Message number 00000000
This is on VMS 5.5 using VAX C 3.2.
Am I missing something here?
(02/18/94 Walker: Got it - quoted-printable is -q )
----------------------------------------------------
Oh, I see. For quoted-printable the second switch is supposed to
be -q not -p. So that's mmencode -u -q filename
(02/18/94 Kennedy: Sorry about the errors - it was past my bedtime 8-) )
-------------------------------------------------------------------------
(02/19/94 Sivia)
----------------
Thanks!
March, 1994 The DECUServe Journal Page: 39
The DECUServe Journal
=====================
Publication Information
-----------------------
Topic threads in the DECUServe VAXNotes conferences are selected for
publication on the basis of strong technical content and/or interest to a wide
audience. They are submitted to the editor by a team of Contributing Editors
who are DECUServe Moderators, Executive Committee members and other volunteers.
Articles in the DECUServe Journal are downloaded to a 286 PC and formatted
using a standard text editor.
Editorial Content Disclaimer
----------------------------
Opinions and information presented here belong to each individual author.
No inferences should be made that the authors are expressing the policies of
their employers unless specifically stated. Content has been deemed acceptable
by the Moderators of DECUServe according to the DECUServe Canons of Conduct.
How can I use DECUServe?
------------------------
DECUServe is available 24 hours a day, 7 days a week, except for the last
Thursday of each month at 5pm Eastern time for backups. Membership is by
individual subscription only, and subscriptions are sold on a yearly basis
currently for $75.00. Subscription forms are always included in DECUS New
Member packets and Symposia registration packets. Six-month subscription
forms are often distributed at symposia as well.
Foreign DECUS chapter members are invited to subscribe as well, although
they must do so through their chapter office. Forms and price details can be
obtained from the chapter office.
Also subscription forms can be downloaded directly from DECUServe by dialing
1-800-521-8950 with the username INFORMATION. Set your modem to 2400 or 9600,
1 stop bit, 8 bits, no parity. Other access modes are Tymnet, PC pursuit,
and Internet.