RFC 2449 describes a POP3 extension mechanism. A client can use the CAPA command to ask the server about any optional or enhanced capabilities. In the context of POPular there is one special problem with capabilities: The CAPA command can be send before or after authentication. But that means that the proxy and the server both have to be able to send the right answer back. To not confuse the client the answer in both cases must be the same or similar (for details see RFC 2449). Because the POPular proxy can be used with any server and it doesn't know about its capabilities it can't send a proper answer to a CAPA request on its own.
To solve this problem the proxy and the server can be configured to answer anything you like to a CAPA query. For different virtual servers, different CAPA listings can be saved. Note that, because a CAPA request can be sent before authentification, it is not possible to bind a list of capabilities to a backend server.
Setting up a capabilities list happens in two steps. First you edit a file in /etc/popular/capa (the directory can be changed through pcontrol with set capadir) and put all the capabilities you want to offer in that file. You can give the file any name you want. This name will later be used as the ID of this capability list in pcontrol.
The format of the capabilities file is easy. Just list the capabilities one per line, exactly as they are supposed to appear as answer to the CAPA command. Have a look at RFC 2449 for the details. If you get this wrong, the answer to the CAPA command might be not conforming to RFC 2449! Use a normal LF as line ending, POPular will automatically translate that to a proper CRLF line ending for the POP protocol. Note that there is a compiled in upper limit (MAXLEN_CAPA) on the length of all the capabilities joined together in one list.
After you have set up the file (or files) you can load the capabilities list into pproxy with the pcontrol utility. With capa load FILENAME the file is loaded. capa show NAME will show you the loaded capability list. Note that for printing purposes the list of capabilities will appear on one line, separated by commas. Capability lists can be reloaded at any time with the capa load command and deleted with capa del NAME. With capa list you can get a list of all currently loaded capability lists.
There are three special capability lists build into POPular: ERROR, NONE and DEFAULT. ERROR means to answer with an error to any CAPA command sent by the client, emulating an old server without CAPA support. NONE will send an empty capabilities list and DEFAULT will send a small list of capabilities that are supported by both pproxy and pserv. That means that if you use only POPular programs and no external servers you can use DEFAULT.
The last step is assigning a capability list to each virtual server. This can be done with the vserv conf VSERV capa CAPABILITY-ID command. You can set any of the three builtin capability lists or any of the ones you loaded.
The following capabilities are always supported by POPular: TOP, UIDL, USER and PIPELINING. SASL, RESP-CODES, and LOGIN-DELAY are not supported. The EXPIRE capability is outside the scope of the POPular software, but you might want to use it. The default capability list does not include the IMPLEMENTATION capability. If you want to use it, please use 'IMPLEMENTATION POPular-<version>'.