fetchmail-users — User questions and discussion

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

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

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

Greetings,

I have just released fetchmail 6.2.9-rc8, the hopefully last release
candidate before 6.3.0. It fixes two regressions introduced into -rc7
and fixes another minor bug. Some polish was added to manual page and
error messages.

- -----------------------------------------------------------------------
Support call - fetchmail needs funding:
<https://developer.berlios.de/developer/make_donation.php?user_id=2007>
- -----------------------------------------------------------------------

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 -rc7 are:
* POP2 is obsolete. Support for POP2 may be removed from a future fetchmail
  version without further notice. (MA)
* When eating IMAP message trailer, don't see any line containing "OK" as the
  end of the trailer, but wait for the proper tagged OK line. To work around
  the qmail + Courier-IMAP problem in Debian Bug#338007. Matthias Andree
* Fix Debian Bug#317761: when trying to send a bounce message, don't bail out
  if we cannot qualify our own hostname, so we aren't losing the bounce.
  Instead, pass the buck on to the SMTP server and use our own unqualified
  hostname. Matthias Andree
* Revise some error messages so they are less confusing. Sunil Shetye.
* Man page: update --smtphost documentation. Matthias Andree
* Man page: clarify --loghost works only while detached. Matthias Andree
(not in the NEWS file:)
* Fix -rc7 crash when our own hostname cannot be qualified when we are
  to send a bounce. Matthias Andree

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=7951>
<http://home.pages.de/~mandree/fetchmail/>

Regards,

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

iD8DBQFDcrcyvmGDOQUufZURAhNEAKDViQK2aqSjUQ4QzRd1SgwXqol10QCfQ0i1
pS2MOIobL/KsbIULa8bWdws=
=CpXr
-----END PGP SIGNATURE-----

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

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

Michelle Konzack wrote:
> So right, I am using fetchmail + procmail + courier-imap
> and sometimes They are errors and messages are going into
> /var/mail/<$USER> which are inaccessible.  Specialy if I
> have more then 17.000 $USER.
>
> I think, procmail should have an config option to stop
> this behaviour and return an error instead.

As Stephen van den Berg posted:

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


-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

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

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

Hello Thomas,

Am 2005-11-02 17:58:28, schrieb Thomas Wolff:

> I would not say this issue was a user error on my part (because it's 
> not properly documented), but it's not a serious issue as I said 
> before. Procmail handles an inaccessible system mailbox well (this is 
> documented); I was not able to check what would happen if /var/mail is 
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> completely inaccessible but I assume something reasonable should 
  ^^^^^^^^^^^^^^^^^^^^^^^
> happen too, so I withdraw my statement that procmail is an unsafe MDA.
> 
> User feedback and documentation should be improved, though, and maybe 
> this case of redirection should not be applied at all (or be configurable) 
> and rather a proper error indication returned instead.

So right, I am using fetchmail + procmail + courier-imap
and sometimes They are errors and messages are going into
/var/mail/<$USER> which are inaccessible.  Specialy if I
have more then 17.000 $USER.

I think, procmail should have an config option to stop
this behaviour and return an error instead.

It is not funny to walk through 17.000 Mailboxes to get
the "lost" messages back into the $USER mailboxes.

> Thanks and kind regards,
> Thomas Wolff

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: unsafe MDA procmail recommended by fetchmail

[Stephen R. v. d. B. <sr...@cu...>]

On 11/2/05, Thomas Wolff <to...@to...> wrote:
> I wrote:
> > I had a "disk quota exceeded" condition here which procmail failed
> > to handle properly. It accepted its input, threw it away and just
> > returned success.

> Stephen van den Berg wrote:
> > Procmail handles quota-exceeded problems
> > with flying colours since about 1993.
>
> > There is a 99.997% probability that the serious
> > issue is a user error on your part.

> Actually, it would also be prudent to add the mailing list address to
> the man page, in either the AUTHORS section or at least the -v description.

$ man procmail
[...]
MAILINGLIST
       There exists a mailinglist for questions relating to any program in the
       procmail package:
              <pro...@pr...>
                     for submitting questions/answers.
[...]
AUTHORS
[...]

> bash> cat /tmp/procmail.log.
> procmail: Quota exceeded while writing "testbox"
> procmail: Truncated file to former size
>  Subject: test mail
>   Folder: /var/mail/....                                                 1266

