fetchmail-users — User questions and discussion

[fetchmail-users] Re: [fetchmail-users] fetchmail doesn´t fetching

[Alex M. <al3...@gm...>]

smtp works ok. I´m using qmail some time ago and now, after installing mutt
i can send mails without problems... The problem appears trying to read the
incoming mails by pop3... fetchmail is not writing my mails on ~/Mail or any
other known directory...

On 1/26/06, Matthias Andree <mat...@gm...> wrote:
>
> Alex Moreno <al3...@gm...> writes:
>
> > and it seems that works, it connects and i can see on the shell some
> > messages... until i try to read with mutt. fetchmail is not writing the
> mails
> > or at least i don´t know where is it writing them.
>
> ...
>
> >   Messages will be SMTP-forwarded to: localhost (default)
>
> Check the log of your SMTP listener (Exim or whatever you're using),
> /var/log/maillog and /var/log/mail are common places, I don't know what
> Debian uses though (read /etc/syslog.conf to find out). This seems to be
> a problem outside fetchmail from your description.
>
> --
> Matthias Andree
>

Re: [fetchmail-users] fetchmail doesn´t fetching

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

Alex Moreno <al3...@gm...> writes:

> and it seems that works, it connects and i can see on the shell some
> messages... until i try to read with mutt. fetchmail is not writing the mails
> or at least i don´t know where is it writing them.

...

>   Messages will be SMTP-forwarded to: localhost (default)

Check the log of your SMTP listener (Exim or whatever you're using),
/var/log/maillog and /var/log/mail are common places, I don't know what
Debian uses though (read /etc/syslog.conf to find out). This seems to be
a problem outside fetchmail from your description.

-- 
Matthias Andree

[fetchmail-users] Re: [fetchmail-users] fetchmail doesn´t fetching

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

On 25/01/06, Alex Moreno <al3...@gm...> wrote:
> Hi all,
>
> First of all, excuse me if i ask some repetitive question. I´ve been loking
> on internet for the solution or a similar problem with no luck. I´m trying
> to use fetchmail with a pop account. I´ve tried this conf:
>
>
> alex@trantor:~$ cat .fetchmailrc
> #set syslog
>
> poll localhost with proto POP3
> user ale...@mo... there to alex here
>
> alex@trantor:~$
>
>
> and it seems that works, it connects and i can see on the shell some
> messages... until i try to read with mutt. fetchmail is not writing the
> mails or at least i don´t know where is it writing them.
>
> I´m running debian stable and fetchmail 6.2.5.4-1. I attach you some more
> information of fetchmail -V

No, it's not the output of "-V" we need, it's the output of "-v -v -v"
(lower case).

--
                 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 doesn´t fetching

[Alex M. <al3...@gm...>]

Hi all,

First of all, excuse me if i ask some repetitive question. I´ve been loking
on internet for the solution or a similar problem with no luck. I´m trying
to use fetchmail with a pop account. I´ve tried this conf:


alex@trantor:~$ cat .fetchmailrc
#set syslog

poll localhost with proto POP3
user ale...@mo... there to alex here

alex@trantor:~$


and it seems that works, it connects and i can see on the shell some
messages... until i try to read with mutt. fetchmail is not writing the
mails or at least i don´t know where is it writing them.

I´m running debian stable and fetchmail 6.2.5.4-1. I attach you some more
information of fetchmail -V


------------------------------------------------

alex@trantor:~$ fetchmail -V
This is fetchmail release 6.2.5.4+NTLM+SDPS+SSL+NLS
Fallback MDA: (none)
Linux trantor 2.4.27-2-386 #1 Mon May 16 16:47:51 JST 2005 i686 GNU/Linux
Taking options from command line and /home/alex/.fetchmailrc
Idfile is /home/alex/.fetchids
Fetchmail will show progress dots even in logfiles.
Fetchmail will forward misaddressed multidrop messages to alex.
Options for retrieving from ale...@mo...@localhost:
  True name of server is localhost.
  Password will be prompted for.
  Protocol is POP3.
  All available authentication methods will be tried.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  Only new messages will be retrieved (--all off).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  Fetch message size limit is 100 (--fetchsizelimit 100).
  Do binary search of UIDs during 9 out of 10 polls (--fastuidl 10).
  Messages will be SMTP-forwarded to: localhost (default)
  Single-drop mode: 1 local name(s) recognized.
  No UIDs saved from this host.
alex@trantor:~$

------------------------------------------------


Any help or link would be appreciated.

Thanks a lot

[fetchmail-users] fetchmail security announcement 2006-01 (CVE-2006-0321)

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

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

fetchmail-SA-2006-01: crash when bouncing messages.

Topics:		#1 crash when bouncing a message
		#2 fetchmail 6.2.5.X end of life

Author:		Matthias Andree
Version:	1.0
Announced:	2006-01-22
Type:		free() with bogus pointer
Impact:		fetchmail crashes
Danger:		low
Credits:	Nathaniel W. Turner (bug report)
CVE Name:	CVE-2006-0321
URL:		http://fetchmail.berlios.de/fetchmail-SA-2006-01.txt
		http://bugs.debian.org/348747
Project URL:	http://fetchmail.berlios.de/

Affects:	fetchmail release >= 6.3.0
		fetchmail release <  6.3.2
		fetchmail release candidates 6.3.2-rc1, -rc2 and -rc3

Not affected:	fetchmail release candidate 6.3.2-rc4
		other versions not mentioned here or in the previous
		sections have not been checked

Corrected:	2006-01-19 fetchmail 6.3.2-rc4
		2006-01-22 fetchmail 6.3.2


0. Release history
==================

2006-01-19	internal review draft
2006-01-20	add CVE ID
2006-01-22	release 1.0


1. Background
=============

fetchmail is a software package to retrieve mail from remote POP2, POP3,
IMAP, ETRN or ODMR servers and forward it to local SMTP, LMTP servers or
message delivery agents.

fetchmail ships with a graphical, Python/Tkinter based configuration
utility named "fetchmailconf" to help the user create configuration (run
control) files for fetchmail.


2. Problem description and Impact
=================================

Fetchmail contains a bug that causes itself to crash when bouncing a
message to the originator or to the local postmaster. The crash happens
after the bounce message has been sent, when fetchmail tries to free the
dynamic array of failed addresses, and calls the free() function with an
invalid pointer.  This bug was introduced short before fetchmail 6.3.0
and is not present in the now discontinued 6.2.X series (see below).


3. Workaround
=============

None known at this time.


4. Solution
===========

Download and install fetchmail 6.3.2 or a newer stable release from
fetchmail's project site at
<http://developer.berlios.de/project/showfiles.php?group_id=1824>.


5. End of life announcement
===========================

The aged fetchmail 6.2.5.X branch is discontinued effective immediately.
No further releases from the 6.2.5.X branch will be made.

The new 6.3.X stable branch has been available since 2005-11-30
and will not change except for bugfixes, documentation and message
translations.


A. Copyright, License and Warranty
==================================

(C) Copyright 2006 by Matthias Andree, <mat...@gm...>.
Some rights reserved.

This work is licensed under the Creative Commons
Attribution-NonCommercial-NoDerivs German License. To view a copy of
this license, visit http://creativecommons.org/licenses/by-nc-nd/2.0/de/
or send a letter to Creative Commons; 559 Nathan Abbott Way;
Stanford, California 94305; USA.

THIS WORK IS PROVIDED FREE OF CHARGE AND WITHOUT ANY WARRANTIES.
Use the information herein at your own risk.

END OF fetchmail-SA-2006-01.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFD04VrvmGDOQUufZURAuktAKD62llCNM2NlccXzI8NOqU9/sD1hgCeLfw0
fu8vMb8DiolqOUdQU6vVAP0=
=tfMu
-----END PGP SIGNATURE-----

[fetchmail-users] fetchmail 6.3.2 stable release with security relevant bugfixes

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

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

Greetings,

I am announcing the release of fetchmail 6.3.2.

This release fixes a denial of service bug/fetchmail crash after sending
a bounce, adds a Maillennium (Comcast) workaround and fixes other bugs.
(The security announcement will be mailed separately.)

This is a recommended upgrade for all users of any previous fetchmail versions.

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

These are the relevant changes in 6.3.2 since 6.3.1,
unless otherwise noted, changes to this release were made by Matthias Andree.

# SECURITY FIX IN THIS RELEASE
* CVE-2006-0321: Fix segfault or bus error after bouncing a message.  This bug
  was introduced into 6.3.0 when removing alloca(); it caused fetchmail to free
  random memory.  Reported by Nathaniel W. Turner, Debian Bug#348747.
  See fetchmail-SA-2006-01.txt

# DEPRECATED FEATURES AND MAJOR INCOMPATIBLE CHANGE ADVANCE WARNINGS
* The --enable-fallback (fall back to MDA if MTA unavailable) may be removed
  from a future fetchmail release.

# INCOMPATIBLE CHANGES
* Automatically disable the POP3 TOP command if the greeting string contains
  "Maillennium POP3/PROXY server", which is used by comcast and known to
  truncate messages after 80 kByte. Fall back to RETR, and complain if we had
  used TOP otherwise (the warning is printed only once per server in daemon
  mode).  Suggested by Ed Wilts.
  *Note* that this means messages are marked read on these servers, which is a
  deviation from how 6.3.1 behaved, but we have no alternative, comcast haven't
  fixed this bug in years.  Preventing the loss of the remainder of the message
  justifies this incompatible fix.
* fetchmail, since 6.3.0, requires write permission to the directory holding the
  idfile. See the amendment in the 6.3.0 MAJOR INCOMPATIBLE CHANGES section
  below for details. The manual page was updated.

# CHANGES RELEVANT TO PACKAGERS
* The outdated BUGS document was removed from the distribution.
* Added fetchmail-SA-2006-01.txt to the distribution.

# BUG FIXES
* SMTP/LMTP cleanup to fix these two bugs:
  - switch back to SMTP after having tried LMTP hosts (multiple smtphost hosts)
  - switch back to LMTP after sending a bounce.
  The patch removes the global state variable that was the root of this problem.
  Patch by Sunil Shetye. (MA)
* Don't complain about fetchall keep in --configdump mode. Bug introduced in
  6.3.0.
* fetchmailconf.py: Fix novice help for Poll interval and fetchall.
  Reported by Justin Pryzby, Debian Bug #344978.
* Some verbose output disappeared in debug mode. Adding further -v options would
  alternate between verbose and debug mode. debug mode now comprises all verbose
  output, and adding more -v options does not switch back from debug to verbose
  mode.
* fetchmail.man: Fix accented characters in Héctor García's name. Merged from
  downstream debian/patches/01_man_page.dpatch.
* Add missing --help text for "--sslcertck" option.
* fetchmailconf.py: Accept --help and --version.
* fetchmail --version  now prints the copyright notice.
* don't complain about READ-ONLY IMAP folders in --fetchall --keep mode.
  Reported Alexander Zangerl, Debian Bug#348964.
* the RPM .spec file now generates a -debuginfo package on newer RPM versions.

Regards,

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

iD8DBQFD04UzvmGDOQUufZURApk+AJ46zXfGAd0jHsbxziZ7JQpPugjJKwCeM2xW
DSAxh7uWlnM7Teolv4wF+BE=
=hrZ0
-----END PGP SIGNATURE-----

Re: [fetchmail-users] Exit Codes, a script and daemon

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

fink <fi...@ra...> writes:

> I would like Fetchmail to check my mailserver periodically for new mail.
>
> I created a small script which just needs one argument (the exit code
> from fetchmail):
>
> if [ $1  = 1]
> then
>   echo 1 > /proc/acpi/asus/mled
> else
>   echo 0 > /proc/acpi/asus/mled
> fi
> exit
>
> The trouble is now how to get the exit code passed to the script: When
> fetchmail is running deamonised it never returns and thus the exit
> code does not exist.

Well, it would trash its value on the next run anyhow, besides that I
think you got the logic in reverse. Exit code 0 = messages
fetched/waiting, Exit code 1 = no mail.

I'd suggest to use a cron job for such a setup and not daemon mode, that
way you can perhaps set a flag file and LED if fetchmail exits 0, ignore
fetchmail exiting 1, and reset the flag file when your mailer has been
started or quit.

-- 
Matthias Andree

[fetchmail-users] Exit Codes, a script and daemon

[fink <fi...@ra...>]

Hi,

I would like Fetchmail to check my mailserver periodically for new mail.

I created a small script which just needs one argument (the exit code
from fetchmail):

if [ $1  = 1]
then
  echo 1 > /proc/acpi/asus/mled
else
  echo 0 > /proc/acpi/asus/mled
fi
exit

The trouble is now how to get the exit code passed to the script:
When fetchmail is running deamonised it never returns and thus the exit
code does not exist.

Is it possible in some odd way to pass the result of the fechmail mail
check to the program called by the "postconnect" command ?

The idea I had was something like this:

[poll SERVERNAME with proto IMAP user 'USER' password 'PASSWD'
postconnect '/usr/bin/servicemled $?']

Cheers
RaceMouse

[fetchmail-users] Exit Codes, a script and daemon

[fink <fi...@ra...>]

Hi,

I would like Fetchmail to check my mailserver periodically for new mail.

I created a small script which just needs one argument (the exit code
from fetchmail):

if [ $1  = 1]
then
  echo 1 > /proc/acpi/asus/mled
else
  echo 0 > /proc/acpi/asus/mled
fi
exit

The trouble is now how to get the exit code passed to the script:
When fetchmail is running deamonised it never returns and thus the exit
code does not exist.

Is it possible in some odd way to pass the result of the fechmail mail
check to the program called by the "postconnect" command ?

The idea I had was something like this:

[poll SERVERNAME with proto IMAP user 'USER' password 'PASSWD'
postconnect '/usr/bin/servicemled $?']

Cheers
RaceMouse

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

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

Michelle Konzack <lin...@fr...> writes:

>> Better pick: Replace procmail by maildrop, compile it so that the
>> fetchmail user is allowed to use -d, and install maildrop setuid-root.
>> It will be a better match for courier-imap anyhow. (Maildir++, quota,
>> same user database and all the nice parts of integration.)
>
> Unfortunatly "courier-maildrop" is no option for me, because I have
> setup a whole "office" web interface with php5 and the filters are
> set directly in procmail.
>
> The syntax of maildrop is driving me crazy and I have not the time
> and LUST to recode all from scratch again!

D'accord.

At least there are ways to do it without making fetchmail UID root.

Personally, I prefer feeding everything through Postfix, because that
gives me Amavisd-new's virus scanning capabilities and decent logging.

-- 
Matthias Andree

[fetchmail-users] Re: message was not the expected length errors

[Frederik <fr...@gm...>]

On 1/19/06, Frederik <fr...@gm...> wrote:
> On 12/24/05, Sunil Shetye <sh...@bo...> wrote:
> > Quoting from Frederik's mail on Fri, Dec 23, 2005:
> > > Since tonight, I'm suffering from "message [...] was not the expected
> > > length" errors. I see it on one mailbox on my ISP (the other mailbox is
> > > unaffected though), and it makes fetchmail completely fail to retrieve
> > > mails from the mailbox concerned.
>
> > Please try adding the "forcecr" option to your fetchmailrc.
> >
> > In case it doesn't work, please send the output of "fetchmail -V" and
> > the details of your smtp server.
> >
> > Is the "message ... was not the expected length" error coming on every
> > mail or on specific mails only?
>
> The problem disappeared as suddenly after it appeared. Well, till
> today at least, because now exactly the same problem started again.

And a bit after I wrote this, all started to work again.

That means: while doing a fetchmail -v -v, it still had the error
messages about inccorret size, but it continued to download
everything. After that, I restarted fetchmail, and mails are now being
downloaded without errors. Weird...


--
Surf veilig en snel met de Mozilla Firefox web browser
http://spreadfirefox.com/community/?q=affiliates&amp;id=617&amp;t=1

[fetchmail-users] Re: message was not the expected length errors

[Frederik <fr...@gm...>]

On 12/24/05, Sunil Shetye <sh...@bo...> wrote:
> Quoting from Frederik's mail on Fri, Dec 23, 2005:
> > Since tonight, I'm suffering from "message [...] was not the expected
> > length" errors. I see it on one mailbox on my ISP (the other mailbox is
> > unaffected though), and it makes fetchmail completely fail to retrieve
> > mails from the mailbox concerned.

