fetchmail-users — User questions and discussion

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

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

I had confused:
>> # if procmail has reached here, delivery has failed. return with a
>> ...
> Fetchmail needs ...

Jakob Hirsch wrote:
> This is not a fetchmail issue and this whole discussion is unrelated to
> fetchmail. If you are really interested in improving procmail's error
> behaviour, you should move this to the procmail-list.
Sure, sorry for my confusion.

> As a sidenote: I doubt procmail is so bad, but you never know. Anyway, I used
> maildrop for quite a while. Main reason was its non-obfuscating filter
> language, but it also has a proper error handling. And I never needed anything
> like formail to use it as MDA.
Thanks for the hint, it looks promising.

Kind regards,
Thomas Wolff

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

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

Thomas Wolff wrote:

>> # 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
> So that may work, but it is really an obscure trick.
> Fetchmail needs to have an easy-to-use, well-documented facility to
> configure its error behaviour in an obvious way.

This is not a fetchmail issue and this whole discussion is unrelated to
fetchmail. If you are really interested in improving procmail's error
behaviour, you should move this to the procmail-list.

As a sidenote: I doubt procmail is so bad, but you never know. Anyway, I used
maildrop for quite a while. Main reason was its non-obfuscating filter
language, but it also has a proper error handling. And I never needed anything
like formail to use it as MDA.

> That other program may often be formail. While formail -s does
> propagate an error return code here, this is not reliable because it's
> not documented. Should be fixed.

By whom? Certainly not by any fetchmail maintainer.

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

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

Sunil Shetye wrote:
> Quoting from Michelle Konzack's mail on Mon, Nov 07, 2005 at 07:29:19PM +0100:
> > ...
> > I think, procmail should have an config option to stop
> > this behaviour and return an error instead.
> > ...
> 
> 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
> ==========================================================================

So that may work, but it is really an obscure trick.
Fetchmail needs to have an easy-to-use, well-documented facility to 
configure its error behaviour in an obvious way.


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

That other program may often be formail. While formail -s does 
propagate an error return code here, this is not reliable because it's 
not documented. Should be fixed.


Kind regards,
Thomas Wolff

Re: [fetchmail-users] RE: Fetchmail error!

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

On 13/11/05, deven barhate <dev...@gm...> wrote:
> fetchmail: POP3> USER us...@so...
> fetchmail: POP3< +OK User name accepted, password please
> fetchmail: POP3> PASS
> fetchmail: POP3< -ERR Bad login
> fetchmail: Bad login
> fetchmail: Authorization failure on us...@so...
> fetchmail: POP3> QUIT
> fetchmail: POP3< +OK Sayonara
> fetchmail: 6.2.0 querying somemailserver.com (protocol POP3) at Sun 13 Nov
> 2005 06:36:18 PM IST: poll completed
>
> Now the thing is I can access the mails through webmail over the internet
> with same USERNAME and PASSWD.
>
> then why fetchmail is not able to fetch the mails?

Have you tried using just "user" (dropping "@somemailserver.com")? 
Are there any special (ie not A-Z, a-z or 0-9) characters in your
password?

Finally, try the latest version of fetchmail, 6.2.0 is old and has a
number of known security issues.  You should either be on 6.2.5.2 or
the latest 6.3.0 release candidate.

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

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

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

Quoting from Michelle Konzack's mail on Mon, Nov 07, 2005 at 07:29:19PM +0100:
> 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.

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

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

-- 
Sunil Shetye.

[fetchmail-users] RE: Fetchmail error!

[deven b. <dev...@gm...>]

 Devendra Barhate.
Pune.
 Sub: I'm getting error "Query status=3 (AUTHFAIL)" while using
fetchmail-6.2.0-3
 Dear Friends,
 I have installed redhat 9.0 with fetchmail-6.2.0-3 on P4 system.
 While fetchmail starts it gives me an error no 3 i.e.Query status=3
(AUTHFAIL)
or bad login .
 Have look at follwing logs messages..
  fetchmail: 6.2.0 querying somemailserver.com