Even without asking on the mailinglist, the logfile
should have made clear what happened.

> At this point, I noticed that procmail has a fallback behaviour
> that when delivery to a local folder fails, it delivers into
> /var/mail instead. So actually the mail was not lost.
> This is, however, not documented anywhere.
[...]
> So, quoting you again
> > There is a 99.997% probability that the serious
> > issue is a user error on your part.
> I would not say this issue was a user error on my part (because it's
> not properly documented),

$ man procmailrc
[...]
       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.
[...]

> User feedback and documentation should be improved,

Please provide suggestions as to what wording in the logfile would have made
it more clear?
Same question for the manpage; in what way should we rephrase it?

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

> (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).
--
Sincerely,
                Stephen R. van den Berg (AKA BuGless).

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

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

I wrote:
> I had a "disk quota exceeded" condition here which procmail failed
> to handle properly. It accepted its input, threw it away and just
> returned success.

Stephen van den Berg wrote:
> Procmail handles quota-exceeded problems
> with flying colours since about 1993.

> There is a 99.997% probability that the serious
> issue is a user error on your part.
> ...
> In order to clarify the issue, it would be helpful
> if you can show the used procmailrc files, ...
When I did this, the issue did actually clarify (see below), ...

> Nonetheless, in order to assure timely assistance,
> it would be prudent to forward this
> information to the procmail mailinglist (instead
> of me personally), so they
> can help you fix the procmail recipe(s).
> See procmail -v as to the address of the list.
Right; I'm not doing this now because the issue has been clarified. 
Actually, it would also be prudent to add the mailing list address to 
the man page, in either the AUTHORS section or at least the -v description.


So here is the essential info:
bash> cd
bash> cat .procmailrc
MAILDIR=$HOME/Post

:0:
testbox

bash> cat testmail
From: to...@to...
To: to...@to...
Subject: test mail

1234567890123456789012345678901234567890123456789012345678901234567890

bash> if procmail -p < testmail ; then echo y ; fi
procmail: Quota exceeded while writing "testbox"
y
bash> ls -l Post/testbox 
-rw-------   1 demsn702 mdd            0 Nov  2 17:08 Post/testbox
bash> cat /tmp/procmail.log.
procmail: Quota exceeded while writing "testbox"
procmail: Truncated file to former size
 Subject: test mail
  Folder: /var/mail/....                                                 1266
bash> 


At this point, I noticed that procmail has a fallback behaviour 
that when delivery to a local folder fails, it delivers into 
/var/mail instead. So actually the mail was not lost.
This is, however, not documented anywhere. It is very unexpected 
behaviour for a user who has a configuration file that refers only 
to local folders (for mail sorting, spam filtering, etc). After all, 
if I configure local folders, I'm doing it just because I do not 
intend (or cannot) use /var/mail.
The event that procmail redirects into the system mailbox due to 
a failure should be noted clearly to the user in this case (on 
stdout/stderr, as well as in the logfile folder).

So, quoting you again
> There is a 99.997% probability that the serious
> issue is a user error on your part.
I would not say this issue was a user error on my part (because it's 
not properly documented), but it's not a serious issue as I said 
before. Procmail handles an inaccessible system mailbox well (this is 
documented); I was not able to check what would happen if /var/mail is 
completely inaccessible but I assume something reasonable should 
happen too, so I withdraw my statement that procmail is an unsafe MDA.

User feedback and documentation should be improved, though, and maybe 
this case of redirection should not be applied at all (or be configurable) 
and rather a proper error indication returned instead.

Thanks and kind regards,
Thomas Wolff

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

[Stephen R. v. d. B. <sr...@cu...>]

On 11/2/05, Thomas Wolff <to...@to...> wrote:
> I had a "disk quota exceeded" condition here which procmail failed
> to handle properly. It accepted its input, threw it away and just
> returned success.

Procmail handles quota-exceeded problems
with flying colours since about 1993.

> I heard before that exceeded quota is a known touchstone for proper
> error handling of software. Obviously procmail has a serious issue
> here which should be fixed as soon as possible.

There is a 99.997% probability that the serious
issue is a user error on your part.

>As long as it is not,
> fetchmail should no longer recommend using procmail but rather warn
> from it.

Acting prematurely on the 0.003% chance
that it is procmail's fault, would be unwise.

