fetchmail-devel — Development related discussion

Re: [fetchmail-devel] name fix

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

Rob Funk schrieb:
> Yeah, this could be considered a vanity patch, but it's only been lately 
> that I've noticed my name appearing wrong in problem reports. (I somehow 
> missed when this code first went in over a year ago.)  I would've just 
> committed the fix myself, but I haven't found the current svn commit 
> access info.  (I know, I'm bad.)
> 
> So Matthias, would you mind committing this patch to the 6.3 branch?  

Hi, Rob!

Sorry -- I do not mind at all. Please accept my sincere apologies for my
misspelling your name -- I don't consider those "vanity" patches, after
all, proper credit is *the* building block to keep certain communities
(open source, scientific, ...) going.

About the mknod commit access, there have been several revisions,
the URL is svn+ssh://mknod.org/svn/fetchmail/branches/BRANCH_6-3 - and
your login should be rfunk - that's what appears in your latest commit
from 2004. In doubt, Graham Wilson maintains the SVN server and can help
with your commit access.

HTH and sorry again,
Matthias

[fetchmail-devel] name fix

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

Yeah, this could be considered a vanity patch, but it's only been lately 
that I've noticed my name appearing wrong in problem reports. (I somehow 
missed when this code first went in over a year ago.)  I would've just 
committed the fix myself, but I haven't found the current svn commit 
access info.  (I know, I'm bad.)

So Matthias, would you mind committing this patch to the 6.3 branch?  
Thanks.

-- 
==============================|   "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-devel] New Japanese PO file for `fetchmail'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A revised PO file, for programs using the textual domain `fetchmail',
has been submitted by the team of translators taking care of the
Japanese language.  This particular file, along with all other PO
files pertaining to the same textual domain, is available as:
>    http://www.iro.umontreal.ca/translation/maint/fetchmail/ja.po

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/ja.po
>    http://translation.sf.net/maint/fetchmail/ja.po

This file has already been sent to you separately on 2007-03-29,
as a MIME invoice unpacking the file `fetchmail-6.3.8-rc2.ja.po'.

The following HTML page should also be updated by tomorrow.

>    http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html

Please consider including all PO files, as they stand, in the `po/'
subdirectory of your next release of programs using that textual domain,
whether it is official or pretest.  Whenever you have a distribution ready
which holds a newer PO Template, please send the URL of this distribution
to the address below.  The distribution could be a pretest or a snapshot,
it does not even have to compile.  This is to be used by translators,
when they need to get some translation context from your sources.

Within the Translation Project, each PO Template file should have different
version numbers, but since it is not OK to have two different distributions
using same version numbers, this is not a problem in practice.

Contact me if any question arises.  Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

[fetchmail-devel] [PATCH] fix segfault in sink.c if fopen returns NULL

[Nico G. <ni...@ng...>]

Hi,
the attached patch fixes #416625 in Debian.
Kind regards
Nico

-- 
Nico Golde - http://www.ngolde.de
JAB: ni...@ja... - GPG: 0x73647CFF
Forget about that mouse with 3/4/5 buttons,
gimme a keyboard with 103/104/105 keys!

[fetchmail-devel] New Russian PO file for `fetchmail'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A revised PO file, for programs using the textual domain `fetchmail',
has been submitted by the team of translators taking care of the
Russian language.  This particular file, along with all other PO files
pertaining to the same textual domain, is available as:
>    http://www.iro.umontreal.ca/translation/maint/fetchmail/ru.po

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/ru.po
>    http://translation.sf.net/maint/fetchmail/ru.po

This file has already been sent to you separately on 2007-03-26,
as a MIME invoice unpacking the file `fetchmail-6.3.8-rc2.ru.po'.

The following HTML page should also be updated by tomorrow.

>    http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html

Please consider including all PO files, as they stand, in the `po/'
subdirectory of your next release of programs using that textual domain,
whether it is official or pretest.  Whenever you have a distribution ready
which holds a newer PO Template, please send the URL of this distribution
to the address below.  The distribution could be a pretest or a snapshot,
it does not even have to compile.  This is to be used by translators,
when they need to get some translation context from your sources.

Within the Translation Project, each PO Template file should have different
version numbers, but since it is not OK to have two different distributions
using same version numbers, this is not a problem in practice.

Contact me if any question arises.  Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

[fetchmail-devel] New Polish PO file for `fetchmail'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A revised PO file, for programs using the textual domain `fetchmail',
has been submitted by the team of translators taking care of the
Polish language.  This particular file, along with all other PO files
pertaining to the same textual domain, is available as:
>    http://www.iro.umontreal.ca/translation/maint/fetchmail/pl.po

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/pl.po
>    http://translation.sf.net/maint/fetchmail/pl.po

This file has already been sent to you separately on 2007-03-26,
as a MIME invoice unpacking the file `fetchmail-6.3.8-rc2.pl.po'.

The following HTML page should also be updated by tomorrow.

>    http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html

Please consider including all PO files, as they stand, in the `po/'
subdirectory of your next release of programs using that textual domain,
whether it is official or pretest.  Whenever you have a distribution ready
which holds a newer PO Template, please send the URL of this distribution
to the address below.  The distribution could be a pretest or a snapshot,
it does not even have to compile.  This is to be used by translators,
when they need to get some translation context from your sources.

Within the Translation Project, each PO Template file should have different
version numbers, but since it is not OK to have two different distributions
using same version numbers, this is not a problem in practice.

Contact me if any question arises.  Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

[fetchmail-devel] New PO Template file for `fetchmail'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A new PO Template file, for programs using the textual domain
`fetchmail', has just been made available to language teams for
translation, and a copy is available as:
>    http://www.iro.umontreal.ca/translation/domains/POT/fetchmail-6.3.8-rc2.pot

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/domains/POT/fetchmail-6.3.8-rc2.pot
>    http://translation.sf.net/domains/POT/fetchmail-6.3.8-rc2.pot


In your releases, this file is usually found as `po/fetchmail.pot'.
It is created or updated automatically at `make dist' time, or
whenever you run `make update-po' in the `po/' subdirectory.  Whenever
you have a distribution ready which holds a newer PO Template, please
send the URL of this distribution to the address below.  The
distribution could be a pretest or a snapshot, it does not even have
to compile.  This is to be used by translators, when they need to get
some translation context from your sources.

Within the Translation Project, each PO Template file should have
different version numbers, but since it is not OK to have two
different distributions having same version numbers, this is not a
problem in practice.
Here is the URL information which has just been provided to translators for
your package.  Please inform the translation coordinator, at the address
given below, if the information does not appear to be adequate or current:

>    http://home.pages.de/~mandree/fetchmail/fetchmail-6.3.8-rc2.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

Re: [fetchmail-devel] Security vulnerability in APOP authentication

[<gae...@en...>]

Matthias Andree wrote on 19 Mar 2007 23:38:58 +0100:

> BTW, do you have or are you aware of a MITRE CVE Id to track this
> protocol weakness?

No.  Actually, I had never head about MITRE CVE until I read you
mail...

If I understood correctly how it works, the best thing to do is to post
to bugtrack, which I plan to do in a few days (just giving some time for
patches to come out...  or do you think I should rather do it right
now?)

-- 
Gaëtan LEURENT

Re: [fetchmail-devel] Security vulnerability in APOP authentication

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

Gaëtan LEURENT schrieb:
> Matthias Andree wrote on 18 Mar 2007 00:03:55 +0100:
> 
>> How does this work in detail? Recover character by character? Are
>> specially-crafted challenges required to provoke weak messages in MD5,
>> if there are any?
> 
> Yes, it uses specially-crafted challenges to recover the password
> character by character.  It is not really a matter of weak messages, but
> of pair of colliding messages.

BTW, do you have or are you aware of a MITRE CVE Id to track this
protocol weakness?

Thanks,
Matthias

[fetchmail-devel] fetchmail 6.3.8-rc2 release candidate

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

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

Greetings,

I have uploaded the second fetchmail 6.3.8 release candidate to the usual
download location: <http://home.pages.de/~mandree/fetchmail/>.

This release candidates adds strict verification of the POP3 APOP
timestamp for RFC-822 syntax to make an MD5 collision attack more
difficult - details:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
fetchmail 6.3.8 (not yet released) - CHANGES IN RC2 SINCE RC1

# SECURITY STRENGTHENING:
* Make the APOP challenge parser more distrustful and have it reject challenges
  that do not conform to RFC-822 msg-id format, in the hope to make mounting
  man-in-the-middle attacks (MITM) against APOP a bit more difficult.

  APOP is claimed insecure by Gaëtan Leurent for MITM scenarios for typical
  setups: based on MD5 collisions, it is purportedly possible to recover the
  first three characters of the shared secret (password), which would then make
  recovery of the shared secret a matter of hours or minutes; this would then
  enable the attacker to impersonate the client vis-à-vis the server.

  For further details, check
  * Gaëtan Leurent, "Message Freedom in MD4 and MD5 Collisions: Application
  to APOP", Fast Software Encryption 2007, Luxembourg. (Proceedings to appear in
  Springer's Lecture Notes on Computer Science.)
  * The mailing list discussion thread at
  <http://lists.berlios.de/pipermail/fetchmail-devel/2007-March/000887.html>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

WARNING: This message sets the Reply-To: header.
When replying to me personally, you need to edit the To: header!

Thank you.

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

iD8DBQFF/w9AvmGDOQUufZURAtWHAKCsM234Qe7gh8C9z1MsuH43wA4hiQCg0xOy
wrxZO6Dpj4P7XtDO4MuvzDo=
=5+Nu
-----END PGP SIGNATURE-----

Re: [fetchmail-devel] Security vulnerability in APOP authentication

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

(Mince alors, que je n'utilise pas Thunderbird pour des pièces
jointes en text. Dommage.)

"8-bit us-ascii" MIME encoding, what kind of TB brainfart is that?

*This* message should get the character encoding of the attachment
right.  Sorry for the mess.

-- 
Matthias 'mutt simply works' Andree

Re: [fetchmail-devel] Security vulnerability in APOP authentication

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

Gaëtan LEURENT schrieb:

> The idea of this attack is to create a collision, and replace a part of
> the collision with an unknown password character; therefore, if it still
> collides the chances are that the password character is the same than
> the one in the original collision.

> Well OpenSSL does something like 2^31 MD5 per hour, and 85^5 is about
> 2^32.  So you should be able to bruteforce 5 characters in 2
> hours...

Gee. I can then be friendly and use USER/PASS instead to spoil the
challenge at least :-)

