Conference iosg::all-in-1_v30

    Suzanne,
    
    You're sure it's searching DDS (yes I'm sure you are) - the mail code
    shouldn't even get as far as searching profile, network or dds once
    it sees one of those @'s it's supposed to realise it's remote mail
    and hurry on back to the message header
    
    No of course I can't reproduce it - was this before or after the Friday
    lunchtime drink (:==:)?
    
    Regards,
    
    Andrew.D.Wicks

Hi,

The mail address validation code only looks for '@' symbols after it has
exhausted all other possibilities.  So it will try and find a match in DDS.

The flow goes something like this:

- Is the address a nickname
- Is it a distribution list
- Is it in profile/DDS
- Is it in Network
- Does it contain an @
- If none of the above, error

The code jumps out of this sequence as soon as it finds a match.

So it looks to (innocent, naive) me that something in your X.400 address is
matching with something in DDS.

All I can suggest is: enter the address using the X400 form, and see if the
result that's put back in the 'TO' field is different (including such apparently
trivial things as spaces) from what the user enters directly.  If so, get the
user to enter the address directly in the same form as the X400 form would do
it, and see if that fixes the problem.

Scott

    We only have a small dds system, and I have typed in the address that
    the customer is using. i.e.
    DAVE INESON@8=M@3=BPAUS@2=OTC@1=AU@TMAILUK@LHR2
    
    and it still leaves me in dds i.e.
    
                                     Mail Directory
    ----------------------------------------------------------------------------
     Select an addressee from the following:
    ----------------------------------------------------------------------------
     1   MANAGER             DEPT                       ( ALL-IN-1 MANAGER  )
     2   Symbiont                                       ( Script Symbiont   )
     3   guest               Office Applications        ( iosg guest        )
     4   salmon              Office Applications        ( jason salmon      )
     5   Simpson             Office Applications        ( Richard Simpson   )
     6   B                                              ( C B               )
     7   Talbot              Office Applications        ( Trevor Talbot     )
     8   Othen               TEMP                       ( Julie Othen       )
     9   barham              Office Applications        ( clive barham      )
     10  REVSVERYLONGADDRES                             (TREVSVERYLONGADDRESSEE )
     11  MYSNADS                                        ( MYSNADS           )
     12                                                 (                   )
     13  Crooks              Special                    ( Alan Crooks       )
     14  jackson                                        ( peter jackson     )
     15  SIMPSON_BG          Office Applications        ( RICHARDvSIMPSON_BG)
     16  cooper              Office Applications        ( suzanne cooper    )
    
    ---------------------------------------------------------------------------
    
    well that's our total dds entries,  I can't see what it thinks it
    matched on, (ehatever the match is it's all records).  Can anyone
    reproduce this using the address provided above.

    Just a stupid question....
    
    where on the x400 form is the field that corresponds to the @8= ?
    
    When I enter everthing else on the x400 form it seems to work, if then
    copy the line (spaces, capitals everything I can see is the same) it
    searches the mail directory.
    
    I don't understand this?
    
    Confused of Basingstoke.

Hello Suzanne,

We can also reproduce your problem when using a nickname for a X400 address
and the OA$DDS_PRIME is set to 2.

At customer site the problem is worse as it seems that adressing a X400	
nickname ends in a loop when DDS is called. 

Until now I could not log to customer's system to analyse - so it is not for
sure that the customer has a loop because of lots of DDS entries or if there
might be another problem with DDS.

As temporary workround they can use a distribution list instead of a nickname.


Regards,
Manuela   

    In reverse order...
    
    .5 this is a different problem, please start a new note...
    
    .4 8 is of course Initials and isn't supported by the X.400 form
       though of course it can be customised using CM to do so, 9 which
       is generation is also unsupported.
    
       If you type out X400.CMU you'll see it only supports attributes
       1-->5
    
    .3 Well I typed out the address you used and it didn't find any matches
       so it put the address as typed on the right and Remote Address on
       the left so i've no idea what it's matching on on your system!
    
    regards,
      
    Andrew.D.Wicks

    Andy,
    
    	Could you trace this and mail me, I just want to see if there are
    any differences.  I tried several times, to get a trace when it works
    but to no avail.
    
    Thanks in advance 
    Suzanne

    Suzanne,
    
    Oh **** (rude word) - the system I was testing on was v3.0 unpatched
    when I tried it on our v3.0-1 system to get you a trace guess what 
    happened!??
    
    So, this must have been introduced in V3.0-1. Please report it.

    Regards,
    
    Andrew.D.Wicks

    Thanks for that, I'm glad I'm not going mad (no rude comments please.)
    
    A CLD it might have to be as SPR's are a thing of the past.........
    
    Suzanne

    Suzanne,
 
    It might even be worse than that! can you send any remote mail with
    OA$DDS_PRIME set to 2?
    
    when I tried user@mailbox@node I get 
    You cannot send to Remote addressees on this system
       
    I never could get the hang of this DDS stuff (:==:) please make sure you 
    suggest in the CLD text that the fix should be done urgently.
    
    regards,
    
    Andrew.D.Wicks

Sorry, this isn't intended personally, but it seems to be the prevailing
attitude and it makes me angry:

>> A CLD it might have to be as SPR's are a thing of the past

The only reason SPR response is slow is because too many people are submitting
CLDs for trivial things that shouldn't be CLDs in the first place.  Thus too
much time is spent in engineering "fire-fighting" trying to fix CLD problems,
instead of getting on with fixing SPRs.  Also, far too many problems end up in
engineering that should have been answered before they ever reach us.  CSSE has
gone away, but the work they did hasn't, and it's all ended up in our lap.  Thus
throwing more CLDs at engineering thinking that will solve problems is an
illusion; it only makes things worse.

There, I feel better now :-)

