It does not seem to be possible to deny registration.
The configuration variables in security.txt do not seem
to work and there is no example in config.py.

Strangely enough I also get other errors with that
registration.
Namely: 

 Traceback (most recent call last):
  File
"/spare/roundup/0.5.0/lib/python2.1/site-packages/roundup/cgi/client.py",
line 405, in handle_action
    getattr(self, method)()
  File
"/spare/roundup/0.5.0/lib/python2.1/site-packages/roundup/cgi/client.py",
line 607, in registerAction
    if self.session:
AttributeError: Client instance has no attribute 'session'

Logged In: YES 
user_id=113859

Okay, I found information in the upgrading documentation.
This still is a documentation bug because the security.txt
file is shipped.

The second part of the bug stays misterious to me so far.

Logged In: YES 
user_id=6405

I've removed the security and templating working docs from the dist     
for 0.5.1. Did you upgrade from a 0.4 installation?  If so, did you follow   
all the steps in the upgrading doc? If you didn't,  why not?    
   
Otherwise, do the docs in the customisation doc help at all?   
  
I've patched the bug in registerAction in the CVS. The line which says:  
  if self.session  
should say:  
 if hasattr(self, 'session'): 
 

Logged In: YES 
user_id=113859

I did not upgrade from a 0.4 installation. Reading the
upgrading docs would
have helped.

The docs in the customisation section do help. I've found
quite some rought edges in the documentation but in the
process of getting the stuff installed and working I did not
recorded them for reporting.

As for this bug I think that you should add a hint to the
classic config.py
and switch off registration as users by default.

Logged In: YES 
user_id=6405

Please consider going back over the documentation and make some  
notes regarding sections that are confusing or lacking in detail.  
 
What would the hint in the config.py allude to? 
 
I have polled the users of roundup, and they're split 50/50 on whether 
to have the default to allow or deny email rego. I'm firmly in the allow 
camp, and haven't seen a convincing argument from the deny camp. 

Logged In: YES 
user_id=6405