In order to clarify the issue, it would be helpful
if you can show the used procmailrc files, and
possibly even the generated logfile entries
(by procmail) which describe the event (or
shortly before and after).

Nonetheless, in order to assure timely assistance,
it would be prudent to forward this
information to the procmail mailinglist (instead
of me personally), so they
can help you fix the procmail recipe(s).
See procmail -v as to the address of the list.
--
Sincerely,
                Stephen R. van den Berg (AKA BuGless).

[fetchmail-users] unsafe MDA procmail recommended by fetchmail

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

There has been some discussion about the MDA configuration of fetchmail 
in the last few days, and I had proposed my configuration:
>   mda "formail >> ${MAIL-$HOME/Post/Inbox}"
or alternatively:
>   mda "formail -s procmail -p"

Jakob Hirsch as well as the fetchmail manual page even suggested to 
use just procmail alone.

Now I've happened to encounter a really serious problem with procmail.
It turned out to be what the fetchmail man page calls an "unsafe MDA":
> RETRIEVAL FAILURE MODES
>        The protocols fetchmail uses to talk  to  mailservers  are
>        next  to  bulletproof.   In normal operation forwarding to
>        port 25, no message is ever deleted (or  even  marked  for
>        deletion)  on  the  host  until  the  SMTP listener on the
>        client side has acknowledged to fetchmail that the message
>        has been either accepted for delivery or rejected due to a
>        spam block.
> 
>        When forwarding to an MDA, however, there is  more  possi-
>        bility of error.  Some MDAs are 'safe' and reliably return
>        a nonzero status on any delivery error, even  one  due  to
>        temporary  resource  limits.   The  well-known procmail(1)
>        program is like this; so are  most  programs  designed  as
>        mail  transport  agents, such as sendmail(1), and exim(1).
>        These programs give back a reliable positive  acknowledge-
>        ment  and  can be used with the mda option with no risk of
>        mail loss.  Unsafe MDAs, though,  may  return  0  even  on
>        delivery failure.  If this happens, you will lose mail.

I had a "disk quota exceeded" condition here which procmail failed 
to handle properly. It accepted its input, threw it away and just 
returned success.

I heard before that exceeded quota is a known touchstone for proper 
error handling of software. Obviously procmail has a serious issue 
here which should be fixed as soon as possible. As long as it is not, 
fetchmail should no longer recommend using procmail but rather warn 
from it.

Kind regards,
Thomas Wolff

[fetchmail-users] Re: [fetchmail-announce] fetchmail 6.2.9-rc7 available (fix galore)

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

Matthias Andree wrote:
> * Try to obtain FQDN as our own host by default, rather than using "localhost".
>   If hostname cannot be qualified, complain noisily and continue, unless
>   Kerberos, ODMR or ETRN are used (these require a FQDN).
>   Partial fix of Debian Bug#150137. Fixes Debian Bug#316454.  Matthias Andree

Das machte bei mir Probleme, ich muß den fetchmail-Daemon jetzt mit
-smtphost localhost laufen lassen, da sonst die lokale Mail-Auslieferung
fehlschlägt (der smtp-Daemon ist hier nur an localhost gebunden).

Oct 31 10:48:00 zi025 fetchmail[12521]: reading message ba...@nm...:1 of 1 (1804 header octets) 
Oct 31 10:48:00 zi025 fetchmail[12521]: SMTP connect to zi025.glhnet.mhn.de failed
Oct 31 10:48:00 zi025 fetchmail[12521]: SMTP transaction error while fetching from mail.in.tum.de

=> Vorschlag: lokale Delivery entweder immer über localhost machen, oder
              zumindest als Fallback probieren.

Mit der o.g. Option gehts, aber jetzt erhalte ich diese Warnungen im Log
(aber anscheinend nur 1x beim Start des fetchmail Daemons).

Oct 31 10:52:36 zi025 fetchmail[12645]: starting fetchmail 6.2.9-rc7 daemon 
Oct 31 10:52:36 zi025 fetchmail[12645]: IMAP connection to localhost failed: Connection refused
Oct 31 10:52:36 zi025 fetchmail[12645]: POP3 connection to localhost failed: Connection refused

Warum will er sich per IMAP bzw. POP3 zu localhost verbinden?

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

[fetchmail-users] fetchmail 6.2.9-rc7 available (fix galore)

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

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

Greetings,

I have just released fetchmail 6.2.9-rc7, yet another release candidate
before 6.3.0, after yet another bugfix evening.