>> That is certainly feasible to implement, I wonder though if that helps
>> us out for long.
> 
> Well I don't know.  That's up to you to choose if it's worth...

Let's just try it. I'm attaching a patch against 6.3.8-rc1 that
validates the timestamp according to the RFC-822 ABNF stuff and refuses
to authenticate if the timestamp isn't a valid RFC-822 msd-id token.

Yes, I hand-hacked a full(!) msg-id parser, and a few more eyeballing is
desired - let me know if you have any concerns about the new rfc822valid.c.

Thanks.

Best regards
Matthias Andree

Re: [fetchmail-devel] Security vulnerability in APOP authentication

[<gae...@en...>]

Matthias Andree wrote on 18 Mar 2007 00:03:55 +0100:

> How does this work in detail? Recover character by character? Are
> specially-crafted challenges required to provoke weak messages in MD5,
> if there are any?

Yes, it uses specially-crafted challenges to recover the password
character by character.  It is not really a matter of weak messages, but
of pair of colliding messages.

The idea of this attack is to create a collision, and replace a part of
the collision with an unknown password character; therefore, if it still
collides the chances are that the password character is the same than
the one in the original collision.

> What's the state of the MD5 cracking art WRT unknown plaintext, how big
> is the effort to brute force the 85^5 space from the 1,000 hashes thus
> collected?