Scott

    Hi,
    
    I will join in now!!
    
    Scott - are you not aware that the SPR group in the States has gone away, 
    so we cannot send out ANY spr's from the CSC until IPMT is implemented - 
    so if a customer requires a fix before then, what can we do????
    
    
    		Julie

    Please beat up the organisation that made this non-optimal decision,
    not use up my disc space!
    
    Graham

Hello.

I'm very sympathetic to the problems of reporting SPR level problems while 
the mechanisms are being changed, and - no doubt - ultimately and 
eventually much improved. However, I will ask please try to avoid raising CLD 
for SPR level problems if you possibly can.

I know this is a difficult request. The reason I make it is that the CLD 
process was originally designed for urgent and critical problems with the 
assumption that these are relatively infrequent. Consequently, the CLD 
process has a lot of overhead, management activity, reporting, etc. etc. 
associated with it. As the arrival rate increases, the overall efficiency of 
the whole thing declines to the point where less than 10% of the work done is 
actually directed at fixing a problem. The rest is memos, phone calls, and 
meetings, all of which we are absolutely required to do.

Ideally, we'd like to cut our response time for both CLD and SPR-level 
problems because we know that improvements are required. If we can reserve 
CLDs for the really critical things that will help us.

Thanks,

	Richard.

    There are clearly 2 MAJOR issues in note 2681.*
    1) V3.0-1 introduced problem with X.400 address handling
    2) The SPR system is apparently broken.
    
    We are currently investigating 1) and will try to report when resolved
    or patched.
    
    As far as the Corporate SPR system is concerned - I have opened up a 
    new note (2702.0) on this subject.
    
    Martin.
                     

    Martin,
    
    I would argue that the technical problem is not X.400 address
    handling but any remote mail handling i.e if I type in COOK@A1@IOSG
    I cannot send you mail (this isn't X.400). 
    
    Just want to make sure we have a clear and concise problem
    description.
    
    Regards,
    
    Andrew.D.Wicks

    
    OK... some news on this problem...
    
    Investigation shows this is a problem with '=' in addresses so it
    affects X.400 more than anything else.
    
    [Andy - your problem seems to be something different - can you check
     that your system is linked with DDS support and check your MR setup.]
    
    For purposes of explanation, the handling of addresses with DDS is as
    follows: 
    
    1. Look up SURNAME (.USER) using an exact match     ]
    2. Look up COMMNAME using an exact match            ]  VALIDATION
    3. Look at NETWORK, NICKNAMES etc etc.              ]
    4. Look to see if it is a remote address            ]
    
    5. Check for SURNAME using inexact (starting) match ]
    6. Lookup COMMNAME using inexact match              ] RECOGNITION
    7. Look up NETWORK, NICKNAMES etc. inexact match    ]
    
    In practice it is a little more complicated because there seems to be a
    partially implemented concept of freeform DDS searches. For the sake of
    sanity, I ignore this here.
    
    The way that DDS searches work is that they build up specific search
    terms from the request. They check for .USER == string or .COMMNAME ==
    string by asking DDS to return entries matching these. Additional
    functionality has been coded in for some reason to allow specific
    fields to be used in the search using:
    
    field=value,...
    
    I don't believe this is documented or has ever been supported (Andy -
    do you know different here?). When this processing is invoked, it
    doesn't do the COMMNAME search. In the examples which break, the '='
    sign in the address triggers this field-name processing but "8" is not
    a valid SUBSCRIBER DSAB field name. For valid field names, a search
    term is generated for DDS, but for invalid or unrecognised field names,
    no term is generated.
    
    Therefore, in the case of 8=, NO search terms are generated for DDS and
    hence ALL DDS entries match and are presented. 
    
    We here in Support are proposing to change this '=' processing so that
    it is only invoked during recognition (otherwise it may prevent exact
    DDS matches and/or remote address validation) and also change it so
    that at least one valid field name must be present to invoke this form
    of search. The code gives up on the first invalid field name so
    anything which isn't exactly in the right "field=value" format will
    just use the USER/COMMNAME search.
    
    All of these problems are in the OADDS code - but what actually broke
    this in V3.0-1 was a change to another part of the MAIL system to allow
    COMMNAME searches to take place in a different order. This caused the
    "field=value" logic to kick in earlier - before remote address
    validation.
    
    What interests me is whether anyone even knew of the existence of this
    "field=value" form of search and whether any customer is likely to be
    using it. If not, we could kill this logic altogether? As always, the
    problem with MAIL addressing is that there is no spec and nobody admits
    to knowing how it should work. Customers seem to know more than we do!
    
    Comments and Thoughts?
    
    Paul.