I've gone ahead and removed the defaults; '' (empty string) is valid 
for remote mailboxes, and since they were never used...

Well, if we're going to keep the defaults, we should make them show up 
in the UI somehow. Possibly by having $fm_account->getValue() return 
the default if the $account key is null; then it's just a matter of 
finding a nice way for $fm_account to get its default values - I 
looked at the code some and it wasn't falling in to pace for me.
Probably not, but I'd be wary of running into a case (maybe with a 
parameter that hasn't been added yet, even) where there's a non-empty 
default for a parameter that can validly be empty. We don't want to 
make it impossible for users to zero out parameters that can be empty.



Moving the whole fetchmail form to use Horde_Form would actually take 
care of all of this.

IMP_Fetchmail_imap supplies defaults for {l,r}mailbox in its constructor:



     function IMP_Fetchmail_imap($params)

     {

         /* Default values for a couple of parameters. */

         $defaults = array(

             'rmailbox' => 'INBOX',

             'lmailbox' => 'INBOX'

         );

         $params = array_merge($defaults, $params);



but these values never apply because imp/fetchmailprefs.php 
unconditionally sets all parameters:



     foreach ($fetchmail->getParameterList() as $val) {

         $fm_account->setValue($val, Util::getFormData('fm_' . $val), 
$to_edit);

     }



so they wind up being empty strings ("").



Should IMP_Fetchmail_imap() override empty strings with the defaults? 
Does having an empty value for {l,r}mailbox make any sense (IOW, do 
any remote servers interpret this as a sane default)?