Well OpenSSL does something like 2^31 MD5 per hour, and 85^5 is about
2^32.  So you should be able to bruteforce 5 characters in 2
hours...

>> However, using the current techniques available to attack MD5, the
>> msg-ids sent by the server can easily be distinguished from genuine ones
>> as they will not respect the RFC specification.
>
> How long until these colliding messages ASCII and RFC-822 message-id format

I have no idea...  I think APOP should already be considered insecure,
but as you said it is sometimes the best authentication available, so
it's better to try to make it as resistant as possible...  Anyway,
restricting the space of possible message-ids will at least make the
attack somewhat harder if it becomes possible.

>> In particular, they
>> will contain non-ASCII characters.  Therefore, as a security
>> countermeasure, I think fetchmail should reject msg-ids that does not
>> conform to the RFC.
>
> That is certainly feasible to implement, I wonder though if that helps
> us out for long.

Well I don't know.  That's up to you to choose if it's worth...

>> The details of the attack and the new results against MD5 needed to
>> build it will be presented in the Fast Software Encryption conference on
>> March 28.  I can send you some more details if needed.
>
> That would certainly be interesting - who will present the attack at the
> conference? Is the paper available for download or will it be after the
> conference?

I will present it :-)  I send you a copy of the paper.

-- 
Gaëtan LEURENT