<http://somemailserver.com/>(protocol POP3) at Sun 13 Nov 2005
06:33:52 PM IST: poll started
fetchmail: POP3< +OK POP3 accord1.ads4globe.net<http://accord1.ads4globe.net/>
v2003.83rh server ready
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows:
fetchmail: POP3< TOP
fetchmail: POP3< LOGIN-DELAY 180
fetchmail: POP3< UIDL
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN LOGIN
fetchmail: POP3< .
fetchmail: POP3> USER fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows:
fetchmail: POP3< TOP
fetchmail: POP3< LOGIN-DELAY 180
fetchmail: POP3< UIDL
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN LOGIN
fetchmail: POP3< .
fetchmail: POP3> USER us...@so...
fetchmail: POP3< +OK User name accepted, password please
fetchmail: POP3> PASS
fetchmail: POP3< -ERR Bad login
fetchmail: Bad login
fetchmail: Authorization failure on us...@so...
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Sayonara
fetchmail: 6.2.0 querying somemailserver.com
<http://somemailserver.com/>(protocol POP3) at Sun 13 Nov 2005
06:36:18 PM IST: poll completed

Now the thing is I can access the mails through webmail over the internet
with same USERNAME and PASSWD.
 then why fetchmail is not able to fetch the mails?
  Awaiting for reply.
 Thanking you,
 Deven.

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

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

On 11/11/05, Thomas Wolff <to...@to...> wrote:
> There is this new warning "WARNING: Running as root is discouraged."
> which is somehow disturbing.
> 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).

Why?  There is no need to run fetchmail as root.  You can, and should,
run it as an unpriviledged user.

Look on the bright side, it had been proposed to refuse (as some
software does) to run as root.  It was agreed that at least for 6.3
this wouldn't happen, giving people like you time to change their
configuration.

> 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
> recommended in general but it's not fetchmail to tell me that every
> time I retrieve my mail.

I dunno, it does encourage you to use it in a more secure manner :-)

Seriously, running anything as root that doesn't have to be run as
root is a security risk.  Simply run fetchmail using a normal user
account and the message will go away.

--
                 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] WARNING: Running as root is discouraged.

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

There is this new warning "WARNING: Running as root is discouraged." 
which is somehow disturbing.
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).
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 
recommended in general but it's not fetchmail to tell me that every 
time I retrieve my mail.

Please remove the message.

Kind regards,
Thomas Wolff

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

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

On 10/11/05, Thomas Wolff <to...@to...> wrote:
>
> Then I switched to fetchmail 6.2.9rc7 and it fetched all mails as it
> should do, except the affected message, on which it still reported:
> fetchmail: message delimiter found while scanning headers
>
> What still concerns me, however, is that it discarded that message
> completely and wrote no trace of it to the mailbox, so messages with
> that kind of problem (whatever it may be) can not be checked or
> analysed anymore with fetchmail.

The message is illegally formatted (in this case, has no blank line
between headers and body) and should never have been accepted by 1&1's
mail server (though from personal experience I'm not surprised). 
Fetchmail is doing the correct thing and discarding this email.

Previously it has been suggested that one option might be to wrap the
entire of the illegal mail and forward it to the postmaster.  Nobody
however was willing to put the effort into a patch to do this, and
frankly given that every occurence to date has been identified as spam
I'm not surprised.

I am however happy to see that the forthcoming 6.3.0 release will
handle this more gracefully than previous versions :)

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

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

Michelle Konzack wrote:
> Am 2005-11-07 13:46:15, schrieb Rob Funk:
> > 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).
>
> Hmmm, I have tried this, but $DEFAULT is set in the $USER configs to
>
>     DEFAULT=$MAILDIR/.maybe_spam/
>
> and ORGMAIL is unset.

Do you have a line that's just:
ORGMAIL
in the file?  If you don't, then ORGMAIL is not unset.

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

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

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

I had written:
> > > 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.
> ...


> > bash> cat /tmp/procmail.log.
> > procmail: Quota exceeded while writing "testbox"
> > procmail: Truncated file to former size
> >  Subject: test mail
> >   Folder: /var/mail/....                                                 1266
> 
> > 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
> [...]
Well, this is not very obvious, because I have to check the manual of 
procmailrc to find out about some basic workflow behaviour of procmail.
And I even have to study the descriptions of the environment variables 
(total of > 250 lines) before I get a clue on this handling mode.

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


> > User feedback and documentation should be improved,
> 
> Please provide suggestions as to what wording in the logfile would have made
> it more clear?
Instead of just reporting the actual output file:
  Folder: /var/mail/....                                                 1266
the logfile should clearly indicate that this was a fallback situation, 
like:
procmail: Truncated file to former size
procmail: Redirecting to system folder as a replacement


