fetchmail-users — User questions and discussion

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

[fetchmail-users] fetchmail 6.2.5.4 released (security bugfix) (legacy)

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

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

Greetings,

I am announcing the release of fetchmail 6.2.5.4. For the main part, the
updated fetchmailconf that fixed CVE-2005-3088 (the password exposure
problem) is now part of the tarball, many build problems with 6.2.5 and
6.2.5.2 were fixed and the infamous "timeout" bug with IMAP that only
showed with several servers (for instance, older CommuniGate; Debian
Bug#314509) was also fixed. CVE-2005-2335 was already fixed in 6.2.5.2,
the fix is also part of 6.2.5.4. See below for details.

The software is available from:
<https://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=7976>

fetchmail-6.2.5.X is a security fix branch that forked off
fetchmail-6.2.5. It does not change for anything but security and the
most severe bug fixes. Note that no 6.2.5.X security audits are planned
except when a particular bug is reported, and that 6.2.5.X is unsafe to
use on some systems, particularly those that lack a *working and secure*
snprintf implementation.

This 6.2.5.X branch is ONLY intended for packages for systems that
cannot move forward to a newer version for stability policies, such as
Debian stable.  Note that this branch may be discontinued alongside the
official 6.3.0 release without further notice.

End users and all other systems should therefore use a current
fetchmail-6.2.9-rc* release candidate or, if available at that time,
6.3.X or newer release.

These are the relevant changes since (and excluding) 6.2.5.2:

* SECURITY FIX CVE-2005-3088: fetchmailconf: fix password exposure: use
  umask 077 before opening output file and restore umask later.
* Critical fix: fix IMAP timeouts, counting message count down on
  servers that do not send EXISTS counts after EXPUNGE. Debian Bug#314509.
* On FreeBSD, add /usr/local/include to CPPFLAGS so that libintl.h is found.
* Avoid automatically picking up HESIOD implementations that lack
  hesiod_getmailhost, such as the one in FreeBSD's base system.
* Fix makedepend for separated build (where the build is not run from
  the source directory), but prevent packaging from separated build, it
  yields bogus results.
* Fix resolv.h autodetection.
* Add +HESIOD to version printout if appropriate.
* Ship pre-built rcfile_l.c for systems that don't have flex.
* Also ship pre-built rcfile_y.[ch] for systems that don't have flex,
  yacc or bison.
* Build environment: Update included gettext. Fix
  --with-included-gettext. Fix parallel build (make -j). Fix "always
  rebuild fetchmail" syndrome.
* Do not link against -ll or -lfl (not needed).

Regards,

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

iD8DBQFDfTM3vmGDOQUufZURAtu2AKCyPEETBn+q1vTQBMF3eHCR0UlEhQCdE7Os
i1DBvMPM0ry0ufynC+0QjKE=
=fUW6
-----END PGP SIGNATURE-----

[fetchmail-users] fetchmail 6.2.9-rc8 available (bug fixes)

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

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

Greetings,

I have just released fetchmail 6.2.9-rc9, the hopefully last release
candidate before 6.3.0, with minor bug fixes.

For distributors, please upload this to every unstable/testing/current
distribution that you have (do not upload to "stable", it changes
behavior in a few places) to expose this to wider testing.

Changes since -rc8 are:
* The default for --smtphost is now always "localhost" regardless of
  authentication types and protocols, so as to simplify configurations for
  workstations where the SMTP daemon only listens on the loopback interface.
  Sunil Shetye & Matthias Andree
* Man page: update --smtphost documentation. Sunil Shetye, Matthias Andree.
* Man page: update --smtpaddress documentation. Sunil Shetye.
* Fix several memory leaks and bugs in the SMTP/LMTP retry logic where
  fetchmail confused UNIX and Internet domain sockets. Sunil Shetye.
* Man page (BUGS): document that passwords are length limited. Matthias Andree
* Man page: Document that quoted strings that run across line boundaries
  contain the control characters (CR or LF). Document explicitly the backslash
  escape sequences and their differences from the escape sequences used in the
  C programming language.  Matthias Andree
* Fix segfault when run control file ends with a backslash inside an
  unterminated quoted string. Matthias Andree.
* In quoted strings, support backslash as last character on a line to join the
  following line to the current. Matthias Andree.
* Parsing untagged IMAP responses is more robust now. Matthias Andree.
* Man page: Remove some procmail praises in --mda documentation, suggest
  maildrop instead, warn of procmail fallthrough behavior. Matthias Andree.
* Man page: Revise AUTHORS and SEE ALSO sections. Matthias Andree.
* Updated translations: Albanian [sq] (Besnik Bleta), Catalan [ca] (Ernest
  Adrogué Calveras), Czech [cs] (Miloslav Trmac), German [de] (MA),
  Spanish (Castilian) [es] (Javier Kohen), French [fr] (MA),
  Polish [pl] (Jakub Bogusz), Russian [ru] (Pavel Maryanov).
* In oversized warning messages, print the account name, too. Fixes Debian
  Bug#213299. Sunil Shetye (MA).
* Fix '!: command not found' in configure script on nonconformant shells
  such as Solaris' /bin/sh.
* The IMAP trail-eating fix in -rc8 was broken and fixed by Sunil
  Shetye.

I seek everyone to test it out, report remaining bugs, update outdated
translations (send your translated .po files to the translation
project's robot, it'll forward your translation to the -devel list) or
send patches for documentation or report inconsistencies (including
formatting!) in the documentation.

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

Regards,

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

iD8DBQFDfTEivmGDOQUufZURAhvXAKD6MF7T8MhWvpjlJ/11PsRjaVjmRgCgnry2
oGSAFM4uTU3QdG6IZB1FgcA=
=82bb
-----END PGP SIGNATURE-----

[fetchmail-users] Re: [PATCH] Re: oversized messages notification provides server info but lacks user info

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

Sunil Shetye schrieb am 2005-11-17:

> Quoting from Matthias Andree's mail on Thu, Nov 17, 2005:

> > Unless someone posts a patch do this, suitably to apply against the SVN
> > repository at <https://decoy.wox.org/svn/fetchmail/trunk/>, this is not
> > going to make fetchmail 6.3.0.
> 
> ===================================================================================
> Index: fetchmail/driver.c
> ===================================================================
> --- fetchmail/driver.c	(revision 4449)
> +++ fetchmail/driver.c	(working copy)

Wow, that was fast. Thanks a lot, committed for 6.2.9-rc9.

-- 
Matthias Andree

[fetchmail-users] [PATCH] Re: oversized messages notification provides server info but lacks user info

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

Quoting from Matthias Andree's mail on Thu, Nov 17, 2005:
> Gregor Zattler <te...@un...> writes:
> 
> > [please Cc: me, i'm not subscribed to this list]
> >
> > Hi,
> >
> > this is a feature wish i posted as a debian bug report but
> > nothing happend.  Now I read (http://lwn.net/Articles/89403/)
> > there are plans to revive the development of fetchmail and so I
> > post this here...
> 
> Unless someone posts a patch do this, suitably to apply against the SVN
> repository at <https://decoy.wox.org/svn/fetchmail/trunk/>, this is not
> going to make fetchmail 6.3.0.

===================================================================================
Index: fetchmail/driver.c
===================================================================
--- fetchmail/driver.c	(revision 4449)
+++ fetchmail/driver.c	(working copy)
@@ -338,12 +338,12 @@
     stuff_warning(NULL, ctl, "%s", "");
     if (ctl->limitflush)
 	stuff_warning(NULL, ctl,
-		GT_("The following oversized messages were deleted on the mail server %s:"),
-		ctl->server.pollname);
+		GT_("The following oversized messages were deleted on server %s account %s:"),
+		ctl->server.pollname, ctl->remotename);
     else
 	stuff_warning(NULL, ctl,
-		GT_("The following oversized messages remain on the mail server %s:"),
-		ctl->server.pollname);
+		GT_("The following oversized messages remain on server %s account %s:"),
+		ctl->server.pollname, ctl->remotename);
 
     stuff_warning(NULL, ctl, "%s", "");
 
===================================================================================

-- 
Sunil Shetye.

[fetchmail-users] Re: unsafe MDA procmail recommended by fetchmail

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

Hello Sunil,

Am 2005-11-14 18:23:58, schrieb Sunil Shetye:

> procmail has a way of returning with an error. You may append the
> lines below to your procmailrc for error handling.
> 
> ==========================================================================
> 
> # if procmail has reached here, delivery has failed. return with a
> # temporary failure code from <sysexits.h>.
> # 75 = EX_TEMPFAIL
> EXITCODE=75
> :0
> /dev/null
> ==========================================================================

This is, what I was searching for.

> WARNING: the above recipe works only when the program invoking
> procmail handles the exit code gracefully. Otherwise, all your mails
> will be trashed.
> 
> fetchmail will not delete these mails. Even, most SMTP servers should

I use only fetchmail + courier-mta while the MTA receives
regulary messages and fetchmail collect (at $USER request)
messages from other ISP's

> queue up such mails for a few days before bouncing them back. But, if
> you have other programs invoking procmail, you will need to check if
> they handle such exit codes gracefully.

So I think, courier-mta will work to.

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] [texmex@uni.de: fetchmail: oversized messages notification provides server info but lacks user info]

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