Re: [fetchmail-devel] Security vulnerability in APOP authentication

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

Gaëtan LEURENT schrieb am 2007-03-14:

> I found a security vulnerability in the APOP authentication.  It is
> related to recent collision attacks by Wang and al. against MD5.  The
> basic idea is to craft a pair of message-ids that will collide in the
> APOP hash if the password begins in a specified way.  So the attacker
> would impersonate a POP server, and send these msg-id; the client will
> return the hash, and the attacker can learn some password characters.

Thanks for the heads-up.

The problem with APOP is that it specifies MD5, and that isn't going to
change, and with some clueless upstreams, APOP is the best you can
get...

> This attack is really a practical one: it needs about an hour of
> computation and a few hundred authentications from the client, and can
> recover three password characters.  I tested it against fetchmail, and
> it does work.

How does this work in detail? Recover character by character? Are
specially-crafted challenges required to provoke weak messages in MD5,
if there are any?

What's the state of the MD5 cracking art WRT unknown plaintext, how big
is the effort to brute force the 85^5 space from the 1,000 hashes thus
collected?

I don't know details beyond that someone has a way to produce two
messages with colliding hash with reasonably little effort.

> However, using the current techniques available to attack MD5, the
> msg-ids sent by the server can easily be distinguished from genuine ones
> as they will not respect the RFC specification.

How long until these colliding messages ASCII and RFC-822 message-id format

> In particular, they
> will contain non-ASCII characters.  Therefore, as a security
> countermeasure, I think fetchmail should reject msg-ids that does not
> conform to the RFC.

That is certainly feasible to implement, I wonder though if that helps
us out for long.

> The details of the attack and the new results against MD5 needed to
> build it will be presented in the Fast Software Encryption conference on
> March 28.  I can send you some more details if needed.

That would certainly be interesting - who will present the attack at the
conference? Is the paper available for download or will it be after the
conference?

> Meanwhile, feel free to alert any one that you believe is concerned.
> I am already sending this mail to the maintainers of Thunderbird,
> Evolution, fetchmail, and mutt.  KMail already seems to do enough checks
> on the msg-id to avoid the attack.

I think I'll be easy on this one until after I've seen the details.

Best regards,

-- 
Matthias Andree

[fetchmail-devel] fetchmail 6.3.8-rc1 release candidate

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

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

Greetings,

I have uploaded the first fetchmail 6.3.8 release candidate to the usual
download location: <http://home.pages.de/~mandree/fetchmail/>.

One more workaround was added to support repolling after failure of
opportunistic TLS upgrade - this time when the server refused
authentication.

Several parts of the documentation have been corrected and the Received:
format that fetchmail expects was documented. There is also a new
contrib/ script, delete-later.

Details:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
fetchmail 6.3.8 changes since 6.3.7:

# BUG FIXES:
* Fix pluralization of oversized-message warning mails.
* Fix manual page: --sslcheck -> --sslcertck, and do not set trailing 
  "recommended:" in bold. Fixes Debian Bug #413059, reported by Rafal Czlonka.