> Even without asking on the mailinglist, the logfile
> should have made clear what happened.
Maybe, once you look at it. You don't normally do that, especially as 
the manual is very terse about the logfile and doesn't mention that 
it will be in /tmp by default. In any case, there should be a clear 
error message and indication what procmail did on stderr, too.


> Same question for the manpage; in what way should we rephrase it?
The mail delivery strategy, as well as (at least the names of all) the 
options and settings that can modify it, should be clearly described 
in a paragraph of the initial DESCRIPTION section already.
Currently, it's:
>       ... $HOME/.procmailrc.   According  to  the  processing
>       recipes in this file, 
The recipes do not include any fallback behaviour which is rather implicit.
>       the mail message that  just  arrived
>       gets  distributed into the right folder (and more).
So which are the right and, especially, which are the "more" folders?
>       If no
>       rcfile is found, or processing of the rcfile falls off the
>       end,  procmail  will  store the mail in the default system
>       mailbox.
OK, the system mailbox is mentioned, but not for the case in question.
Same in man procmailrc. All description of error handling is hidden 
deep in the description of settings that one could well assume to be 
optional.


> > ... 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.
I agree this is basically the right strategy.

> 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).
The problem here is that the user also has a lack of knowledge on 
procmail's handling of the situation. Once the manual is improved, 
and also the options to tweak the behaviour, it will be fine.


> > (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).
These variables only briefly occur in man procmail and are not described 
there. There is no hint either that man procmailrc will have to be 
studied to configure behaviour in error situations, and even there it's 
(as said above) hidden somewhere in the long list of settings.
The DESCRIPTION should clearly refer to the relevance of DEFAULT and 
ORGMAIL for proper adaptation to your specific environment, otherwise 
it's next to useless for the non-Guru, and I'm glad to be confirmed 
that I'm not the only one who couldn't easily assemble a proper 
configuration as 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.
> 
> It is not funny to walk through 17.000 Mailboxes to get
> the "lost" messages back into the $USER mailboxes.


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.


Thanks for your consideration and your request for suggestions to 
improve documentation, which I hope to have done.

Best regards,
Thomas Wolff

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

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

Hi Rob,

Am 2005-11-07 13:46:15, schrieb Rob Funk:

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

Hmmm, I have tried this, but $DEFAULT is set in the $USER configs to

    DEFAULT=$MAILDIR/.maybe_spam/

and ORGMAIL is unset.

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

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

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.

mbarsalou (having a similar problem) wrote:
> Subject: [fetchmail-users] fetchmail stopping on spam
> ...
> This is purely anecdotal, however.


This problem occurred again yesterday and I have additional evidence now:

reading message pt8...@po...:18 of 43 (1873 octets) . flushed
reading message pt8...@po...:19 of 43 (1293 octets) fetchmail: incorrect header line found while scanning headers
fetchmail: message delimiter found while scanning headers
 flushed
fetchmail: client/server protocol error while fetching from pop.kundenserver.de
fetchmail: Query status=4 (PROTOCOL)

This was with fetchmail 6.2.3 and it stopped fetching mails at this point. 
There are two additional observations to note:
* Although fetchmail said "flushed" for all the previous mails (and 
  even the affected one, actually), it did not delete them from the 
  server.
* It left the affected message in the mailbox though (or at least 
  some initial part of the headers) (domain name changed manually):

Return-Path: <OCH...@no...>
Delivery-Date: Tue, 08 Nov 2005 17:25:36 +0100
Received: from pop.kundenserver.de [212.227.15.181]
	by localhost with POP3 (fetchmail-6.2.3)
	for root@localhost (single-drop); Thu, 10 Nov 2005 00:13:00 +0100 (CET)
Received: from [83.242.73.87] (helo=host-n2-73-87.telpol.net.pl)
	by mx.kundenserver.de (node=mxeu3) with ESMTP (Nemesis),
	id 0MKqIe-1EZWHr1aO4-0001NV for th...@xx...; Tue, 08 Nov 2005 17:25:31 +0100
Received: from peternixon.net [215.199.192.160


Then I switched to fetchmail 6.2.9rc7 and it fetched all mails as it 
should do, except the affected message, on which it still reported:
fetchmail: message delimiter found while scanning headers

What still concerns me, however, is that it discarded that message 
completely and wrote no trace of it to the mailbox, so messages with 
that kind of problem (whatever it may be) can not be checked or 
analysed anymore with fetchmail.


Kind regards,
Thomas Wolff

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