fetchmail-users

[fetchmail-users] Fetchmail 6.3.0 released

[Rob F. <rf...@fu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The Community Fetchmail team is happy to announce the release of
Fetchmail 6.3.0 on 30 November, 2005.

More than two years after the previous formal 6.2.5 release, this
collects several dozen bug fixes, documentation, portability and IPv6
improvements and marks the beginning of a new "stable" 6.3.X branch
that will not change, except for bug fixes and documentation updates.

This is also the first major release from the new Community Fetchmail
maintenance team, which took over from longtime maintainer Eric S.
Raymond in June 2004.  As a result of this change, the Fetchmail
home page moved to:
  http://fetchmail.berlios.de/
And the mailing list focus has moved to the lists hosted at Berlios,
located at:
  http://developer.berlios.de/mail/?group_id=1824

Future versions of Fetchmail with new features or changes that affect
Fetchmail's behavior will be called 6.4.0 or 7.0.0 depending how large
the impact is.  This means that we will not have "gold" releases any
more, but instead the 6.3.X release with the greatest X is usually the
best.

Changes between Fetchmail 6.2.5 and 6.3.0:
The --netsec/-T options were removed. The --smtphost is now always
"localhost". fetchmail now uses automake. Internationalization now
requires gettext 0.14 to be installed separately. More than 140
user-visible changes were made, most of them bugfixes. Some
documentation and translation updates were made to improve stability
and protocol conformance, to improve bounce and warning messages, and
to improve portability.

(Note: for those who downloaded the .asc GnuPG signature file in the
first 23 hours after release, they will have seen "BAD signature". The
signature file was broken by the maintainer's last-minute change to
the NEWS file. A new signature file was uploaded on 2005-12-01 at
23:57 UTC.)


About Fetchmail:
Fetchmail is a free, full-featured, robust, well-documented
remote-mail retrieval and forwarding utility intended to be used over
on-demand TCP/IP links (such as SLIP or PPP connections). It supports
every remote-mail protocol now in use on the Internet: POP2, POP3,
RPOP, APOP, KPOP, all flavors of IMAP, and ESMTP ETRN. It can even
support IPv6 and IPSEC.

http://fetchmail.berlios.de/

- -- 
==============================| "A slice of life isn't the whole cake
 Rob Funk <rf...@fu...> | One tooth will never make a full grin"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDlllNC+BU/gUoZAMRArMYAJ0ahklzCKWTMQpPjOLBEO9axKWROgCfZfre
QOHK0M3WNJcLymdpQnw6mPw=
=eZUA
-----END PGP SIGNATURE-----

Re: [fetchmail-users] Fetchmail 6.3.0 released

[Rob M. <rob...@gm...>]

On 07/12/05, Rob Funk <rf...@fu...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The Community Fetchmail team is happy to announce the release of
> Fetchmail 6.3.0 on 30 November, 2005.

I've found what may be a bug (ore more likely a change in the logging output).

As I have a number of mail servers to poll each has it's own fetchids
file in /etc, owned by the relevant user.  Before 6.3 this *appeared*
to work ok (the file was added to anyway).  Under 6.3.0 I get the
following for each file, at startup:

Error deleting /etc/fetchids-one: Permission denied

I've solve the problem by giving each user it's own directory for
fetchmail config files under /etc (and the result is a little
cleaner).  Never spotted the problem before 'cos I'd only run
fetchmail 6.3 against the primary config, owned by root :)

--
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] Fetchmail 6.3.0 released

[Matthias A. <mat...@gm...>]

Rob MacGregor <rob...@gm...> writes:

> I've found what may be a bug (ore more likely a change in the logging output).
>
> As I have a number of mail servers to poll each has it's own fetchids
> file in /etc, owned by the relevant user.  Before 6.3 this *appeared*
> to work ok (the file was added to anyway).  Under 6.3.0 I get the
> following for each file, at startup:
>
> Error deleting /etc/fetchids-one: Permission denied

What is your master configuration?

(no, we don't need your passwords, we'll have poultry, not fish today :)

-- 
Matthias Andree

Re: [fetchmail-users] Fetchmail 6.3.0 released

[Rob M. <rob...@gm...>]

On 07/12/05, Matthias Andree <mat...@gm...> wrote:
>
> What is your master configuration?

I don't really have one, what I have is a number of files that start like this:

defaults proto pop3                     # Default to POP3 mail servers
        no rewrite                      # Don't rewrite headers
                # NOTE: the TRACEPOLLS line is supressed if the
following is used...
        set invisible                   # Don't appear in headers
        set no bouncemail               # Don't bounce mail in error -
give it to...
        set syslog                      # Log to syslog under the "mail" heading
        set idfile      /etc/fetchids-by        # Where to store the
POP3 UID lists

With the idfile changing for each one.  I've got a total of 4 separate
fetchmailrcs and fetchid files (one for each ISP effectively).  None
of these run as root, so the files in /etc look like:

-rw-------  1 fetchmail-by     wheel     0 Dec  4 22:32 fetchids-by
-rw-------  1 fetchmail-lance  wheel   237 Dec  7 07:19 fetchids-lance
-rw-------  1 fetchmail-one    wheel     0 Jan 23  2004 fetchids-one
-rw-------  1 fetchmail-other  wheel     0 Jan 23  2004 fetchids-other
-rw-------  1 fetchmail-by     wheel  2545 Dec  5 21:18 fetchmailrc-by
-rw-------  1 fetchmail-lance  wheel  1133 Dec  2 14:44 fetchmailrc-lance
-rw-------  1 fetchmail-one    wheel  2381 Oct  3 07:47 fetchmailrc-one
-rw-------  1 fetchmail-other  wheel  1144 Oct 28 05:54 fetchmailrc-other

The solution was easy, create an /etc/fetchmail directory, with
subdirectories for each account.  It's just that the error message
didn't appear under 6.2.x, though it's entirely possible it was
equally broken (on that note, I'm pleased to see a general improvement
of error message quality, including mailbox names in some of the more
common messages was a stroke of genius on somebody's part).

On a vaguely unrelated note - there's a documentation error relating
to ssl support.  Having just this morning noticed that one of my
remote providers supports TLS I set about getting things working, what
caught me was:

(Keyword: sslcertpath) Sets the directory fetchmail uses to look up
local certificates. The default is your OpenSSL default one.

Well, actually, it doesn't look like there is a default (at least not
on FreeBSD 5.4).  I had to explicitly state the path for each server I
was polling.

--
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] Fetchmail 6.3.0 released

[Rob M. <rob...@gm...>]

On 07/12/05, Matthias Andree <mat...@gm...> wrote:
>
> Please drop the attached patch-file into your
> ports/mail/fetchmail/files/ directory (as patch-socket.c) and rebuild
> (aka "make clean && make all deinstall install clean") then let me know
> if your problem is fixed.

That didn't (quite) do it I'm afraid:

fetchmail: Server certificate verification error: unable to get local
issuer certificate
fetchmail: Server certificate verification error: certificate not trusted
fetchmail: Server certificate verification error: unable to verify the
first certificate

I still need "ssl sslcertpath /usr/local/openssl/certs" in my
fetchmailrc to get it to work.

Now, checking the libraries fetchmail is linked against the system
openssl, whereas c_rehash is coming from the port install of openssl. 
Having finally found the c_rehash tool in the FreeBSD source tree I
worked out where it expected the certificates (/usr/local/ssl/certs,
when /usr/local/ssl doesn't exist), but that made no difference
either.

So, finally digging through a truss shows that fetchmail/system
openssl is looking in /etc/ssl/certs (which doesn't exist), not
/usr/local/<anything>.  Nice consistency :-)

One sym-link later and all is working as it should.  Not sure how you
could patch for this though - the whole openssl install is a bit of a
mess, with the system tools looking in 2 different locations and the
port in another.

--
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] Fetchmail 6.3.0 released

[Matthias A. <mat...@gm...>]

Rob MacGregor <rob...@gm...> writes:

> So, finally digging through a truss shows that fetchmail/system
> openssl is looking in /etc/ssl/certs (which doesn't exist), not
> /usr/local/<anything>.  Nice consistency :-)
>
> One sym-link later and all is working as it should.  Not sure how you
> could patch for this though - the whole openssl install is a bit of a
> mess, with the system tools looking in 2 different locations and the
> port in another.

I'm very much inclined to see this as a FreeBSD system or port bug in
OpenSSL - the same patch works for me on Linux, where /etc/ssl/certs is
the right place to look.

Can you file a FreeBSD PR against OpenSSL with your findings? Someone
has to look after this, and c_rehash should also be installed (or
rewritten if it's in Perl - which is no longer part of the base
install).

-- 
Matthias Andree