fetchmail-users — User questions and discussion

Re: [fetchmail-users] Fetchmail 6.3.0 released

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

On 10/12/05, Simon Barner <ba...@fr...> wrote:
>
> The security/ca-roots port creates a link from /etc/ssl/cert.pem ->
> /usr/local/share/certs/ca-root.crt
>
> I've just verified that fetchmail picks up those certificates if they
> are installed onto a pristine /etc/ssl.
>
> I'll think about adding a dependency in fetchmail.

Please do - I can confirm that installing security/ca-roots solves the
problem on my system.

--
                 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

[Simon B. <ba...@Fr...>]

Rob MacGregor wrote:
> On 10/12/05, Simon Barner <ba...@fr...> wrote:
> >
> > The patch is included in fetchmail-6.3.0_1. Thanks for the quick fix,
> > Matthias!
> 
> Only problem is - it doesn't really fix anything without some other
> finger waving.
> 
> Poking around, using truss etc, I discovered that the base libraries
> look in /etc/ssl/certs, the version of c_rehash (that doesn't get
> installed) that hides in the source tree looks in /usr/local/ssl/certs
> and the ports version of openssl looks in /usr/local/openssl/certs.
> 
> In short, a bit of a mess :-)
> 
> So, the only way to get it to work is to point /etc/ssl/certs at
> /usr/local/openssl/certs and use the c_rehash that comes with the port
> (but given the version differences, I doubt that's a good idea, even
> if it's what I've done).  Or to edit and install the c_rehash that
> comes with the source tree, but doesn't get installed (and create the
> top level directory required).

The security/ca-roots port creates a link from /etc/ssl/cert.pem ->
/usr/local/share/certs/ca-root.crt

I've just verified that fetchmail picks up those certificates if they
are installed onto a pristine /etc/ssl.

I'll think about adding a dependency in fetchmail.

> 
> I'm happy to raise a PR about this as I'd like to see this easier for
> others to get working - FreeBSD really shouldn't be this hard, that's
> what Linux is for :-)
> 
> --
>                  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

-- 
Best regards / Viele Grüße,                             ba...@Fr...
 Simon Barner                                                ba...@gm...

Re: [fetchmail-users] Fetchmail 6.3.0 released

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

On 10/12/05, Simon Barner <ba...@fr...> wrote:
>
> The patch is included in fetchmail-6.3.0_1. Thanks for the quick fix,
> Matthias!

Only problem is - it doesn't really fix anything without some other
finger waving.

Poking around, using truss etc, I discovered that the base libraries
look in /etc/ssl/certs, the version of c_rehash (that doesn't get
installed) that hides in the source tree looks in /usr/local/ssl/certs
and the ports version of openssl looks in /usr/local/openssl/certs.

In short, a bit of a mess :-)

So, the only way to get it to work is to point /etc/ssl/certs at
/usr/local/openssl/certs and use the c_rehash that comes with the port
(but given the version differences, I doubt that's a good idea, even
if it's what I've done).  Or to edit and install the c_rehash that
comes with the source tree, but doesn't get installed (and create the
top level directory required).

I'm happy to raise a PR about this as I'd like to see this easier for
others to get working - FreeBSD really shouldn't be this hard, that's
what Linux is for :-)

--
                 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

[Simon B. <ba...@Fr...>]

Matthias Andree wrote:
> > (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 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.

Content-Description: fix default --sslcertpath
> Index: socket.c
> ===================================================================
> --- socket.c	(Revision 4499)
> +++ socket.c	(Arbeitskopie)
> @@ -841,6 +841,8 @@
>  	}
>  	if (certpath)
>  		SSL_CTX_load_verify_locations(_ctx, NULL, certpath);
> +	else
> +		SSL_CTX_set_default_verify_paths(_ctx);
>  	
>  	_ssl_context[sock] = SSL_new(_ctx);
>  	

The patch is included in fetchmail-6.3.0_1. Thanks for the quick fix,
Matthias!

-- 
Best regards / Viele Grüße,                             ba...@Fr...
 Simon Barner                                                ba...@gm...

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

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

[fetchmail-users] Re: more clever resource limitations

[Chris B. <li...@pi...>]