> Please try adding the "forcecr" option to your fetchmailrc.
>
> In case it doesn't work, please send the output of "fetchmail -V" and
> the details of your smtp server.
>
> Is the "message ... was not the expected length" error coming on every
> mail or on specific mails only?

The problem disappeared as suddenly after it appeared. Well, till
today at least, because now exactly the same problem started again.

It seems to happen on all messages, deleting the message which causes
the problem, just makes it halt on the next message.

I cannot understand why it works fine so lang, and then it starts to
go mad like this. Another e-mail account I have from the same ISP,
works still fine.

Also something which is not yet clear to me: is it a problem that my
ISP's POP3 server is giving wrong info about the size of the mail to
fetchmail, or is it my own local MTA that complains that the e-mail it
receives is not the size fetchmail said it is? In the first case, it
would not matter much which MTA I am using locally?

Adding forcerc did not help.

My own setup: exim 4.50 from Debian Sarge (using sa-exim and clamav,
but that should not matter much). Problem happens with both Sarge's
fetchmail 6.2.5-12sarge3 and recompiled 6.3.1-4 from unstable.

# fetchmail -V
fetchmail: WARNING: Running as root is discouraged.
This is fetchmail release 6.3.1+NTLM+SDPS+SSL+NLS
Fallback MDA: (none)
Linux Luna 2.6.14-cks4 #1 Wed Nov 9 16:10:51 CET 2005 i686 GNU/Linux
Taking options from command line
No mailservers set up -- perhaps /root/.fetchmailrc is missing?