- -----------------------------------------------------------------------
Support call - fetchmail needs funding:
<https://developer.berlios.de/developer/make_donation.php?user_id=2007>
- -----------------------------------------------------------------------

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.

If someone is familiar with Kerberos 5, the automatic detection is
broken, help with fixing configure.ac for Kerberos 5 without krb5-config
will be appreciated.

Changes since -rc6 are:
* fetchmailconf -h documents the fetchmailconf -h option. Matthias Andree
* fetchmailconf -V now prints the fetchmailconf version. Matthias Andree
* Add support for SubjectAltName (RFC-2595 or 2818), to avoid bogus certificate
  mismatch errors. Patch by Roland Stigge, Debian Bug#201113. (MA)
* make fetchmail --silent --quit really silent, Debian Bug #229014 by Dr.
  Andreas Krüger.  Matthias Andree
* cleanup --quit handling again (so that --silent --quit just kills the
  existing daemon, rather than continue running), and document it more clearly.
  Matthias Andree
* Print an error message if multiple "defaults" records are found in the
  configuration file.  Matthias Andree
* Bury on_exit officially - the necessary code had been missing from 6.0.0,
  6.2.0, 6.2.5.  Matthias Andree
* Exit with error if the lock file cannot be read.  Matthias Andree
* Exit with error if the lock file cannot be created exclusively, this got
  broken in a 6.2.6-pre, 6.2.5.2 and older were fine.  Matthias Andree
* Do not break some other process's lockfile in "-q" mode, but wait for the
  other process's exit.  Matthias Andree
* Man page: --sslfingerprint points user to x509(1ssl) and gives an example
  how to use it. Debian Bug#213484, Eduard Bloch. (MA)
* Try to obtain FQDN as our own host by default, rather than using "localhost".
  If hostname cannot be qualified, complain noisily and continue, unless
  Kerberos, ODMR or ETRN are used (these require a FQDN).
  Partial fix of Debian Bug#150137. Fixes Debian Bug#316454.  Matthias Andree
* fetchmailconf now sets the service properly after autoprobe. Fixes Debian
  Bug#320645.  Matthias Andree
* fetchmail.man: Fix Debian Bug#241883, making global options more clear. Matt
  Swift, Matthias Andree.

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=7815>
<http://home.pages.de/~mandree/fetchmail/>


Regards,

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

iD8DBQFDZVexvmGDOQUufZURAtBUAJ9AIiALOB7rJKS0f+re5c6Uc8r47ACgyDNI
T9vSFmnx8YtwCtMZCmCQIxk=
=KyCq
-----END PGP SIGNATURE-----

[fetchmail-users] fetchmail security announcement 2005-02 (CAN-2005-3088)

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

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

fetchmail-SA-2005-02: security announcement

Topic:		password exposure in fetchmailconf

Author:		Matthias Andree
Version:	1.02
Announced:	2005-10-21
Type:		insecure creation of file
Impact:		passwords are written to a world-readable file
Danger:		medium
Credits:	Thomas Wolff, Miloslav Trmac for pointing out
		that fetchmailconf 1.43.1 was also flawed
CVE Name:	CVE-2005-3088
URL:		http://fetchmail.berlios.de/fetchmail-SA-2005-02.txt

Affects:	fetchmail version 6.2.5.2
		fetchmail version 6.2.5
		fetchmail version 6.2.0
		fetchmailconf 1.43   (shipped with 6.2.0, 6.2.5 and 6.2.5.2)
		fetchmailconf 1.43.1 (shipped separately, now withdrawn)
		(other versions have not been checked but are presumed affected)

Not affected:	fetchmail 6.2.9-rc6
		fetchmailconf 1.43.2 (use this for fetchmail-6.2.5.2)
		fetchmailconf 1.49   (shipped with 6.2.9-rc6)
		fetchmail 6.3.0      (not released yet)

Corrected:	2005-09-28 01:14 UTC (SVN) - committed bugfix (r4351)
		2005-10-21                 - released fetchmailconf-1.43.2
		2005-10-21                 - released fetchmail 6.2.9-rc6

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

2005-10-21	1.00 - initial version (shipped with -rc6)
2005-10-21	1.01 - marked 1.43.1 vulnerable
		     - revised section 4
		     - added Credits