* Repoll immediately if a protocol error happens during the authentication 
  attempt after a failed opportunistic TLS upgrade.
  Fixes comment #9 in Gentoo Bug #163782, reported by Takuto Matsuu.
* Fix rendering of the "24 - 26, 28, 29" paragraph in the exit codes section. 
  Reported by Nico Golde.

# DOCUMENTATION:
* Extend --mda documentation, discourage use of qmail-inject.
  Based on a patch by Rob MacGregor.
* Document SOCKS configuration facility (SOCKS_CONF environment variable).
  Thanks to Jochen Hayek, Michael Shuldman and Rob MacGregor.
* Use envelope option in multidrop example. Patch by Rob MacGregor.
* Document expected Received: line format when parsing for envelope addressees.
* Stripped option documentation from sample.rcfile, since this is bound to go
  out of synch with the manual page, which is the only reference on options.

# CONTRIB:
* Add delete-later and delete-later.README, a script and documentation for
  a MySQL/Tcl-based client-side "delete-after" feature.
  Kindly donated by Yoo GmbH, Großvoigtsberg, Germany (Carsten Ralle).

# KNOWN BUGS AND WORKAROUNDS:
  (this section floats upwards through the NEWS file so it stays with the
  current release information)
* fetchmail does not handle messages without Message-ID header well
  (See sourceforge.net bug #780933)
* Sun Workshop 6 (SPARC) is known to miscompile the configuration file lexer in
  64-bit mode.  Either compile 32-bit code or use GCC to compile 64-bit
  fetchmail.  Note that fetchmail doesn't take advantage of 64-bit code,
  so compiling 32-bit SPARC code should not cause any difficulties.
* fetchmail does not track pending deletes over crashes
* the command line interface is a bit narrow-minded sometimes, for instance,
  fetchmail -s doesn't work with a running daemon
* some of the logging output is not very helpful
* some of the documentation is still not up to date
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

WARNING: This message sets the Reply-To: header.
When replying to me personally, you need to edit the To: header!

Thank you.

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

iD8DBQFF/Fq4vmGDOQUufZURAh5CAJ9eVxplbQV1HJmEo1cIFFMrPIn+bACeJPm/
0dtsJenupmlzyECQ4KNmYEI=
=qutF
-----END PGP SIGNATURE-----

[fetchmail-devel] Security vulnerability in APOP authentication

[<gae...@en...>]

Hello,

I found a security vulnerability in the APOP authentication.  It is
related to recent collision attacks by Wang and al. against MD5.  The
basic idea is to craft a pair of message-ids that will collide in the
APOP hash if the password begins in a specified way.  So the attacker
would impersonate a POP server, and send these msg-id; the client will
return the hash, and the attacker can learn some password characters.

The msg-ids will be generated from a MD5 collision: if you have two
colliding messages for MD5 "<????@????>x" and "<¿¿¿¿@¿¿¿¿>x", and the
message are of length two blocks, then you will use "<????@????>" and
"<¿¿¿¿@¿¿¿¿>" as msg-ids.  When the client computes MD5(msg-id||passwd)
with these two, it will collide if the first password character if 'x',
no matter what is next (since we are at a block boundary, and the end of
the password will be the same in the two hashs).  Therefore you can
learn the password characters one by one (actually you can only recover
three of them, due to the way MD5 collisions are computed).

This attack is really a practical one: it needs about an hour of
computation and a few hundred authentications from the client, and can
recover three password characters.  I tested it against fetchmail, and
it does work.

However, using the current techniques available to attack MD5, the
msg-ids sent by the server can easily be distinguished from genuine ones
as they will not respect the RFC specification.  In particular, they
will contain non-ASCII characters.  Therefore, as a security
countermeasure, I think fetchmail should reject msg-ids that does not
conform to the RFC.

The details of the attack and the new results against MD5 needed to
build it will be presented in the Fast Software Encryption conference on
March 28.  I can send you some more details if needed.

Meanwhile, feel free to alert any one that you believe is concerned.
I am already sending this mail to the maintainers of Thunderbird,
Evolution, fetchmail, and mutt.  KMail already seems to do enough checks
on the msg-id to avoid the attack.

Please CC me in any reply.

-- 
Gaëtan LEURENT

Re: [fetchmail-devel] Patch to the man page

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

Rob MacGregor schrieb:

> Please find attached a quick patch that:

Thank you.

> 1) Documents in the man page (rather than just the FAQ) the fact that
> socks support is a compile time option