Is not there simply a way to make it *ignore* this problem? Actually
fetchmail is completely unusable to me now, as I cannot access my
e-mail anymore :-(

--
Surf veilig en snel met de Mozilla Firefox web browser
http://spreadfirefox.com/community/?q=affiliates&amp;id=617&amp;t=1

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

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

Hallo Matthias,

Am 2006-01-08 22:56:51, schrieb Matthias Andree:

> It's been a long time - désolé. I hope it's still useful :-)

:-)

> Set procmail setuid-root if you trust it (I don't trust it though).
> 
> Better pick: Replace procmail by maildrop, compile it so that the
> fetchmail user is allowed to use -d, and install maildrop setuid-root.
> It will be a better match for courier-imap anyhow. (Maildir++, quota,
> same user database and all the nice parts of integration.)

Unfortunatly "courier-maildrop" is no option for me, because I have
setup a whole "office" web interface with php5 and the filters are
set directly in procmail.

The syntax of maildrop is driving me crazy and I have not the time
and LUST to recode all from scratch again!

Greetings
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


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

[fetchmail-users] Re: Please blacklist Subject "fetchmail-users digest..."

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

Am 2006-01-08 22:13:15, schrieb Matthias Andree:

> It's impolite to send messages to lists with meaningless subjects, and
> people with inferior mailers and without a chance to split the digest up
> locally still have the option to switch their subscription to the
> "plain" format.

Right, but what I do not understand is, that for example "procmail"
has a realy nice example in its manpages how to split a digest into
singel parts using "formail".

I am on three lists which sends digest only and I get each day 5-20
singel messages into my Mailbox without any headache.

<seufz>Nobody like RTFM</seufz>

Greetings
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


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

[fetchmail-users] fetchmail 6.3.2-rc4 final release candidate

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

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

Greetings,

a recently reported Debian bug spoiled my plans to have -rc3 as the
final release candidate, but I hope it was the penultimate - to avoid
embarrassment with the final 6.3.2, I've chosen to insert -rc4.

This release candidate fixes a segfault after sending a bounce.

This release candidate (#4) for 6.3.2 is available from
http://mandree.home.pages.de/fetchmail/

I have requested a CVE Id from MITRE to track this problem and will add
it to the security announcement before 6.3.2 release.

Changes in fetchmail 6.3.2-rc4 (from -rc3):

# SECURITY FIX IN THIS RELEASE
* CVE-2006-XXXX: Fix segfault or bus error after bouncing a message.  This bug
  was introduced into 6.3.0 when removing alloca(); it caused fetchmail to free
  random memory.  Reported by Nathaniel W. Turner, Debian Bug#348747.
  See fetchmail-SA-2006-01.txt

# CHANGES RELEVANT TO PACKAGERS:
* Added fetchmail-SA-2006-01.txt to the distribution.

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

iD8DBQFDzxDdvmGDOQUufZURAiVYAJ4q2xxCuGVrxcP+VJ/fronZz7R/twCgsJXS
jVwe62uMCA+5wYN2iIQ5F1Y=
=V2fc
-----END PGP SIGNATURE-----

[fetchmail-users] fetchmail 6.3.2-rc3 final release candidate

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

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

Greetings,

the final release candidate (#3) for 6.3.2 is available from
http://mandree.home.pages.de/fetchmail/

I released this candidate to give translators some more days to catch up
with the upstream before 6.3.2 is released. Spanish is severely lagged
behind with a potential new translator, and other languages could also
use some updating.

- ---------------------------------------------------------------------
If the translation of YOUR language is missing or out of date, please
help!  Contact me for details on the fetchmail-devel@ mailing list.
- ---------------------------------------------------------------------

(French request for help with translating fetchmail to French:)
| Si vous parlez le français très bien, je vous prie de m'aider et
| devenir traducteur de fetchmail. En ce cas, je vous donnerai une
| traduction complète à commencer sans trop d'effort. Mon français n'est
| pas assez bon afin de m'appeler traducteur officiel.
| 
| J'avais déjà posé cette question dans la liste traduc@ mais je n'y ai
| pas trouvé un autre traducteur.
| 
| Merci.
(end of French)

These are the changes since 6.3.2-rc2:

# CHANGES THAT WILL NOT APPEAR IN THE FINAL NEWS FILE
  because they are revisions of -rc internal changes
  or are too minor:
* The Maillennium workaround warning was changed to put the Maillennium
  server name into quotes.
* A few compiler warnings were fixed
* COPYING was revised

# CHANGES RELEVANT TO PACKAGERS:
* The outdated BUGS document was removed from the distribution.  Matthias Andree

# OTHER USER-VISIBLE CHANGES:
* fetchmail.man: Fix accented characters in Héctor García's name.  Merged from
  downstream debian/patches/01_man_page.dpatch. Matthias Andree.
* Add missing --help text for "--sslcertck" option. Matthias Andree.
* fetchmailconf.py: Accept --help and --version. Matthias Andree.
* fetchmail --version  now prints the copyright notice. Matthias Andree.

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

iD8DBQFDzREdvmGDOQUufZURAr11AJ0Y4RDi6xcYG1ljtjgPdewh+LCzFwCePN3m
tit+cOqUH7B18BVlIZ84ZA8=
=ISlw
-----END PGP SIGNATURE-----

[fetchmail-users] Re: fetchmail-users -- confirmation of subscription -- request 274731

[Paul D. <pa...@pe...>]

On Sun, 15 Jan 2006 12:27:31 +0100, fet...@be... wrote:

> fetchmail-users -- confirmation of subscription -- request 274731
> 
> We have received a request from 68.230.78.84 for subscription of your
> email address, <pa...@pe...>, to the
> fet...@li... mailing list.  To confirm the
> request, please send a message to
> fet...@li..., and either:
> 
> - maintain the subject line as is (the reply's additional "Re:" is
> ok),
> 
> - or include the following line - and only the following line - in the
> message body: 
> 
> confirm 274731
> 
> (Simply sending a 'reply' to this message should work from most email
> interfaces, since that usually leaves the subject line in the right
> form.)
> 
> If you do not wish to subscribe to this list, please simply disregard
> this message.  Send questions to
> fet...@li....


	-Paul

Re: [fetchmail-users] Header Problems.

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

On Fri, 13 Jan 2006, rahul wrote:

> My fetchmail configration is:-
> 
> poll 209.216.x.x  with proto POP3
> localdomains example.com
> envelope "Delivered-To:"
> user cat...@ex... there with password "123456"
> is * here
> fetchall

What part about my answer (which you even quoted)

> > Look for "qvirtual".

did you not understand?

Now please stop wasting everybody's time, read the manual page and
adjust your fetchmail configuration.

Thank you.

-- 
Matthias Andree

Re: [fetchmail-users] Header Problems.

[rahul <rah...@ya...>]

Hi,

I FOLLOW THE SAME URL WHICH YOU HAVE SEND
http://fetchmail.berlios.de/fetchmail-FAQ.html#T2

I have configured .qmail file in /var/qmail/alias
like:-

cat .qmail-1-default
| ../bin/qmail-inject -a -f"$SENDER"
"${LOCAL#1-}@$HOST"


My fetchmail configration is:-

poll 209.216.x.x  with proto POP3
localdomains example.com
envelope "Delivered-To:"
user cat...@ex... there with password "123456"
is * here
fetchall


When i download mails through fetchmail,Now this time
you can see somthing different see the log:-

tail -f /var/log/qmail/send/current
@4000000043c796fc01f9ce54 new msg 1435879
@4000000043c796fc01f9da0c info msg 1435879: bytes 2764
from <rah...@ya...> qp 16283 uid 89
@4000000043c796fc02203274 starting delivery 2738: msg
1435879 to local exa...@ex...
@4000000043c796fc02203a44 status: local 1/10 remote
0/20
@4000000043c796fc026d48d4 delivery 2738: failure:
Sorry,_no_mailbox_here_by_that_name._(#5.1.1)/


HERE YOU CAN SEE SPECIAL HEADER "example.com-1-"
ADDED, HOW CAN I RESOLVE IT PLEASE HELP.



****Headers Detail****

Cc:   	us...@ex...

Content-Transfer-Encoding:  	8bit
Content-Type:  	text/plain; charset=iso-8859-1
Date:  	Mon, 2 Jan 2006 03:27:28 -0800 (PST) [03:27:28
AM PST]

Delivered-To:  	1-...@ex...

DomainKey-Signature:  	a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding;
b=2A5uUPvemgNlni1VGY/cByhG46J5QUZT5LONmUGG+hEL3Q2CnlsVYaxsZXDAer9/KSEVM2iDe8k22W8gsgwRFyfINgBiVqfR79OIwdsQefDcgcWuG8yF+7wzpx7swS/AHtkl2F1V0IrvGQaxHVrZe8aBCVnVK5V6Dzrfh9JAs5I=
;

From:  	rahul <rah...@ya...>
MIME-Version:  	1.0
Message-ID:  
<200...@we...>

Received:    * (qmail 9691 invoked from network); 2
Jan 2006 03:27:56 -0800    * from
web32115.mail.mud.yahoo.com (68.142.207.129) by
209.216.23.17 with SMTP; 2 Jan 2006 03:27:55 -0800   
* (qmail 38250 invoked by uid 60001); 2 Jan 2006
11:27:28 -0000    * from [203.197.202.18] by
web32115.mail.mud.yahoo.com via HTTP; Mon, 02 Jan 2006
03:27:28 PST

Return-Path:  	<rah...@ya...>
Subject:  	*****SPAM***** Test Mail !!!
To:  	us...@ex...
X-Spam-Checker-Version:  
SpamAssassin 2.63 (2004-01-11) on
admin.intersofttechnologies.com
X-Spam-Flag:  	YES
X-Spam-Level:

*******************END Headers Detail***************

--- Matthias Andree <mat...@gm...> wrote:

> rahul <rah...@ya...> writes:
> 
> > I AM AGAIN POSTING THE SAME MESSAGE. I CAN NOT
> CHANGE
> > RUNNING QMAIL SERVER, PLEASE HELP ME TO RESOLVE
> THIS
> > PROBLEM. 
> 
> Even if you cannot change your server, the answer is
> in the manual page,
> as I wrote earlier in my message that you have
> already read,
>
<http://lists.ccil.org/pipermail/fetchmail-friends/2006-January/009913.html>
> 
> The answer is also in the FAQ:
> <http://fetchmail.berlios.de/fetchmail-FAQ.html#T2>
> 
> Look for "qvirtual".
> 
> -- 
> Matthias Andree
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [fetchmail-users] Header Problems.

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

rahul <rah...@ya...> writes:

> I AM AGAIN POSTING THE SAME MESSAGE. I CAN NOT CHANGE
> RUNNING QMAIL SERVER, PLEASE HELP ME TO RESOLVE THIS
> PROBLEM. 

Even if you cannot change your server, the answer is in the manual page,
as I wrote earlier in my message that you have already read,
<http://lists.ccil.org/pipermail/fetchmail-friends/2006-January/009913.html>

The answer is also in the FAQ:
<http://fetchmail.berlios.de/fetchmail-FAQ.html#T2>

Look for "qvirtual".

-- 
Matthias Andree

[fetchmail-users] Header Problems.

[rahul <rah...@ya...>]

Hi,

I AM AGAIN POSTING THE SAME MESSAGE. I CAN NOT CHANGE
RUNNING QMAIL SERVER, PLEASE HELP ME TO RESOLVE THIS
PROBLEM. 


I have two users one is remote user
(us...@ex...).
&
second is us...@do.... us...@do... mails
forward to xy...@ex... a/c.

When i send mail from yahoo.com to
(To:-u...@ex...) &  (Cc:- us...@ex...).

when i check mails us...@ex... a/c its
received....
 But
when i check xy...@ex... a/c through webmail and
check my yahoo mail with headers, 
see the headers below:-

****Headers Detail****

Cc:   	us...@ex...

Content-Transfer-Encoding:  	8bit
Content-Type:  	text/plain; charset=iso-8859-1
Date:  	Mon, 2 Jan 2006 03:27:28 -0800 (PST) [03:27:28
AM PST]

Delivered-To:  	1-...@ex...

DomainKey-Signature:  	a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding;
b=2A5uUPvemgNlni1VGY/cByhG46J5QUZT5LONmUGG+hEL3Q2CnlsVYaxsZXDAer9/KSEVM2iDe8k22W8gsgwRFyfINgBiVqfR79OIwdsQefDcgcWuG8yF+7wzpx7swS/AHtkl2F1V0IrvGQaxHVrZe8aBCVnVK5V6Dzrfh9JAs5I=
;

From:  	rahul <rah...@ya...>
MIME-Version:  	1.0
Message-ID:  
<200...@we...>

Received:    * (qmail 9691 invoked from network); 2
Jan 2006 03:27:56 -0800    * from
web32115.mail.mud.yahoo.com (68.142.207.129) by
209.216.23.17 with SMTP; 2 Jan 2006 03:27:55 -0800   
* (qmail 38250 invoked by uid 60001); 2 Jan 2006
11:27:28 -0000    * from [203.197.202.18] by
web32115.mail.mud.yahoo.com via HTTP; Mon, 02 Jan 2006
03:27:28 PST

Return-Path:  	<rah...@ya...>
Subject:  	*****SPAM***** Test Mail !!!
To:  	us...@ex...
X-Spam-Checker-Version:  
SpamAssassin 2.63 (2004-01-11) on
admin.intersofttechnologies.com
X-Spam-Flag:  	YES
X-Spam-Level:

*******************END Headers Detail***************

My fetchmail Version is 6.3.1.

my fetchmailrc file is:-
poll 209.216.253.97  with proto POP3
localdomains example.com localhost
envelope 'Delivered-To: 1-'
user xy...@ex... there with password "12345" is *
here
fetchall

Please  see /var/log/qmail/send/current log:

-@4000000043b91fee05a26bc4 info msg 882491: bytes 2937
from <rah...@ya...> qp 25416 uid 506
@4000000043b91fee09aaec14 starting delivery 114: msg
882491 to remote 1-...@ex...

If you see my current log, qmail add 
"1-...@ex..."

us...@ex... USER exist in qmail
BUT
1-...@ex... DOES NOT EXIST IN QMAIL. 

HOW CAN I REMOVE "1-" so that the mail should
delivered locally?

Any direction would be appreciated!!!  


--Thanks
Rahul  

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

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

Michelle Konzack <lin...@fr...> writes:

> 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

It's been a long time - désolé. I hope it's still useful :-)

Set procmail setuid-root if you trust it (I don't trust it though).

Better pick: Replace procmail by maildrop, compile it so that the
fetchmail user is allowed to use -d, and install maildrop setuid-root.
It will be a better match for courier-imap anyhow. (Maildir++, quota,
same user database and all the nice parts of integration.)

-- 
Matthias Andree

Re: [fetchmail-users] Fetchmail & Merak Mail Server

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

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

> Alternatively, put it this way - you have no choice.  You can either
> enable UIDL support or try to find another solution that doesn't use
> fetchmail :)

Only that the other solution would also have to use fetchall+nokeep
approaches or UIDL...

-- 
Matthias Andree

[fetchmail-users] Re: blacklisting digest replies

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

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

> On 08/01/06, Matthias Andree <mat...@gm...> wrote:
>> BTW, can the list filters please be adjusted so as to ban + reject
>> "fetchmail-users digest" in subjects?
>
> It doesn't look like mailman can handle this.  The closest it comes is
> allowing you to make a subject with that line a spam marker, which
> then requires an admin to review and act upon - a less than ideal
> approach.

OK, but Mailman can disable digest altogether.

>> I'm not looking at messages with these headers anyways, because they are
>> meaningless. People with incapable mailers deserve to suffer more than
>> those with capable mailers, and they can always switch to the plain
>> version, or split the digest up with maildrop or procmail helper
>> programs.
>
> Or simply copy-n-paste the correct subject when hitting reply :)

That won't do. People who reply to -digest posts 1. often hijack
threads, 2. break threading. Followups to my posts (as per In-Reply-To
or References) will appear in boldface and in the same thread. Just
pasting the right subject on the reply to the digest will break
threading and such followup hiliting.

Given that I'm one of the de-facto unpaid support guys, I decide what
hoops people can expect me to jump, and breaking threads, replying to
digest and other shipwrecks is expecting too much.

I expect proper mail formatting as "payment" for my spare time.

I've taken the liberty to change Subject, so it will pass my filter.

-- 
Matthias Andree

Re: [fetchmail-users] Please blacklist Subject "fetchmail-users digest..."

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

Rob Funk <rf...@fu...> writes:

> Matthias Andree wrote:
>> BTW, can the list filters please be adjusted so as to ban + reject
>> "fetchmail-users digest" in subjects?
>
> You do realize that under such a policy, your message (and this reply) 
> would be rejected.... :-)

Yes, I do. It doesn't matter, because we don't have such list messages
under such a policy.

> Ah, but others here are.  I don't see any need for any one person to look 
> at all the threads.

I'm filtering such subjects now. If someone feels he's found a bug,
he'll have to use a more catchy subject if he wants me to see the post
(or perhaps file a bug at the berlios tracker).

>> People with incapable mailers deserve to suffer more than 
>> those with capable mailers, and they can always switch to the plain
>> version, or split the digest up with maildrop or procmail helper
>> programs.
>
> On the -users list I don't see much reason for being too strict or telling 
> people they're using the wrong MUA.  (This isn't linux-elitists, after 
> all.)  I could see an argument for it on -devel, but it hasn't been an 
> issue there.

It's impolite to send messages to lists with meaningless subjects, and
people with inferior mailers and without a chance to split the digest up
locally still have the option to switch their subscription to the
"plain" format.

-- 
Matthias Andree