2005-10-27	1.02 - reformatted section 0
		     - updated CVE Name to new naming scheme

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

The fetchmailconf program before and excluding version 1.49 opened the
run control file, wrote the configuration to it, and only then changed
the mode to 0600 (rw-------). Writing the file, which usually contains
passwords, before making it unreadable to other users, can expose
sensitive password information.

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

Run "umask 077", then run "fetchmailconf" from the same shell. After
fetchmailconf has finished, you can restore your old umask.

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

For users of fetchmail-6.2.5.2:
- -------------------------------
Download fetchmailconf-1.43.2.gz from fetchmail's project site
<http://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=6617>,
gunzip it, then replace your existing fetchmailconf with it.

For users of fetchmail-6.2.6* or 6.2.9* before 6.2.9-rc6:
- ---------------------------------------------------------
update to the latest fetchmail-devel package, 6.2.9-rc6 on 2005-10-21.
<https://developer.berlios.de/project/showfiles.php?group_id=1824>

A. References
=============

fetchmail home page: <http://fetchmail.berlios.de/>

B. Copyright, License and Warranty
==================================

(C) Copyright 2005 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-2005-02.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDY5UwvmGDOQUufZURAqUhAJ0XxrMg5KiVEzsSTM8bgT9m1z2MyACg5lGh
5a6rj77JM6OycVmrPvINmOY=
=YhtX
-----END PGP SIGNATURE-----

Re: [fetchmail-users] Re: [Bug 110676] Problem with /etc/hosts in gentoo handbook and IPv6

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

Karel Kulhavy wrote:
> Fetchmail and gentoo will have to agree whose bug it is.
>
> If you don't know how, I have a hint: a magical term "interface
> specification" exists.
>
> On Fri, Oct 28, 2005 at 09:25:19AM +0000, bug...@ge... 
wrote:
> > Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=110676
> > Secure: https://bugs.gentoo.org/show_bug.cgi?id=110676

Following this link, I find you wrote this:
| Gentoo handbook should clearly state that if the system has permanent
| only IPv6 address, the /etc/hosts entries should look like this: 
| 2001:5C0:8FFF:FFFE:0:0:0:33AB kestrel kestrel.twibright.com
| 127.0.0.1 localhost kestrel

That's the first I've seen about your machine having only an IPv6 address 
and no ipv4 address besides 127.0.0.1.

The version to be released soon has a lot of IPv6 changes (fixes), so I'd 
suggest you try the latest release candidate (currently 6.2.9-rc6) and 
see if that works any better for you using Gentoo's 
recommended /etc/hosts configuration (i.e. without your machine name on 
the 127.0.0.1 line).

http://developer.berlios.de/project/showfiles.php?group_id=1824

-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

[fetchmail-users] Re: [Bug 110676] Problem with /etc/hosts in gentoo handbook and IPv6

[Karel K. <cl...@tw...>]

Fetchmail and gentoo will have to agree whose bug it is.

If you don't know how, I have a hint: a magical term "interface specification"
exists.

CL<

On Fri, Oct 28, 2005 at 09:25:19AM +0000, bug...@ge... wrote:
> Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=110676
> Secure: https://bugs.gentoo.org/show_bug.cgi?id=110676
> 
> 
> ja...@ge... changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |ja...@ge...
>          AssignedTo|bug...@ge...    |net...@ge...
>            Severity|critical                    |major
> 
> 
> 
> 
> ------- Additional Comments From ja...@ge...  2005-10-28 02:25 PDT -------
> This looks like fetchmail bug, there's nothing wrong with the /etc/hosts
> example, AFAIK.
> 
> 
> -- 
> Configure bugmail: http://bugs.gentoo.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

[fetchmail-users] fetchmail stopping on spam

[mbox m. <ba...@at...>]

I recently had this problem and I had turned off dns and removed the mda
lines from .fetchmailrc...

After doing that...things started working like I would expect them to.

This is purely anecdotal, however.


Mike B.
-- 
mbox mbarsalou <ba...@at...>

Re: [fetchmail-users] fetchmail gets stuck because of malformed spam

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

On 27/10/05, Karel Kulhavy <cl...@tw...> wrote:

> Hehe one could send a malformed e-mail to this mailing list so all
> people would get pissed - or write a bot which would send every hour
> - that would make the bug to be solved promptly ;-)

However, you'd have to be subscribed to do that, and if somebody were
stupid enough to do it then the following *would* happen promptly:

a) They'd be reported to their ISP
b) Their address would be unsubscribed (and I'd keep a note of the
source IP to ban them in future)

Worth noting too that the situation reported doesn't seem to by
typical.  Certainly on the occasions I've hit similar problems with
malformed email rejected by my SMTP server fetchmail happily carries
on fetching the other mail.  This suggests that the problem is a local
config issue.  Sadly without the OP providing the (much requested)
output of "fetchmail -v -v" it's impossible to do anything but
speculate.

--
                 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 gets stuck because of malformed spam

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

Tho...@si... wrote:

> As an additional information I just remembered that I had to use
> the webmail interface because Mozilla Thunderbird was not able to
> retrieve those mails, either, and got stuck the same way,
> when this problem occurred here a few months ago.

So it is very likely that it was an pop/imap server issue, and fetchmail
cannot do much about it.
I have been running fetchmail for several years now and never had a single
case of it hanging because of some malformed message. That doesn't mean
there weren't any bugs, of course.

Re: [fetchmail-users] fetchmail gets stuck because of malformed spam

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

Karel Kulhavy wrote:

>> That means that your MTA is used, which is fetchmail's default.
>> A MDA would procmail, maildrop etc., or Exim itself, but not via smtp.
> If I don't run Exim, fetchmail doesn't deliver. If I run Exim,

Which proves that you are _not_ using the MDA option and that you have no
clue about the difference MTA/MDA. Use your favorite search engine to find
one of the trillion websites explaining it.


PS: And stop mailing me personally, this is list traffic.

Re: [fetchmail-users] fetchmail gets stuck because of malformed spam

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

Thomas Wolff wrote:
>> > or like this:
>> >   mda "formail -s procmail -p"
>> formail is unnecessary here, I think, as fetchmail calls the mda for
>> every single message seperately.
> But fetchmail doesn't generate a "From " line which is needed as a
> message separator in the mailbox. That's why formail is necessary.

Shouldn't that be done by procmail itself? Programs running an MDA
shouldn't care about the local mailbox format. I may be wrong about this,
it's long ago that I used procmail and mbox.

> Whatever the issue, error handling should be reviewed and revised to
> never produce this kind of DoS situation, independent of actual error
> analysis.

If it's a server issue, there's not much fetchmail can do about it. If
it's a fetchmail flaw, you are right of course.

Re: [fetchmail-users] fetchmail gets stuck because of malformed spam

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

> > or like this:
> >   mda "formail -s procmail -p"

> formail is unnecessary here, I think, as fetchmail calls the mda for every
> single message seperately.
But fetchmail doesn't generate a "From " line which is needed as a 
message separator in the mailbox. That's why formail is necessary.
Please check; maybe the "/usr/bin/procmail" example under --mda in 
the manual page is misleading here and should be changed as well.
Without formail, I couldn't produce a mailbox that is readable with "mail".

> > access to my other mails, I did not care to retrieve any of those
> > (using the webmail interface) which I should have sent here for bug
> > analysis, sorry.

> The output of fetchmail -v -v would have been a start. This could have
> also been an issue of the pop/imap server.
As I noted before (in a mail that unfortunately didn't make it on the 
list yet as I used the wrong sender address :( ) :
Whatever the issue, error handling should be reviewed and revised to 
never produce this kind of DoS situation, independent of actual error 
analysis.

Best regards,
Thomas

[fetchmail-users] Re: fetchmail gets stuck because of malformed spam

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

Quoting from Karel Kulhavy's mail on Wed, Oct 26, 2005 at 10:59:30AM +0200:
> I got some malformed spam which causes fetchmail to stop on this spam
> and I am unable to download 162 waiting messages behind this spam.
> 
> This seems to be some kind of fetchmail DoS vulnerability - if someone
> sends this mail to all fetchmail users in the world, they will be pretty
> pissed off to have to log in to remote machine and erase the e-mail by
> hand. And if he sends every hour, they will have to change to a
> different program than fetchmail ;-)

Could you send the output of "fetchmail -v" when the mail gets stuck?

My guess is that the mail gets stuck because fetchmail is unable to
send a bounce message.

-- 
Sunil Shetye.

Re: [fetchmail-users] fetchmail gets stuck because of malformed spam

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

Tho...@si... wrote:

> In this case, it might rather look like this:
>   mda "formail >> ${MAIL-$HOME/Post/Inbox}"

