Hi Julien,

>> I also don't understand why START_TLS and AUTHINFO need to change
>> how the module is interfaced to (separating log in/authentication, etc)

> Because once you have used AUTHINFO, STARTTLS is no longer a valid
> command in a session.

I understand this, but doesn't this mean the init function needs to change to something like:

init:
  if capability STARTTLS is advertised 
    STARTLS stuff
    reget capabilities because STARTTLS changed them probably

  Now handle AUTHINFO Stuff

Is there a case where a server advertises STARTTLS and one would not use it?  If so then couldn't that just be handled with an option to the class inhibiting it?

This is one of the reasons why I proposed dividing the job across two features. 
1. Simple NNTPS which seems to be the most common secured NNTP in use at the moment and is easy to implement, and verify (either as an improvement to the NNTP class or as a new NNTP_SSL class). 
2. SASL AUTHINFO/STARTTLS Extension handling implementation and improvements.  

There are also other bugs with properly handling capabilities at start related to this, are there not? http://bugs.python.org/issue10287