fet...@be... wrote:

>Message: 1
>Date: Thu, 8 Dec 2005 22:04:18 -0800
>From: Greg Lindahl <li...@pb...>
>To: fet...@li...
>Subject: [fetchmail-users] more clever resource limitations
>
>[snip]
>
>Due to the advent of spamassassin, I am no longer able to accept lots
>of messages at once via fetchmail -- it causes my laptop to thrash.  I
>use sendmail -> procmail -> spamassassin, so using sendmail's load
>average limit didn't really help the situation, since sendmail has no
>idea it's kicked off a bunch of spamassassin processes that in a few
>seconds will drive the load way up. (In this analysis I'm assuming that
>it's only cpu time and not disk I/O which is causing the problem.)
>  
>
Can you not limit the no. of messages sendmail accepts per connection 
and a queue limit instead? That's what i did with my similar setup but 
with exim as the MTA. Fetchmail copes with this gracefully. I had 
exactly the same problem every time I went on holiday and shutdown my 
local mailserver: with the huge volume of spam, fetchmai, would go and 
get loads of messages from my POP3 box, deliver them to Exim, which 
would then launch lots of spamd processes. The box would work itself 
into a corner until theer was little choice but to 240-reset it! Once I 
set the limits in exim, it's just a question of waiting a while.

[fetchmail-users] Re: more clever resource limitations

[Sunil S. <sh...@bo...>]

Hi Greg,

Quoting from Greg Lindahl's mail on Thu, Dec 08, 2005:
> Due to the advent of spamassassin, I am no longer able to accept lots
> of messages at once via fetchmail -- it causes my laptop to thrash.  I
> use sendmail -> procmail -> spamassassin, so using sendmail's load
> average limit didn't really help the situation, since sendmail has no
> idea it's kicked off a bunch of spamassassin processes that in a few
> seconds will drive the load way up. (In this analysis I'm assuming that
> it's only cpu time and not disk I/O which is causing the problem.)

Are you invoking spamassassin directly from procmail? Or, are you
using spamc+spamd?

1. If you are invoking spamassassin from procmail, please try starting
spamd and then using spamc from procmail.

2. If you are invoking spamc from procmail, what are the options being
passed to spamd? If the spamd option -m has a high value (more than
10), try reducing it to 5.

3. You can also use locking in procmail. If your recipe looks like
this:

=============================================
:0
| spamc
=============================================

Change it to:

=============================================
# Invoke only one spamc at a time
:0 : $HOME/.spamc.lock
| spamc
=============================================

-- 
Sunil Shetye.

Re: [fetchmail-users] more clever resource limitations

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

Greg Lindahl <li...@pb...> writes:

> I was pleased to see on LWN that you guys are working on fetchmail,
> I had no idea it had active maintainers.

Good to see that the word is spreading. :-)

> Due to the advent of spamassassin, I am no longer able to accept lots
>of messages at once via fetchmail -- it causes my laptop to thrash.  I

My personal experience is that SpamAssassin's biggest hog is its Bayes
database, disabling it speeds up SA quite a bit. External filters such
as bogofilter, spamprobe or qsf are much faster than SpamAssassin, and
as you are already using procmail, integration is quite easy.

It takes a bit of manual work training the filter, though. Also, if you
use "spamassassin" in your procmail script, consider running a "spamd"
daemon and then use "spamc" in your script instead, this also gives you
some resource control given proper spamd settings.

You can also use a procmail "local lock file" to make sure only one
spamassassin process is running at a time, and you can also precede the
spamassassin line with "nice". (You'd change your ":0fw" rule to
":0fw:.spamassassin.lock" or similar, depending on how _exactly_ you use
spamassassin.)

>use sendmail -> procmail -> spamassassin, so using sendmail's load
>average limit didn't really help the situation, since sendmail has no
>idea it's kicked off a bunch of spamassassin processes that in a few
>seconds will drive the load way up. (In this analysis I'm assuming that
>it's only cpu time and not disk I/O which is causing the problem.)

The actual problem is that sendmail is somewhat limited in terms of
resource control. With Postfix for instance you'd set the
local_concurrency_limit to some low value and that's it, but as shown
above there are ways around your problem.

>  --fetchlimitsize n (kilobytes, default to 100 kilobytes? 1 meg?)
>  --expungesize n (kilobytes, same default as fetchlimitsize)
>
> In addition, we could use a rate limiter sending messages to sendmail
> to dodge the spamassassin problem. My laptop takes 2 cpu seconds to
> spamassassin a small email message (20 seconds elapsed) and so perhaps
> a time-based measure with an optional addition for the message size
> would do it. If you wanted to be clever you could compute this
> dynamically by watching what happens when you throw a bunch of email
> messages at sendmail, but to start:
>
>  --mtacpu n (seconds, default to 0)
>  --mtacpupermeg n (seconds per megabyte, default to 0)
>
> so fetchmail would wait "mtacpu + size / 1meg * mtacpupermeg" seconds
> before sending another message to the MTA. I'd set this to 2. Hm,
> given that this value is small a floating-point value would be a
> good idea instead of an integer.

As you talked about varying network connection quality, a time limit is
probably one easy way to go and it makes good sense for --expunge* like
options, too -- fetchmail might then checkpoint the mailbox every two
minutes or so (or whichever the user set).

-- 
Matthias Andree

Re: [fetchmail-users] more clever resource limitations

[Jakob H. <jh...@pl...>]

Greg Lindahl wrote:

> use sendmail -> procmail -> spamassassin, so using sendmail's load

Why don't you use fetchmail -> procmail -> spamassassin (mda option)? This
way only one message would be delivered at one time and there's no need to
fix other component's issues in fetchmail.
Speaking of, sendmail surely has some mechanisms to queue messages and
deliver only message per time, which would also fix your problem. Or
configure procmail to use some locking to only start one spamassassin
process.

> I worked around this by adding expunge 1 (which since I'm using POP3
> is similar to using a fetchlimit), which slows things down enough by
> re-logging in repeatedly (wastefully) to avoid the problem. But this
> doesn't work well when I'm on the road and have a bad network
> connection; it slows things down quite a lot, especially when I have a

By "bad" you mean, it breaks often? Then expunge 1 is a good idea, else
you could be downloading messages more than once.

[fetchmail-users] more clever resource limitations

[Greg L. <li...@pb...>]

I was pleased to see on LWN that you guys are working on fetchmail,
I had no idea it had active maintainers.

Due to the advent of spamassassin, I am no longer able to accept lots
of messages at once via fetchmail -- it causes my laptop to thrash.  I
use sendmail -> procmail -> spamassassin, so using sendmail's load
average limit didn't really help the situation, since sendmail has no
idea it's kicked off a bunch of spamassassin processes that in a few
seconds will drive the load way up. (In this analysis I'm assuming that
it's only cpu time and not disk I/O which is causing the problem.)

I worked around this by adding expunge 1 (which since I'm using POP3
is similar to using a fetchlimit), which slows things down enough by
re-logging in repeatedly (wastefully) to avoid the problem. But this
doesn't work well when I'm on the road and have a bad network
connection; it slows things down quite a lot, especially when I have a
big inbox. (I see that I'm not using the new fetchsizelimit and
fastuidl options. But, there are more issues:) Also a large expunge
limit is simply a bad idea for slow connections if there are large
messages; the odds of something going wrong is drastically
increased. And if I move my laptop from the office to a hotel I
currently would have to change the expunge/fetchlimit value by hand.

I think what we really want is something which decides when to expunge
or limit based on the *size* of the messages downloaded. This would
address the current issue that we don't expunge very intelligently;
the point is that you don't want hugely long downloads which might be
interrupted and lose some state, so it makes sense to expunge more
frequently when large messages are being downloaded. One size doesn't
fit all.

 --fetchlimitsize n (kilobytes, default to 100 kilobytes? 1 meg?)
 --expungesize n (kilobytes, same default as fetchlimitsize)

In addition, we could use a rate limiter sending messages to sendmail
to dodge the spamassassin problem. My laptop takes 2 cpu seconds to
spamassassin a small email message (20 seconds elapsed) and so perhaps
a time-based measure with an optional addition for the message size
would do it. If you wanted to be clever you could compute this
dynamically by watching what happens when you throw a bunch of email
messages at sendmail, but to start:

 --mtacpu n (seconds, default to 0)
 --mtacpupermeg n (seconds per megabyte, default to 0)

so fetchmail would wait "mtacpu + size / 1meg * mtacpupermeg" seconds
before sending another message to the MTA. I'd set this to 2. Hm,
given that this value is small a floating-point value would be a
good idea instead of an integer.

Just another fetchmail user,

-- greg

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

[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, 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

[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 issues

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

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

"Harry G. McGavran Jr. " <w5...@wo...> writes:

> I downloaded fetchmail-6.3.0 and things went very nicely
> except for a couple minor issues.  There may be other
> things I find later, but I've been using it today with
> only the following minor problems.
>
> First:
>
> I upgraded from fetchmail-6.2.5.4 with 6.3.0.
>
> When I downloaded fetchmail-6.2.5.4 and did the gpg --verify
> on the signature I got:
>
> gpg: Signature made Sun Nov 13 06:58:22 2005 MST using DSA key ID 052E7D95
> gpg: Good signature from "Matthias Andree <mat...@gm...>"
>
> But, when I downloaded fetchmail-6.3.0 and did the gpg --verify
> on the signature I got:
>
> gpg: Signature made Wed Nov 30 16:41:57 2005 MST using DSA key ID 052E7D95
> gpg: BAD signature from "Matthias Andree <mat...@gm...>"

My apologies. I goofed up the signature(*), and uploaded a new signature
23 hours later. You can erase your fetchmail-6.3.0.tar.bz2.asc file,
re-download it and should then get "Good signature...".

There are the digests of the fetchmail-6.3.0.tar.bz2 tarball:

   MD5 (fetchmail-6.3.0.tar.bz2) = b547b59f352af956911ce812773b3976
  SHA1 (fetchmail-6.3.0.tar.bz2) = 9449e87036802d95fb07ab4d226f67709840b3ee
RMD160 (fetchmail-6.3.0.tar.bz2) = 889a67a5858507d731851857f911e69ed27e86d0
 TIGER (fetchmail-6.3.0.tar.bz2) = 247f1b1bae139fb2e5267356350819a43382e8fb537b1455
SHA256 (fetchmail-6.3.0.tar.bz2) = abe34809e1a6a4eb27c8c91efe763e7c9762d50bfee31d3174703f022982b76e

(*) I'd seen that the signed tarball still stated 6.3.0 had not been
released, changed that to released Nov 30, and forgot to re-sign the new
tarball.

> The man page for fetchmail-6.3.0 has:
>
>        The  --showdots  option  (keyword:  set  showdots)  forces
>        fetchmail to show progress dots even if the current tty is
>        not  stdout  (for example logfiles).  Starting with fetch-
>        mail version 5.3.0, progress dots are only shown on stdout
>        by default.
>
> With showdots set (seems to be the default) the progress dots
> appear on stdout AND on any file the logging is redirected to.

Eek. We'll look into that.

> To me, either the behavior of fetchmail should reflect the man
> page on this or vice-versa.

Right.

> Everything else looks nice!

Thank you for the reports.

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDkYpJvmGDOQUufZURAvHJAJ9B8SEb2OJ1wAY2L1XrsU2WnzUBVgCgtjdb
RTeMP5mSIrHZjEyfM6+e8gU=
=qtM6
-----END PGP SIGNATURE-----

[fetchmail-users] fetchmail-6.3.0 issues

[Harry G. M. J. <w5...@wo...>]

I downloaded fetchmail-6.3.0 and things went very nicely
except for a couple minor issues.  There may be other
things I find later, but I've been using it today with
only the following minor problems.

First:

I upgraded from fetchmail-6.2.5.4 with 6.3.0.

When I downloaded fetchmail-6.2.5.4 and did the gpg --verify
on the signature I got:

gpg: Signature made Sun Nov 13 06:58:22 2005 MST using DSA key ID 052E7D95
gpg: Good signature from "Matthias Andree <mat...@gm...>"

But, when I downloaded fetchmail-6.3.0 and did the gpg --verify
on the signature I got:

gpg: Signature made Wed Nov 30 16:41:57 2005 MST using DSA key ID 052E7D95
gpg: BAD signature from "Matthias Andree <mat...@gm...>"

This was with the tar.bz2 download in each case.

Second:

The man page for fetchmail-6.3.0 has:

       The  --showdots  option  (keyword:  set  showdots)  forces
       fetchmail to show progress dots even if the current tty is
       not  stdout  (for example logfiles).  Starting with fetch-
       mail version 5.3.0, progress dots are only shown on stdout
       by default.

With showdots set (seems to be the default) the progress dots
appear on stdout AND on any file the logging is redirected to.

With showdots NOT set, the progress dots do NOT appear on stdout
and do NOT appear on any file the logging is redirected to.

I infer from the man page that "no showdots" should be set by
default and the when showdots is NOT set, progress dots appear anyway
when logging to stdout and NOT when logging is redirected to
a file.

To me, either the behavior of fetchmail should reflect the man
page on this or vice-versa.

Everything else looks nice!

	Harry
	w5...@ar...

-- 

Harry G. McGavran, Jr.

E-mail: w5...@ar...

[fetchmail-users] Re: [fetchmail]fetchmail 6.2.9-rc10 available (this is it, with minor bug fixes)

[H I L T O N R A L P H S <hi...@th...>]

Matthias Andree wrote:
> Unless show stopping bugs are found, this will be released as fetchmail
> 6.3.0 on November 30. At that date, I will bump the version, copy
> the SVN /trunk to /branches/BRANCH_6-3, tag RELEASE_6-3-0 and release.
> 

I see that 6.3.0 is out but no noise on this list?

Cheers
Hilton

[fetchmail-users] fetchmail 6.2.9-rc10 available (this is it, with minor bug fixes)

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

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

Greetings,

This is it - I have just released fetchmail 6.2.9-rc10, the final
release candidate before 6.3.0, with minor bug fixes.

Unless show stopping bugs are found, this will be released as fetchmail
6.3.0 on November 30. At that date, I will bump the version, copy
the SVN /trunk to /branches/BRANCH_6-3, tag RELEASE_6-3-0 and release.

I don't care for reports about cosmetic bugs unless accompanied by a
fix which is either trivial or otherwise obviously correct.

NOTE: Fetchmail used to have these translations, but unless someone
submits updated translation (.po) files to the Translation Project's
Robot (doesn't matter if for -rc9 or -rc10) and has it relayed to
fetchmail-devel by Wednesday UTC noon, these will be dropped from the
distribution as they lack too many translations and would result in a
horrible English/local language mix:

da      Danish
el      Greek
gl      Galician
pt_BR   Brazilian Portuguese
sk      Slovak
tr      Turkish

My special thanks go to Jakub Bogusz, Pavel Maryanov and Takeshi
Hamasaki for their efforts to get the Polish, Russian and Japanese
translations updated.

For distributors, please upload this to every distribution that you have
where small changes in behavior are allowed, to expose this to wider
testing, and put this through your build farms.

Changes since -rc9 are:
* Fix installation without Python. Sunil Shetye, reported by Peter Church. (MA)
* Update Japanese translation. Fixes Bug#329342, Takeshi Hamasaki. (MA)
* Fix imap.c size safeguard that broke on x86_64 architecture. Matthias Andree
* The FAQ is now available for duplex DIN A4 printing in PDF format.
  Don't bother to ask for a Letter version, I don't care.  Matthias Andree
* Man page: Use \- in the manual page where appropriate so that copy & paste
  works.  I hope we got them all.  Héctor García, Matthias Andree.

The software is available from:
<https://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=8158>
<http://home.pages.de/~mandree/fetchmail/>

Regards,

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDik3avmGDOQUufZURAkcpAKCGUZ9KyG/hMJJtSTkNxq0zg+J3qgCfV76R
pxHVr2GuKSSEXzhTW42BQPs=
=cUee
-----END PGP SIGNATURE-----

Re: [fetchmail-users] feedback on failed delivery

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

Thomas Wolff <to...@to...> writes:

> Also, in either case, the indication of the MDA as the cause is quite 
> hidden in the far end of a line. It should really be ensured to be 
> a separate line.
> In this respect I don't understand your comment:
>
> From: Matthias Andree <mat...@gm...>
>> > Now it's:
>> > > 1 message for deblnss01a/demsn702 at blnss35a.
>> > > reading message deblnss01a/demsn702@blnss35a:1 of 1 (3257 header octets) ... (2542 body octets) ..fetchmail: MDA returned nonzero status 255
>> > >  not flushed
>> > which is fine. Just make it better visible by putting the error notice 
>> > on a new line.
>> 
>> Well - fetchmail is actually behaving as was originally intended. It
>> prints the error message at the earliest possible time, and the "not
>> flushed" is a consequence of the error.
> The message would not be printed significantly less early if you just 
> flush stdout first as there is no noticeable delay and no error situation 
> to be expected by that.

That is exactly what happens: fetchmail builds up the line, prints the
sizes of header and body, flushes the line so that --showdots can work,
and then encounters a problem shipping the fetched message out to the
MDA. This error message triggers the flush of a line without LF, then
the error message. There is no easy way to figure if LF needs to be
printed before the problem message, and this is not the time for
sweeping changes. I looked into the problem, and more than 100 code
lines need to change. That is a full days work for a cosmetic change,
I'm not ready to do that now.

Please file your --mda /bin/false example with a stripped-down set of
output examples (one for each of the two error messages is probably
sufficient, SIGPIPE vs. MDA exit) to the bug tracker at BerliOS.de so we
don't forget about the bug.

-- 
Matthias Andree

Re: [fetchmail-users] feedback on failed delivery

[Thomas W. <to...@to...>]

About the stdout/stderr merging issue with error messages I made some 
experiments as I had been asked to.
Fetchmail was always invoked without additional option (no verbose 
mode), .fetchmailrc defines "mda false".
With some variations in invoking fetchmail, I got all kinds of order 
of appearance of the 4 messages. Below you find some examples.

Please also note my later remarks on the messages themselves.


-------------------------------------------------------
Local invocation seems to produce a stable result:
>> fetchmail
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
>fetchmail: Query status=2 (SOCKET)


With an stdout pipe, it looks quite weird:
>> fetchmail | cat
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets) ...fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
> (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: Query status=2 (SOCKET)


With simple remote fetchmail, I even got 3 different versions:
>> rsh ... fetchmail
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
>fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: Query status=2 (SOCKET)

>> rsh ... fetchmail
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: Query status=2 (SOCKET)
>fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a

>> rsh ... fetchmail
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
>fetchmail: Query status=2 (SOCKET)


With a remote stdout pipe, it looks quite weird again (like with local pipe):
>> rsh ... "fetchmail | cat"
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets) fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
> (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: Query status=2 (SOCKET)

But not always:
>> rsh ... "fetchmail | cat"
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: Query status=2 (SOCKET)
>fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a


Joining stderr with stdout can stabilise the result:
>> rsh ... "fetchmail 2>&1"
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
>fetchmail: Query status=2 (SOCKET)

So we would have the local appearance again.


-------------------------------------------------------
Some comments about the messages themselves:

They are now (6.2.9-rc9) actually the same as with 6.2.9-rc5, when 
I had commented:
> If you look exactly, you find MDA mentioned and can draw your conclusion, 
> but it's not really while "reading" the message or while "fetching" it 
> (at least it's not in the process of fetching, so this is confusing), 
> and it's not a socket error either, I think.

While with 6.2.9-rc8 there was a much different and better message:
> 1 message for deblnss01a/demsn702 at blnss35a.
> reading message deblnss01a/demsn702@blnss35a:1 of 1 (3257 header octets) ... (2542 body octets) ..fetchmail: MDA returned nonzero status 255
>  not flushed

So why does rc9 revert to the confusing previous messages here?

Also, in either case, the indication of the MDA as the cause is quite 
hidden in the far end of a line. It should really be ensured to be 
a separate line.
In this respect I don't understand your comment:

From: Matthias Andree <mat...@gm...>
> > Now it's:
> > > 1 message for deblnss01a/demsn702 at blnss35a.
> > > reading message deblnss01a/demsn702@blnss35a:1 of 1 (3257 header octets) ... (2542 body octets) ..fetchmail: MDA returned nonzero status 255
> > >  not flushed
> > which is fine. Just make it better visible by putting the error notice 
> > on a new line.
> 
> Well - fetchmail is actually behaving as was originally intended. It
> prints the error message at the earliest possible time, and the "not
> flushed" is a consequence of the error.
The message would not be printed significantly less early if you just 
flush stdout first as there is no noticeable delay and no error situation 
to be expected by that. This flushing would do the safety of the error 
message no harm - it would in contrast ensure its logically correct 
placement and its reliable appearance and thus improve the user feedback.


Kind regards,
Thomas Wolff

[fetchmail-users] Re: feedback on failed delivery

[Sunil S. <sh...@bo...>]

Quoting from Matthias Andree's mail on Sat, Nov 19, 2005:
> > Actually, running remotely (rsh ... fetchmail), the output turns into:
> > > fetchmail: MDA returned nonzero status 255
> > > 1 message for deblnss01a/demsn702 at blnss35a.
> > > reading message deblnss01a/demsn702@blnss35a:1 of 1 (3257 header octets) ... (2542 body octets) .. not flushed
> > which indicates that stdout and stderr gets merged in an unsynchronised 
> > way. Probably a flush at some point (flush stdout before any error output) 
> > would fix this.
> 
> Do you perhaps use a different verbosity with rsh than on your local
> computer? I'm asking because verbosity would make a difference on your
> local computer, too. We need to be sure we use absolute identical
> settings for silent vs. verbose on both machines before we can start
> debugging.
> 
> Could you double-check this?

I think, it would be easy to test the issue of buffering by using
redirection. Just run fetchmail twice remotely, once with redirection:

rsh ... fetchmail
rsh ... 'fetchmail 2>&1'

If the output is unchanged, buffering is not the issue. If the output
changes, then stdout is getting buffered.

-- 
Sunil Shetye.

Re: [fetchmail-users] feedback on failed delivery

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

Thomas Wolff schrieb am 2005-11-17:

> Now it's:
> > 1 message for deblnss01a/demsn702 at blnss35a.
> > reading message deblnss01a/demsn702@blnss35a:1 of 1 (3257 header octets) ... (2542 body octets) ..fetchmail: MDA returned nonzero status 255
> >  not flushed
> which is fine. Just make it better visible by putting the error notice 
> on a new line.

Well - fetchmail is actually behaving as was originally intended. It
prints the error message at the earliest possible time, and the "not
flushed" is a consequence of the error.

> Actually, running remotely (rsh ... fetchmail), the output turns into:
> > fetchmail: MDA returned nonzero status 255
> > 1 message for deblnss01a/demsn702 at blnss35a.
> > reading message deblnss01a/demsn702@blnss35a:1 of 1 (3257 header octets) ... (2542 body octets) .. not flushed
> which indicates that stdout and stderr gets merged in an unsynchronised 
> way. Probably a flush at some point (flush stdout before any error output) 
> would fix this.

Do you perhaps use a different verbosity with rsh than on your local
computer? I'm asking because verbosity would make a difference on your
local computer, too. We need to be sure we use absolute identical
settings for silent vs. verbose on both machines before we can start
debugging.

Could you double-check this?

-- 
Matthias Andree

[fetchmail-users] Re: WARNING: Running as root is discouraged.

[Michelle K. <lin...@fr...>]

Am 2005-11-17 11:02:01, schrieb Matthias Andree:
> Thomas Wolff schrieb am 2005-11-11:
> 
> > There is this new warning "WARNING: Running as root is discouraged." 
> > which is somehow disturbing.
> 
> Yes, and that is deliberate.
> 
> Networking clients should never run with root privileges, and fetchmail
> is no exception. Fetchmail does not need root privileges to forward
> mail, the only conceivable scenario where it needs root privileges is
> one where it calls an MDA for a different user.

If fetchmail can not started by the $USER and it run global from a
script for all $USERS with "mda /usr/bin/procmail -d %T" what must
I change that it continue to work

To get a clue:

My fetchmail wraper generates logs like

2005-09-12 12:45:01 : Processing started...
2005-09-12 12:45:02 :  amina.herdam         default         (2: Socket)
2005-09-12 12:45:13 :  athina.russel        default         (1: No mail)
2005-09-12 12:45:14 :  ccenter              default         (1: No mail)
2005-09-12 12:45:18 :  dgse                 default         (1: No mail)
2005-09-12 12:45:20 :  diana.seitz          default         (1: No mail)
2005-09-12 12:45:21 :  dst                  default         (1: No mail)
2005-09-12 12:45:23 :  farahnaz.pahlavi     default         (1: No mail)
2005-09-12 12:45:24 :  fayah.dogan          default         (1: No mail)
2005-09-12 12:45:28 :  karima.kalaaji       default         (1: No mail)
2005-09-12 12:45:30 :  lydia.ackermann      default         (1: No mail)
2005-09-12 12:45:31 :  mehdi.serhane        default         (1: No mail)
2005-09-12 12:45:32 :  michelle.konzack     0_private       (1: No mail)
2005-09-12 12:45:46 :  michelle.konzack     1_tdnet         (0: Success)
2005-09-12 12:46:11 :  michelle.konzack     3_arabeyes      (1: No mail)
2005-09-12 12:46:12 :  michelle.konzack     4_bts           (1: No mail)
2005-09-12 12:46:15 :  michelle.konzack     5_postgresql    (1: No mail)
2005-09-12 12:46:16 :  michelle.konzack     6_php           (0: Success)
2005-09-12 12:46:24 :  michelle.konzack     7_linux         (0: Success)
2005-09-12 12:46:50 :  michelle.konzack     8_mail          (1: No mail)
2005-09-12 12:46:50 :  michelle.konzack     9_debian        (0: Success)
2005-09-12 12:54:34 :  michelle.konzack     A_misc          (11: DNS)
2005-09-12 12:55:30 :  michelle.konzack     B_wanadoo       (2: Socket)
2005-09-12 12:59:15 :  michelle.konzack     C_lugs          (11: DNS)
2005-09-12 13:00:11 :  michelle.konzack     D_sun           (11: DNS)
2005-09-12 13:01:07 :  michelle.konzack     F_tdautobuilder (2: Socket)
2005-09-12 13:02:59 :  mis                  default         (2: Socket)
2005-09-12 13:04:52 :  mos                  default         (11: DNS)
2005-09-12 13:05:48 :  noor.nurani          default         (11: DNS)
2005-09-12 13:06:45 :  omegasector          default         (11: DNS)
2005-09-12 13:07:43 :  pmc                  default         (11: DNS)
2005-09-12 13:08:39 :  sandrine.dario       default         (11: DNS)
2005-09-12 13:09:35 :  tamay.dogan          default         (2: Socket)
2005-09-12 13:13:20 :  zelie.domeracki      default         (11: DNS)
------------------------------------------------------------------------
Availlable diskspace:
Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/hdj1                72287     45802     25751  65% /home-mail
========================================================================

Each $USER can have one or more fetchmailconfigs and now ?
There is only ssmtp on the system availlable which does not
support local delivery.

> > I thought fetchmail is also intended as a system installation 
> > for multi-user mail retrieval so it's actually a designed mode to 
> > run fetchmail as root (and the message seems to be unconditional, 

Right

> Refused. Please fix the way you work. This is not Windows, and sudo(1)
> works well for the few moments when you need more power than the regular
> user.  <http://www.courtesan.com/sudo/>

It can not fixed, if you need to fetch messages from cron
for all the $USER of a system.

> fetchmail is a tool for the end user who is usually untrained about
> systems administrations, putting up obstacles and annoyances while he
> works as root is the right thing to do.

But if the $ENDUSER can not run fetchmail because she/he
has no access and it is the system which get the messages ?

My system has only courier-imap-ssl, procmail and fetchmail
installed.

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/3/88452356    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: [fetchmail-users] Re: fetchmail-6.2.6 please test

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

mbox mbarsalou <ba...@at...> writes:

> If there was an rpm for this...I'd willingly test it.

For testing, it's usually easier to just compile it and run from the
compile directory. Instructions on building fetchmail are in the INSTALL
file that ships with fetchmail.

-- 
Matthias Andree