This is a little dangerous, as there is no locking involved

> or like this:
>   mda "formail -s procmail -p"

formail is unnecessary here, I think, as fetchmail calls the mda for every
single message seperately.

> access to my other mails, I did not care to retrieve any of those
> (using the webmail interface) which I should have sent here for bug
> analysis, sorry.

The output of fetchmail -v -v would have been a start. This could have
also been an issue of the pop/imap server.

Re: [fetchmail-users] fetchmail gets stuck because of malformed spam

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

Karel Kulhavy wrote:

once again:
>> Please keep list traffic on the list.


> But I have mda option.

No, you don't, as your output of fetchmail -V says:

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

That means that your MTA is used, which is fetchmail's default.
A MDA would procmail, maildrop etc., or Exim itself, but not via smtp.

With "mda" it would say something like

Messages will be delivered with "/usr/sbin/sendmail -i %T"

Re: [fetchmail-users] fetchmail gets stuck because of malformed spam

[Karel K. <cl...@tw...>]

On Thu, Oct 27, 2005 at 12:07:35PM +0200, Tho...@si... wrote:
> Jakob Hirsch wrote:

[...]

> So I don't know either if the malformed parts raised the same problem 
> as it occurred now. But in any case, I think fetchmail error handling 
> should be carefully reviewed for any possible case of aborting the 
> retrieval in order to avoid this DoS situation in the future.

Hehe one could send a malformed e-mail to this mailing list so all
people would get pissed - or write a bot which would send every hour
- that would make the bug to be solved promptly ;-)

CL<
> 
> Kind regards,
> Thomas Wolff

Re: [fetchmail-users] fetchmail gets stuck because of malformed spam

[<Tho...@si...>]

I wrote:

> But I've actually had similar problems a while ago; fetchmail couldn't 
> get past certain spam mails. I had to use a webmail interface to 
> delete them to get any further. Unfortunately, as I needed quick 
> access to my other mails, I did not care to retrieve any of those 
> (using the webmail interface) which I should have sent here for bug 
> analysis, sorry.
As an additional information I just remembered that I had to use 
the webmail interface because Mozilla Thunderbird was not able to 
retrieve those mails, either, and got stuck the same way, 
when this problem occurred here a few months ago.

Kind regards,
Thomas Wolff

Re: [fetchmail-users] fetchmail gets stuck because of malformed spam

[<Tho...@si...>]

Jakob Hirsch wrote:

> I personally would always recommend using fetchmail with the mda option
> (for the usual pop/imap retrieval), so you won't have all these smtp
> problems.
> ...
> > What is mda option?
> It means that your mail is not delivered over smtp but to the local
> delivery agent, which (usually) simply drops it in your inbox.
> 
> I use:
> 
> defaults
>   mda "/usr/sbin/sendmail -i %T"
> ...

I have a personal setup that does not (cannot) rely on a working local 
mail environment (the machine is not normally intended for handling mails).
In this case, it might rather look like this:
  mda "formail >> ${MAIL-$HOME/Post/Inbox}"
or like this:
  mda "formail -s procmail -p"

So for me, there is no smtp involved in mail retrieval.
But I've actually had similar problems a while ago; fetchmail couldn't 
get past certain spam mails. I had to use a webmail interface to 
delete them to get any further. Unfortunately, as I needed quick 
access to my other mails, I did not care to retrieve any of those 
(using the webmail interface) which I should have sent here for bug 
analysis, sorry.

So I don't know either if the malformed parts raised the same problem 
as it occurred now. But in any case, I think fetchmail error handling 
should be carefully reviewed for any possible case of aborting the 
retrieval in order to avoid this DoS situation in the future.

Kind regards,
Thomas Wolff

Re: [fetchmail-users] fetchmail gets stuck because of malformed spam

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

Karel Kulhavy wrote:


Please keep list traffic on the list.

>> I personally would always recommend using fetchmail with the mda option
> What is mda option?


It means that your mail is not delivered over smtp but to the local
delivery agent, which (usually) simply drops it in your inbox.

I use:

defaults
  mda "/usr/sbin/sendmail -i %T"
  is "jh" here

poll imap.web.de proto imap user x pass y fetchall ssl


For more information: man fetchmail

> What is multidrop?

The opposite of single-drop, which you are using.
For more information: man fetchmail