OK, added a remark that socks provides no interfaces for run-time
configuration that fetchmail could use.

> 2) Makes use of the envelope header in the multidrop example in the
> hope that it'll encourage others to use it :)

OK

> 3) Provides advice in the MDA section that qmail-inject should be
> avoided (as per Matthias's regular comments)

Well, the issue at hand was that qmail-inject was not being given the
recipient as command-line options, but instead had to rely on parsing
the headers. This kind of abuse can happen with the sendmail interface
too. I've revised the whole --mda action based on your patch and made
the distinction between missing the %T and qmail-inject's nonstandard
interfaces clearer.

> For future features can I suggest/request that:
> 
> a) In multi-drop mode if the envelope header isn't explicitly
> specified a warning is logged ("WARNING: Multidrop mode selected but
> no envelope header specified.  This may lead to incorrectly delivered
> email")

Looks we already have this for recent 6.3.X releases.

Perhaps we could make the "no 6.2.X support" policy even stricter (and
not let users get away with "I know I have to update") for this list to
avoid discussing fixed issues like this one :-)

fetchmail.c (SVN version on branches/BRANCH_6-3):

            /*
             * can't handle multidrop mailboxes without "envelope"
             * option, this causes truckloads full of support complaints
             * "all mail forwarded to postmaster"
             */
            if (MULTIDROP(ctl) && !ctl->server.envelope)
            {
                report(stderr, GT_("warning: multidrop for %s requires
envelope option!\n"), ctl->server.pollname);
                report(stderr, GT_("warning: Do not ask for support if
all mail goes to postmaster!\n"));
            }

> b) When the envelope header is specified, but it isn't found, a
> warning is logged and the mail is forwarded to the postmaster
> ("WARNING: Envelope header $HEADER found, cannot identify the
> recipient.  Forwarding to the postmaster")

Will consider, it's on the 6.4 TODO.txt.

THank you!

Best,
MA

[fetchmail-devel] Patch to the man page

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

Please find attached a quick patch that:

1) Documents in the man page (rather than just the FAQ) the fact that
socks support is a compile time option

2) Makes use of the envelope header in the multidrop example in the
hope that it'll encourage others to use it :)

3) Provides advice in the MDA section that qmail-inject should be
avoided (as per Matthias's regular comments)

For future features can I suggest/request that:

a) In multi-drop mode if the envelope header isn't explicitly
specified a warning is logged ("WARNING: Multidrop mode selected but
no envelope header specified.  This may lead to incorrectly delivered
email")

b) When the envelope header is specified, but it isn't found, a
warning is logged and the mail is forwarded to the postmaster
("WARNING: Envelope header $HEADER found, cannot identify the
recipient.  Forwarding to the postmaster")

-- 
                 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-devel] Bug#413059: --sslcheck - non-existent option in the man page

[Nico G. <ni...@ng...>]

tags 413059 + upstream confirmed
thanks

Hi,
* Rafal Czlonka <raf...@go...> [2007-03-01 23:52]:
> Package: fetchmail
> Version: 6.3.6-1
> Severity: normal
> 
> In the manual page a paragraph starts with:
> 
> --sslcheck  recommended:  When  connecting  to  an SSL or TLS encrypted
> [cut]
> 
> with two first words in bold. First of all there is no such option.
> Probably it was ment to be '--sshcertck'. Second of all, due to both
> being 'bold', 'recommended' looks like an variable to non-existent option.

Yes you are right, the options changed with a new upstream 
release. I forward this to fetchmail developer list.
Thanks
Nico
-- 
Nico Golde - http://www.ngolde.de
JAB: ni...@ja... - GPG: 0x73647CFF
Forget about that mouse with 3/4/5 buttons,
gimme a keyboard with 103/104/105 keys!

[fetchmail-devel] New Russian PO file for `fetchmail'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A revised PO file, for programs using the textual domain `fetchmail',
has been submitted by the team of translators taking care of the
Russian language.  This particular file, along with all other PO files
pertaining to the same textual domain, is available as:
>    http://www.iro.umontreal.ca/translation/maint/fetchmail/ru.po

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/ru.po
>    http://translation.sf.net/maint/fetchmail/ru.po

This file has already been sent to you separately on 2007-03-01,
as a MIME invoice unpacking the file `fetchmail-6.3.7.ru.po'.

The following HTML page should also be updated by tomorrow.

>    http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html

Please consider including all PO files, as they stand, in the `po/'
subdirectory of your next release of programs using that textual domain,
whether it is official or pretest.  Whenever you have a distribution ready
which holds a newer PO Template, please send the URL of this distribution
to the address below.  The distribution could be a pretest or a snapshot,
it does not even have to compile.  This is to be used by translators,
when they need to get some translation context from your sources.

Within the Translation Project, each PO Template file should have different
version numbers, but since it is not OK to have two different distributions
using same version numbers, this is not a problem in practice.

Contact me if any question arises.  Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

[fetchmail-devel] New Vietnamese PO file for `fetchmail'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A revised PO file, for programs using the textual domain `fetchmail',
has been submitted by the team of translators taking care of the
Vietnamese language.  This particular file, along with all other PO
files pertaining to the same textual domain, is available as:
>    http://www.iro.umontreal.ca/translation/maint/fetchmail/vi.po

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/vi.po
>    http://translation.sf.net/maint/fetchmail/vi.po

This file has already been sent to you separately on 2007-02-26,
as a MIME invoice unpacking the file `fetchmail-6.3.7.vi.po'.

The following HTML page should also be updated by tomorrow.

>    http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html

Please consider including all PO files, as they stand, in the `po/'
subdirectory of your next release of programs using that textual domain,
whether it is official or pretest.  Whenever you have a distribution ready
which holds a newer PO Template, please send the URL of this distribution
to the address below.  The distribution could be a pretest or a snapshot,
it does not even have to compile.  This is to be used by translators,
when they need to get some translation context from your sources.

Within the Translation Project, each PO Template file should have different
version numbers, but since it is not OK to have two different distributions
using same version numbers, this is not a problem in practice.

Contact me if any question arises.  Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

Re: [fetchmail-devel] RFC: support --smtphost for bounces

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

On Wed, 21 Feb 2007, Sunil Shetye wrote:

> Quoting from Matthias Andree's mail on Mon, Feb 19, 2007:
> > how about the attached patch to fix the "bounces are always
> > SMTP-injected to localhost without regard to the --smtphost"?
> > <http://bugs.debian.org/150137>
> > 
> > It's not perfect, and I don't know how to handle cases where --smtphost
> > contains LMTP hosts exclusively or is switched to LMTP by --lmtp -
> > suggestions?
> 
> A lot more work will be required for this.
> 
> Here I am assuming that smtphost is not localhost and requires
> authentication for relaying the bounce message. The code currently
> does not do that because localhost (by default) allows relaying of the
> bounce message without authentication.

> For using smtphost as a relay server for the bounce message, fetchmail
> will have to authenticate using esmtpname. For that, fetchmail will
> have to send EHLO, save the response, and parse it. For that, separate
> structure will have to be maintained per smtp connection. All the smtp
> variables which are currently global/static will have to be part of
> that structure.

It's not clear to me this is required at all sites (Postfix's mynetworks
and permit_mynetworks allows IP-based relaying as in "my local networks
are allowed to" out of the box), but at least esmtpname should be
supported indeed.

Perhaps the whole SMTP engine needs to be made thread-safe and reentrant
at application level so that we don't have to reimplement things as it's
now with two SMTP clients.

BTW, I've recently received a report (openSUSE) where the user complained
bitterly he lost mail after his localhost SMTP listener had refused every
SMTP command (including RSET!!!) with a 500 series code, because there
was no TLS in use and bouncing was disabled, so fetchmail just went
ahead and deleted the message.
<https://bugzilla.novell.com/show_bug.cgi?id=246829>

> There will also be a compatibility problem if the user has not
> specified any esmtpname. This is not a problem for the incoming mail
> as the mail is (presumably) being delivered locally on the smtphost.
> However, for the bounce message, authentication is a must as the
> smtphost is now going to act as a relay server. So, smtphost should be
> automatically used only if the user has specified an esmtpname.

The automatisms that are going to hide underneath such logic scare me,
we'll get dozens of "why does it not care about smtphost, I don't need
to login to SMTP" questions.

Perhaps the easiest is backing out the change and deferring the solution
to 6.4 and leave this bug in 6.3. I'm somewhat pushing forward to start
the 6.4 cycle since the 6.3 bug arrival rate has decreased and there are
some larger changes I'd like to make, and leave 6.3 for security fixes
and critical regression fixes rather sooner than later so we can make
some progress (requiring change in behavior) towards the goals, one of
them should be consistency...

Best,

-- 
Matthias Andree

Re: [fetchmail-devel] RFC: support --smtphost for bounces

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

Quoting from Matthias Andree's mail on Mon, Feb 19, 2007:
> how about the attached patch to fix the "bounces are always
> SMTP-injected to localhost without regard to the --smtphost"?
> <http://bugs.debian.org/150137>
> 
> It's not perfect, and I don't know how to handle cases where --smtphost
> contains LMTP hosts exclusively or is switched to LMTP by --lmtp -
> suggestions?

A lot more work will be required for this.

Here I am assuming that smtphost is not localhost and requires
authentication for relaying the bounce message. The code currently
does not do that because localhost (by default) allows relaying of the
bounce message without authentication.

For using smtphost as a relay server for the bounce message, fetchmail
will have to authenticate using esmtpname. For that, fetchmail will
have to send EHLO, save the response, and parse it. For that, separate
structure will have to be maintained per smtp connection. All the smtp
variables which are currently global/static will have to be part of
that structure.

There will also be a compatibility problem if the user has not
specified any esmtpname. This is not a problem for the incoming mail
as the mail is (presumably) being delivered locally on the smtphost.
However, for the bounce message, authentication is a must as the
smtphost is now going to act as a relay server. So, smtphost should be
automatically used only if the user has specified an esmtpname.

-- 
Sunil Shetye.

[fetchmail-devel] New PO Template file for `fetchmail'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A new PO Template file, for programs using the textual domain
`fetchmail', has just been made available to language teams for
translation, and a copy is available as:
>    http://www.iro.umontreal.ca/translation/domains/POT/fetchmail-6.3.7.pot

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/domains/POT/fetchmail-6.3.7.pot
>    http://translation.sf.net/domains/POT/fetchmail-6.3.7.pot


In your releases, this file is usually found as `po/fetchmail.pot'.
It is created or updated automatically at `make dist' time, or
whenever you run `make update-po' in the `po/' subdirectory.  Whenever
you have a distribution ready which holds a newer PO Template, please
send the URL of this distribution to the address below.  The
distribution could be a pretest or a snapshot, it does not even have
to compile.  This is to be used by translators, when they need to get
some translation context from your sources.

Within the Translation Project, each PO Template file should have
different version numbers, but since it is not OK to have two
different distributions having same version numbers, this is not a
problem in practice.
Here is the URL information which has just been provided to translators for
your package.  Please inform the translation coordinator, at the address
given below, if the information does not appear to be adequate or current:

>    http://home.pages.de/~mandree/fetchmail/fetchmail-6.3.7.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

[fetchmail-devel] RFC: support --smtphost for bounces

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

Hi,

how about the attached patch to fix the "bounces are always
SMTP-injected to localhost without regard to the --smtphost"?
<http://bugs.debian.org/150137>

It's not perfect, and I don't know how to handle cases where --smtphost
contains LMTP hosts exclusively or is switched to LMTP by --lmtp -
suggestions?

Thanks,

-- 
Matthias Andree