Log Message:
Update to 3.07:

3.07 2015-07-17

    - Net::FTP::rmdir() has been made more robust by making use of the MLSD
      command in addition to the NLST command since the latter is known not to
      be processed correctly by some FTP servers.

      [Chris Lindee, CPAN RT#100694]

    - Net::FTP, Net::NNTP, Net::POP3 and Net::SMTP can now restrict domain to
      IPv4 even if IPv6 is available by using the new Domain or Family argument.

      Net::NNTP now supports the LocalPort argument in addition to LocalAddr.

      Net::POP3 now supports the LocalAddr and LocalPort arguments in addition
      to ResvPort (which is retained for backwards compatibility).

      [Steffen Ullrich, PR#18]

    - Fixed a bug in Net::Cmd::datasend() which caused octets in [\x80-\xFF]
      stored in a "binary string" to be replaced with their UTF-8 \ 
encodings if
      the string happened to be stored internally in an "upgraded" \ 
state (i.e.
      with the UTF-8 flag on).  (As noted below, strings passed to datasend()
      should always be encoded first, and therefore not stored in such a state
      anyway, but it is all too easy for perl to change this internal state
      unless the encodeing is done at the very last minute before calling
      datasend(), so it helps if datasend() plays more nicely in this case.  In
      particular, it was wrong of datasend() to treat upgraded and downgraded
      strings differently when their contents were identical at the Perl level.)

      This bugfix results in a breaking change to the case of a "text \ 
string"
      with characters in U+0080..U+00FF stored internally in an upgraded state
      since those characters are likewise no longer encoded to UTF-8 by
      datasend(), but callers of datasend() should not have been relying on this
      behaviour anyway: In general, datasend() has no idea what encoding is
      required for output so callers should always encode the data to be output
      to whatever encoding is required first.  This has now been clarified in
      the documentation.

      Finally, a text string with characters >= U+0100 will now cause a "Wide
      character in print" warning from datasend() since such characters cannot
      be output as bytes and datasend() no longer encodes to UTF-8.  In this
      case, UTF-8 bytes will still be output as before since that happens to be
      the internal representation of such characters, but the warning is new.
      Callers should heed this warning and encode such strings to whatever
      encoding is required before calling datasend(), as noted above.

      [Ricardo Signes, CPAN RT#104433]