Gregor Zattler <te...@un...> writes:

> [please Cc: me, i'm not subscribed to this list]
>
> Hi,
>
> this is a feature wish i posted as a debian bug report but
> nothing happend.  Now I read (http://lwn.net/Articles/89403/)
> there are plans to revive the development of fetchmail and so I
> post this here...

Unless someone posts a patch do this, suitably to apply against the SVN
repository at <https://decoy.wox.org/svn/fetchmail/trunk/>, this is not
going to make fetchmail 6.3.0.

-- 
Matthias Andree

Re: [fetchmail-users] feedback on failed delivery

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

I wrote:
> > 1 message for deblnss01a/demsn702 at blnss35a.
> > reading message deblnss01a/demsn702@blnss35a:1 of 1 (902 header octets)  (6 body octets) Segmentation Fault
> Crash.

Matthias Andree wrote:
> Can you redo the situation and obtain a backtrace for me, ...
Unfortunately, the crash is not reproducible anymore today, sorry.

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.

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.

Thanks and best regards,
Thomas Wolff

Re: [fetchmail-users] feedback on failed delivery

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

Thomas Wolff schrieb am 2005-11-16:

> > 1 message for deblnss01a/demsn702 at blnss35a.
> > reading message deblnss01a/demsn702@blnss35a:1 of 1 (902 header octets)  (6 body octets) Segmentation Fault
> Crash.

Can you redo the situation and obtain a backtrace for me, from your core
file? See <http://leafnode.sourceforge.net/doc_en/FAQ.html#backtrace>
for instructions. The document is for leafnode, but the procedure is the
same for fetchmail.

NOTE: If you had installed fetchmail with "make install-strip", please
reinstall with "make install" (do not strip), and you may need to enable
core dumps. In bash, use ulimit (see help ulimit) to let the system
allow core files, and you need to run fetchmail with "-v -d0" so
fetchmail itself does not disable core files again.

You can also run fetchmail from gdb, i. e.

(in the shell)
gdb fetchmail
(inside gdb)
run -v -N -d0 --nosyslog

(you can pass more options to run, but do leave -v -N and -d0 in).

Thank you.

-- 
Matthias Andree

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

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

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.

In this scenario, fetchmail should use IPC (Unix domain socket, named
pipe or similar) to talk from one unprivileged process to another.  This
won't happen in the near future though, unless someone else finds the
time to do that.

> 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, 
> looking at the code).

That was how it originally worked, but the fetchmail 6.2.5 code Rob,
Graham and I took over was utterly unsuitable to run as root, as you can
read in <http://fetchmail.berlios.de/fetchmail-SA-2005-01.txt>
(CVE-2005-2335).

The 6.2.5 code was so bold as to fall back to sprintf on systems where
snprintf was unavailable, which opened up even more buffer overrun
possibilities. 6.3.0 uses trio_snprintf instead on such systems.

There is a reason why I recommend 6.2.9-rc* to everyone, and that is
many more bugfixes.

> Also I don't need this message when I retrieve my personal mailbox while 
> regularly working as root on my home machine; this may not be 

I don't care if you work as root on your home machine and fetchmail
pesters you with this warning.

On some day in the future, fetchmail might have a model where it can
give up privileges for good in the process that talk to the network and
only retain privileges for MDA based setups where someone needs to run
the MDA of somebody else's. This model will certainly not be the
seteuid() swapping crap as that's not secure. Look at sendmail to learn
some lessons about this.

> recommended in general but it's not fetchmail to tell me that every 
> time I retrieve my mail.

Evidently, it is. Sorry for my being so boldfaced.

> Please remove the message.

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

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.

-- 
Matthias Andree

Re: [fetchmail-users] Re: unsafe MDA procmail recommended by fetchmail

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

Thomas Wolff schrieb am 2005-11-10:

> >        ORGMAIL     Usually  the  system  mailbox  (ORiGinal MAILbox).  If, for
> >                    some obscure reason (like `filesystem full') the mail could
> >                    not  be  delivered,  then  this  mailbox  will  be the last
> >                    resort.  If procmail fails to save the mail in here  (deep,
> >                    deep  trouble  :-),  then  the mail will bounce back to the
> >                    sender.
> What would "bounce back" actually mean in an environment with no working 
> or properly configured sendmail interface?

Do not worry, fetchmail will not delete the message if you use a
reliable retrieval protocol such as POP3 + UIDL and retry on the next
run.

> Actually, I think there is also an option missing to prevent procmail 
> from attempts to bounce a mail after failed delivery. As I indicated 
> above, not all system configuration provide working outgoing mail 
> (at least not through the standard interfaces). I, for instance, use 
> ssmtp with a script wrapper; /usr/sbin/sendmail is not working here.
> In this case (not bouncing failed mail), procmail should of course 
> return an error code so e.g. fetchmail notices and doesn't delete 
> the mail from the server.

In that particular case, ! redirections will not work either (unless you
override SENDMAIL).

-- 
Matthias Andree

Re: [fetchmail-users] Re: unsafe MDA procmail recommended by fetchmail

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

It is a well-known fact that procmail is too demanding to configure
properly for the average user, and the documentation is insufficient in
this respect.

What have the procmail maintainers done in the past four years to remedy
this? Nothing. No documentation, no code changes, no new release.

With my system administrator hat on, I have taken procmail away from
my users and given them maildrop instead, years ago, and I think
fetchmail 6.3.0 should go this route, as suggested by Thomas Wolff.

To use procmail safely, you have to add something after every delivering
recipe, that either you or Philip posted to the postfix-users list ages
ago when I complained:

:0e
{
  EXITCODE=75
  HOST
}

This is cumbersome, unintuitive, in none of the prominent tutorials, and
ugly as sin. The ugliness at that time caused embarrassed silence...

To the user: use maildrop, it does The Right Thing[TM] out of the box,
namely exiting with EX_TEMPFAIL as per /usr/include/sysexits.h

What's worse, procmail shows many incomplete examples that confuse the
user.

This procmail fallthrough behavior that makes the many popular and
shipped (see procmailex!) examples so unusable that users have to start
chasing their mail in bad weather is what makes me support Thomas's
original suggestion in spite of the problem being his own fault.

The problem gets worse when multiple rules may match a message. In that
case, the order of matches makes a difference, and mail may end up in
the wrong box, when, for instance by a POP3 or IMAP server shuffling its
mailbox around, /var/mail is TEMPORARILY out of space - the first rule
matches, attempt FOR DELIVERY fails, the mail server lets go of the
temporary file of the other user, meanwhile procmail falls through, the
second rule matches and delivery succeeds -> boom, the mail is in the
wrong destination.

Just unsetting DEFAULT/ORGMAIL as you suggest below is not sufficient to
fix this. It's also a long shot from being anywhere close to a solution.

> > User feedback and documentation should be improved,
> 
> Please provide suggestions as to what wording in the logfile would have made
> it more clear?

The logfile should be enabled by default, and right in the face of the
user: $HOME/procmail.log

> Same question for the manpage; in what way should we rephrase it?

The code must change, not the manual page. In order not to break
existing setups, you should make new "EX_TEMPFAIL right away" behavior a
compile-time switch that defaults to off, or you should make it a
feature that is so prominently documented it warrants a version bump to
procmail 4.

> > though, and maybe
> > this case of redirection should not be applied at all
> 
> Mail wants to arrive.  That means, if we can salvage the mail, instead of
> bouncing it, then that is the preferred solution.  Rescueing instead of
> giving up is the proper action.  It basically guards the user from his
> own lack of knowledge on the situation (and since the user can't
> be asked at that point, procmail has to make an intelligent decision).

procmail's undeterministic behavior is worse than a bounce.

A message that is delivered to the wrong place is a message lost for the
user, and at best one that causes additional work. Why use a filter at
all if it doesn't work?  procmail's "intelligence" is a disservice to
users. We've been through this before, and you fail to see the point.

Imagine someone filtering his important messages (from VIP, with special
subject) to a particular "important" mailbox, to see the mail early, and
only checks his default mailbox once in a while. He'll "lose" that
important mail and only find it later. Is *that* smart? No, it isn't.

maildrop takes care to exit with EX_TEMPFAIL unless there is a really
clear permanent problem (such as user not found in virtual setups). That
makes the message stay in the queue, and fetchmail will thus leave it on
the server and retry later, and that is what users expect.

> > (or be configurable)
> 
> It is, just put the following lines anywhere in your .procmailrc file:
>   DEFAULT
>   ORGMAIL
> 
> Which will unset the DEFAULT and ORGMAIL variables (and prevent
> evasive action in case of system or user error).

As shown above, this does not work for any setups except perhaps (full
example) this trivial one:

DEFAULT
ORGMAIL

:0:
everything

-- 
Matthias Andree

[fetchmail-users] feedback on failed delivery

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

Hello,
I'm bothering you again with the issue of error behaviour, this time 
it is indeed about fetchmail.
As I'm still trying to achieve a reliable overall mail configuration, 
I just tried the following in .fetchmailrc:
mda "false"

As expected, fetchmail leaves the mail on the server but user feedback 
is not good, and there is even a crash:

With fetchmail release 6.2.9-rc5+SSL:

> 1 message for deblnss01a/demsn702 at blnss35a.
> reading message deblnss01a/demsn702@blnss35a:1 of 1 (902 header octets)  (6 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
> fetchmail: socket error while fetching from blnss35a
> fetchmail: Query status=2 (SOCKET)
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.

With fetchmail release 6.2.9-rc8+SSL

> 1 message for deblnss01a/demsn702 at blnss35a.
> reading message deblnss01a/demsn702@blnss35a:1 of 1 (902 header octets)  (6 body octets) Segmentation Fault
Crash.


Kind regards,
Thomas Wolff