Conference iosg::all-in-1_v30

>    Any suggestions of disabling the SUBSCRIBERS: even when a partial
>    address is entered ?
    
    Upgrade to 3.0. Two profile flags to prevent users from
    sending and/or receiving mail to SUBSCIBERS are added.
    
    I doubt wether 2.3 or 2.4 will ever get this functionality.
    
    Regards,
    
    Jan
    
    
    

    *I* can't find the field in profile that defines that a user
    wil not receive SUBSCRIBER mail. The privilege SUP is for 
    sending SUBSCRIBER mail to remote nodes and SUBSCR is the 
    privilege to send SUBSCRIBER mail.
    
    Management Guide 4-31 talks about a field, but I am too blind 
    to see. (I've been wading through the profil forms 4 times).
    
    Where is it...?
    /rhr

    It is a hidden field "RCV$SUB".
    
    <GET PROFIL.RCV$SUB["username"] (will show the current contents)
    
    <WRITE CHANGE PROFIL %KEY="username",RCV$SUB=OA$N (or "N") will change
    it.
    

    *If* I asked the question why it is hidden, whilst it is explained
    as not hidden in the documentation, I'd probably be asked to SPR it
    or some such thing.
    So I guess I better keep quiet.
    Thanks for the appreciated pointer.
    /rhr

    Sorry, but I can see the "Receive SUBSCRIBERS: Mail" field on form
    PROFIL5. I don't think I'm using a special version as I've checked my
    own system and that running on IOSG...
    
    Tony
    
                          User Profile - continued (5)

 Working conditions when reading:
   Status line display [Y/N]:   Y       Read screen wide [Y/N]:      N

 Confirmation prompts:
   GOLD GET selection [Y/N]:    N       Delete unread mail [Y/N]:    Y
   New folder prompt [Y/N]:     N       Forwarding cover note [Y/N]: N
   Document deletion [Y/N]:     N       Delete job [Y/N]:            N

 CDA documents:   CDA storage:  A       CDA handling:                A

   Classification:                      Categories:
   Create new group [Y/N]:      Y       Receive SUBSCRIBERS: Mail [Y/N]: Y

   Orgunit1:
   Orgunit2:
   Orgunit3:
   Orgunit4:

   Date/time of last modification: 1992052200164402

 Press RETURN to complete or PREV SCREEN to go back

    I believe that the distinguished Irishman is taking the use of the word
    Profile literally to mean the PROFILx form-set whereas I am sure that
    both Regina and Mike (peg-leg) Lamberson are talking about the
    profile as it seen by the System Manager (SM MUA E) or the user (US
    SWC) where the RCV$SUB field is indeed "hidden" - the reasons for
    this are discussed in an earlier note by GAP which a SEARCH will find.
    
    Real Programmers of course use <FORM PROFIL but Real Users and those
    that support them whilst still being carbon based life-forms for some
    reason use the documented menu options.
    
    Regards,
    
    Andrew.D.Wicks

Further to .0, if you can't wait for V3, you can always remove it from its 
definition in OALLV (or is it still in OAGBL?). The code which does partial 
name validation will check against the 'subscribers' string in the table in 
OALLV. If you delete that entry, recompile, relink, reinstall, (retire?), 
nobody will ever be able to send mail to SUBSCRIBERS: ever again . . .

grahame

    I agree that it's silly to stop users turning themselves off
    SUBSCRIBERS:, but maybe it was a thought police decision (You will
    receive SUBSCRIBERS: mail whether you like it or not...)  But maybe
    also it's a cunningly disguised opprtunity for people to discover just
    how easy it is to customize the User Setup forms?
    
    Tony

    I can't find my previous sermon about the SUBSCRIBERS flags, so perhaps
    it was in the FT conference. So rather than looking for it, here it is
    again...
    
    PRVSUB - This field controls whether you can send to SUBSCRIBERS: it's
    tested at address validation time when you're creating the message, but
    it's also tested in other parts of the mail code to stop you sneaking
    in a message through direct calls to the API. I think it's watertight
    now, but I await your SPRs...
    
    This field is on PROFIL, but not on PROFILe, so users can't change it.
    It's also settable from templates, and editable from System Management.
    
    RCV$SUB - This fields controls whether mail addressed to SUBSCRIBERS:
    will be delivered to you. There are other rules which control this, but
    I won't go into those here....
    
    This field is on PROFIL, and using <FORM PROFIL is the only way to
    change it, there's no support for changing it from System Management or
    Templates.
    
    However, it is also on PROFILe, so although it isn't on US SWC, it
    *CAN* be changed by unprivileged users. As Tony says, it would be a
    simple customisation to SWC to add it. A knowledgeable and CMDPRV'd or
    PRVUDPFNC'd user could also do <WRITE CHANGE PROFIL etc. too.
    
    The reason for this is because I was advised, during Field Test, that
    people used SUBSCRIBERS: for sending important mail messages, and users
    shouldn't be alowed to accidentally (or intentionally) prevent these
    being delivered. I argued that if only "important" people were
    privileged to send to SUBSCRIBERS:, then people would soon realise that
    the messages were worth reading and not want to stop receiving them,
    however...
    
    Next, I thought of making mail from MANAGER addressed to SUBSCRIBERS:
    be delivered even if you had RCV$SUB turned off, but field testers said
    that they wanted to send "important" mail from other accounts. Since my
    next plan of granting an "important mail" privilege would have meant
    another profile flag, I stopped development...
    
    So as a compromise (I am British after all :-) ) I removed RCV$SUB form
    US SWC so that people couldn't turn it off accidentally, but left it on
    PROFILe so it would be easy to customise back in if your site thought
    that was appropriate.
    
    Graham (trying to write longer notes than Frank :-) )
    
    PS PRVSUP is really to stop you geting to FMS "SUPERVISOR" fields,
    but for some arcane reason it's also used to control who can send to
    SUBSCRIBERS: on remote nodes (e.g. SUBSCRIBERS: @ IOSG) you still need
    PRVSUB as well.

    Thanks Graham,
    
    for the history. I couldn't find your previous note about SUBSCRIBERS:
    neither. I think it is a good idea to not allow users to turn
    this off, as we do hope that people who have received the send to
    subscribers privilege should only be sending important messages. 
    (otherwise the privilege is quite fast removd again).
    
    Now that I know it is called RCV$SUB I have no problem changing it for 
    specific users, but I just stumbled about the doc, which does not mention 
    that the field is hidden. This was my real point.
    
    regards
    Regina
    
    
    

    Regina,
    
    I think it's only described in the release notes.
    
    I argued the same as you, that if only the right people got PRVSUB,
    then junk mail wouldn't be sent (or else they'd soon lose the priv. as
    you say!) and hence people would want to receive the mail. But it was
    argued that people might turn it off by accident.
    
    Hence my not very tidy compromise implementation.
    
    Graham

    I believe that SUBSCRIBERS started off as a privileged-only address,
    but all users were given the "right" to use it based on field test
    feedback in V2.0.