[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

3483.0. "Feedback required for remote address formats" by SCOTTC::MARSHALL (Spitfire Drivers Do It Topless) Tue Nov 02 1993 11:35

Hi,

** This topic relates to a PFR of ALL-IN-1, but I'm posting it in this  **
** conference as I need feedback on the current behaviour in this area. **
** Nothing in this note implies any commitment to make any changes, fix **
** any problems, or provide any new functionality in a PFR.             **


As part of my work on a PFR of ALL-IN-1, I need to define (a bit more strictly
than has been done before) what a remote address string can look like.

In particular, the following oddball cases are all currently permitted, but
we would like to do away with them (all would give an error saying there is a
missing ROUTE or USERID term, as appropriate).  Do you know of any mail address
that relies on any of these formats working the way they do in V3.0?

Mail address           V3.0 behaviour
----------------------------------------------------------------
AT ABC @ MBX        -> "AT ABC" is treated as the USERID

ABC AT@ MBX         -> "ABC AT" is treated as the USERID

ABC @AT MBX         -> "AT MBX" is treated as a ROUTE term

ABC @ MBX AT@ NODE  -> "MBX AT" is treated as a ROUTE term

ABC @ @ MBX         -> "@ @" is treated as a single "@"

ABC AT AT MBX       -> " AT AT " is treated as a single " AT "


We would like to change the behaviour of the following type of address:

"FOO"AT"MBX" @ NODE -> "FOO"AT"BAR" is treated as the USERID

For V3.1, this would take "FOO" as the USERID, and "MBX" and NODE as ROUTE
terms.

Finally, addresses of the form: @ABC @ MBX @ NODE, which do not work in V3.0
(the USERID is taken as "ABC"), should now use "@ABC" as the USERID.

Scott
T.RTitleUserPersonal
Name
DateLines
3483.1Account AT?HSKPRF::TAURIAINENHackaa p��lle!Wed Nov 03 1993 05:3511
    If a persons initials were "AT" and user accounts were based on
    initials how would AT @ NODE be processed? (I know of place where they
    use "DEPARTMENT_INITIALS" as user accounts but I don't know of any place
    where they'd use "DEPARTMENT INITIALS" as user accounts in ALL-IN-1 -
    that would cause problems with initials AT)
    
    --Matti
    
    PS. (This has nothing to do with ALL-IN-1, but) I always change the DEC
    MAILworks default mailbox "AM" to "A1M" AM when installing the
    MAILworks server, since AM might get mixed up with somebodys initials.
3483.2CSOA1::LENNIGDave (N8JCX), MIG, @CYOWed Nov 03 1993 22:157
    Keep in mund that IOS pre-PFR talks NBS V1. Among other things this
    means address strings are presented to MR as just that - a single
    string. TS has to parse it into userid/route elements. In that context,
    <space>AT<space> (and all variations of capitalization) is treated as 
    an @ delimiter. If it doesn't match this the AT is used as is.
    
    Dave
3483.3SCOTTC::MARSHALLSpitfire Drivers Do It ToplessMon Nov 08 1993 16:197
Dave,

Yes, it's precisely because we now have to do what the TS used to do for us
that I put this note in.  We're trying to be cleverer about route term
delimiters than the (ancient) TS interface we were using was!

Scott