Hi all,
> > On Thu, 4 Apr 1996, Mike Jones wrote:
>
> > > Michael writes:
> > >
> > > Your CEO is named Peter Smith Peter_Smith @
organization .
com
> > > You hire Pete Smith to work on graphics for the widget brochures.
> > > Your VP finance sends email regarding the layoff of 500 employees with a
> > > breakdown by department and the names of several managers to be axed
> > > along with the managers current salaries. He addresses it to
> > > Pete_Smith @
organization .
com
> > > Ooops! UNO-what hits the fan after Pete posts this on a public
> > > company-wide discussion group...
[ stuff deleted ...]
> Michael Dillon: michael @
memra .
com responds
> But what if the ID's are a7a22640 @
org .
com and m3h33674 @
org .
com where the
> first letter is the division (a - executive, m - marketing), the next two
> characters represent a dept code and the last 4 are an employee id within
> the dept and the last digit is a checksum to prevent transposition errors.
>
> Or some similar sort of employee ID scheme.
[ stuff deleted ...]
> > In fact, from a human factors point of view, it seems likely that
> > "non-obvious" (a better term might be "user hostile") mail names are
> > *more* likely to cause misdelivery of mail, because it is less
> > obvious if one has mistyped an address.
>
> I believe the scheme should be chosen to make it difficult to mistype an
> address. The schemes I outline above essentially require 3 pieces on info
> to generate a complete address, either division/dept/emp-id or
> dept/name/physical-location
The non-obvious naming scheme is simply going to encourage people to not use
email and/or use the built-in alias/addressbook feature of the mailer to map
the encoded ID into something human readable like Pete_Smith or Peter_Smith
or pSmith ... You haven't solved the problem, just made it more obscure.
No one will remember the scheme because they will make an alias or address
book entry immediately.
A more feasible naming policy for a large organization might be via domain
or sub-domain
Peter_Smith @
corporate .
organiztion .
com - external
Peter_Smith @
corporate - internal
Pete_Smith @
advertising .
organization .
com
Joe_Smith @
mktg
Joseph_Smith @
engr
etc.
This is still not perfect but somewhat easier to remember and more along the
lines of traditional mail where folks use mail stops or departments to segment
the mail.
> > The point here is that a message of that level of business importance
> > should probably be hand delivered, not sent by any medium where there's
> > a noticeable possibility of misdelivery.
>
> Try telling that to the VP Finance. Remember, he's a bean counter and
> this is an information systems expert because he has a subscription to PC
> magazine.
Fact is the the VP Finance is responsible for the screw-up for not verifying
the delivery mechanism and taking appropriate care. We love to blame
technology or anything else when we screw up. Fact also is that he/she will
probably get nothing more than a slap on the wrist. After all 'he' is most
likely part of the good ol' boys group that is responsible for the layoff
in the first place due to lack of managment skills.
What it all comes down to once again is security (as a general term) must
be a comprehensive part of a companys' information infrastructure.
email naming conventions must be usable and understandable both internally
and externally if mistakes are to be avoided. Of course it would
help if we were working with an underlying infrastructure that at least
considered security, authorization and authentication from the get-go.
Unfortunately we are working with protocols that were designed wihtout these
aspects and everything is sort of hooked on.
Yes this means that your users and officers will be susceptible to mail bombs
which means the firewall and or perimeter needs to have an appropriate filter
installed and/or some manual scanning must take place. The perimeter
filtering would be easier if we had a mail system (or better yet a
communication infrastructure) that had true authentication built-in at the
protocol or language level. Of course it still won't be perfect, nothing is
but it would be better.
Steve Knox
--
Steve Knox (206) 775-6495
fortknox @
driftwood .
com Driftwood Systems, Inc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Microsoft is not the answer, Microsoft is the question.
No is the answer.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Follow-Ups:
|
|
