fetchmail-devel — Development related discussion

[fetchmail-devel] [patch][RFC] proper kill management of the MDA process

[<ro...@in...>]

In the past there was a discussion with subject "the message fetch should be 
completed before quitting" on the fetchmail-user mailing list. It was clear the 
possibility of delivering incomplete mail messages when fetchmail is 
interrupted during a mail dispatching process. The issue doesn't lead to a loss 
of mail but produces some garbage in the maildir/mailbox (corrupted duplicated 
messages).

The problem is related to the use of the popen() function which doesn't 
provide the PID number of the MDA process. In this way is not possible to track 
properly the MDA process, i.e. to kill it in response to a quit command issued 
to fetchmail. Using the killpg() in response to the SIGINT (or SIGTERM) signal 
doesn't help because it kills the parent process before killing the child 
process.

Here is attached a first proposal to solve the issue, it seems to work on my 
system. As I don't know the fetchmail code I'm pretty sure there are some 
mistakes. First of all I don't understand the reason in the original 
release_sink() function there is no check of the return from popen(). For this 
reason I kept the same behavior with the new implementation. I also modified 
the SIGCHLD handler to reuse the waiting procedure for the forked MDA process.

Fabio

Re: [fetchmail-devel] Telling the daemon to pull a specific mailbox now?

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

Am 01.02.2012 21:14, schrieb Johann 'Myrkraverk' Oskarsson:
> Rob MacGregor <rob...@gm...> writes:
> 
>> If you have a single daemon polling all the mailboxes, impossible. If
>> you have one daemon per mailbox, trivial (see the SIGNALS section of
>> the man page).
> 
> Not really impossible.  It's just a matter of adding some IPC mechanism
> and probably some other features that allow the command line client to
> tell the daemon which mailbox to pull.
> 
> Depending on the complexiting of the sources, this may be close to
> impossible.

IPC isn't the issue here, but sorting the command line parsing and
"which mailbox is active" stuff out is, and that work would entail
getting rid of the "no command line options permitted with running
daemon"...

I'd presume it's an effort that might easily amount to two dozen hours
for someone moderately acquainted with the sources because it requires
adaptations in multiple parts of the code.

Also, fetchmail would need to lock individual mailboxes against
concurrent access -- but instead, it locks the whole process instead,
which is another obstacle.

I suppose fetchmail 8 might follow a different model compared to all
earlier versions, more modular, which would make such code additions
easier.  I haven't yet made a real plan, as fetchmail 7 would have to
happen first (with less radical changes), yet real life has gotten in
the way of things again.

> I suppose it's rarely needed so I don't think it's worth much efford; as
> it's quite easy to have a different daemon per mailbox.

Plus you can stop the daemon, run fetchmail with "-d0" option (to defeat
the daemon mode) + the server's name (from the "poll" option) on the
command line, and then restart the original daemon.

No big deal from the command line, quite a big deal in code adaptation.

Best regards

Re: [fetchmail-devel] Telling the daemon to pull a specific mailbox now?

[Johann 'M. O. <myr...@ai...>]

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

> If you have a single daemon polling all the mailboxes, impossible. If
> you have one daemon per mailbox, trivial (see the SIGNALS section of
> the man page).

Not really impossible.  It's just a matter of adding some IPC mechanism
and probably some other features that allow the command line client to
tell the daemon which mailbox to pull.

Depending on the complexiting of the sources, this may be close to
impossible.

I suppose it's rarely needed so I don't think it's worth much efford; as
it's quite easy to have a different daemon per mailbox.


Have fun,

Johann

Re: [fetchmail-devel] Telling the daemon to pull a specific mailbox now?

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

On Wed, Feb 1, 2012 at 18:24, Johann 'Myrkraverk' Oskarsson
<myr...@ai...> wrote:
> Hi all,
>
> Is it possible to add the possibility to tell the daemon to pull one
> specific mailbox now, and leave the rest until next scheduled pull?
>
> That is, where is the difficulty on the range "trivial" to "almost
> impossible?"

If you have a single daemon polling all the mailboxes, impossible. If
you have one daemon per mailbox, trivial (see the SIGNALS section of
the man page).

-- 
                 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-devel] Telling the daemon to pull a specific mailbox now?

[Johann 'M. O. <myr...@ai...>]

Hi all,

Is it possible to add the possibility to tell the daemon to pull one
specific mailbox now, and leave the rest until next scheduled pull?

That is, where is the difficulty on the range "trivial" to "almost
impossible?"


Johann

[fetchmail-devel] New Swedish PO file for 'fetchmail' (version 6.3.20-rc3)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/sv.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] [Bug #18447] SMTP< 530 Authentication required

[<ad...@be...>]

Bug #18447, was updated on 2011-Dec-15 07:19
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Submitted by: prasad
Assigned to : none
Summary: SMTP< 530 Authentication required

Details: Hello fetchmail developer team

I have a FC8 Sendmail server on the local intranet. Before I anabled anti-relaying on my server fetchmail was working fine. Now I required smtp authentication. I have enabled saslauthd service. Now I m getting 
an error ( fetchmail SMTP< 530 Authentication required )  while fetching the emails from remote server to local server. Fetchmail retrieves the email form the ISP pop server but it is not delivaring to local server it is giving above mentioned error. 

Please help me inthis matter.



Follow-Ups:

Date: 2011-Dec-15 22:25
By: m-a

Comment:
This is not a bug, but an operator error. Please:

1. update to a supported version of Fedora Core. I don't care about unsupported versions, and chances are your FC8 is vulnerable to various flaws.

2. read the manual page. Current versions of fetchmail support this:

   ESMTP AUTH
       fetchmail  also  supports  authentication  to  the  ESMTP server on the
       client side according to RFC 2554.  You  can  specify  a  name/password
       pair  to be used with the keywords 'esmtpname' and 'esmtppassword'; the
       former defaults to the username of the calling user.

Details: man fetchmail
-------------------------------------------------------

For detailed info, follow this link:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=18447&group_id=1824

[fetchmail-devel] [Bug #18447] SMTP< 530 Authentication required

[<ad...@be...>]

Bug #18447, was updated on 2011-Dec-14 21:19
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: prasad
Assigned to : none
Summary: SMTP< 530 Authentication required

Details: Hello fetchmail developer team

I have a FC8 Sendmail server on the local intranet. Before I anabled anti-relaying on my server fetchmail was working fine. Now I required smtp authentication. I have enabled saslauthd service. Now I m getting 
an error ( fetchmail SMTP< 530 Authentication required )  while fetching the emails from remote server to local server. Fetchmail retrieves the email form the ISP pop server but it is not delivaring to local server it is giving above mentioned error. 

Please help me inthis matter.



For detailed info, follow this link:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=18447&group_id=1824

Re: [fetchmail-devel] Add feature: add header to messages?

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

Am 22.11.2011 03:42, schrieb Jonathan Kamens:

>> Yes, you're wrong - luckily ;-) The MDA setting is a user-specific
>> setting, so you can generate a modified rcfile that uses a distinct mda
>> script (or arguments) for each user.  Now, that's for the easy case
>> where you have one destination address per upstream account.  It won't
>> work with --mda on the command line though.

> The problem with this approach, if I am understanding what you are
> saying correctly, is that we have multiple remote mailboxes /being
> delivered to the same local user account./ If the MDA setting were
> specific to the remote account being queried that would work fine, but
> if it's specific to the local account, it's problematic.

Well, "user" is as opposed to "server", and was referring to fetchmail
rcfile syntax.  What I actually mean is that it's specific to the
upstream server's user, or account.

You should be able to go about something like (untested fragment!):

#------------------------------------------
# one server with two accounts to be polled
poll someserver.example.org proto pop3 uidl
user john pass 123 is joe.sixpack mda "/my/fancy/script john" ssl
user jack pass 456 is joe.sixpack here mda "/my/fancy/script jack" ssl
#...

poll otherimaptoaster.example proto imap
user joe pass "really@ strange!password" is joe.sixpack here
mda "/my/fancy/script joe@other"
#------------------------------------------

Would that work for you?  All three accounts from two servers map to the
same local user, but have a distinct mda option, so I hope this meets
your needs.

> P.S. I apologize for the misleading Subject line I used to start this
> thread. When I started writing my message to the list, I was thinking in
> terms of modifying fetchmail to allow arbitrary headers to be added to
> messages before delivery, but my thinking evolved as I wrote the message
> and I obviously ended up proposing something different, but I forgot to
> go back and update the Subject. I'm not going to change the Subject line
> now, though, because that would just confuse everybody's threading. :-)

Would it really?  I rely on In-Reply-To: and References: headers for
threading...

But generally I'm open to provide filtering through an external command
should the need arise, possibly combined with decisions as to the
transient/permanent error or deliver or drop-silently.  I'm not sure
that it needs to be more specific like that because there are tools like
maildrop's reformail that can modify message headers.

Re: [fetchmail-devel] Add feature: add header to messages?

[Jonathan K. <ji...@ka...>]

A few minutes ago, I wrote:

> The problem with this approach, if I am understanding what you are 
> saying correctly, is that we have multiple remote mailboxes /being 
> delivered to the same local user account./ If the MDA setting were 
> specific to the remote account being queried that would work fine, but 
> if it's specific to the local account, it's problematic.
Never mind, I am an idiot. I understand now what you are saying, and 
yes, I think what you proposed will solve our problem.

Thanks again for your response.

   jik

Re: [fetchmail-devel] Add feature: add header to messages?

[Jonathan K. <ji...@ka...>]

Hi Matthias,

Thanks for the response. Comments and questions below.

On 11/21/2011 08:10 PM, Matthias Andree wrote:
>> The mailboxes receiving these messages are often BCC'd, which means that
>> the recipient address doesn't appear in To or CC. Furthermore, the mail
>> servers we're downloading from unfortunately don't insert
>> X-Delivered-To, or Received lines showing the recipient address, or
>> anything like that. In short, there's no way to tell from looking at the
>> message fed into the MDA what address it was sent to.
> And configuring a filter on the upstream server isn't possible either?
> Sounds like a rather limited service to me.
We cannot ask our users to muck around with the settings on the mail 
server. They are often technically naive or inexperienced, and we need 
to be able to make things work within our application without getting 
anything from them but the mail server's host name, protocol (IMAP or 
POP3), username, and password.

>> We could hard-code a command-line option for the custom MDA command
>> identifying the mailbox, but as far as I can tell, that fails if you've
>> got more than one account in the .fetchmailrc file, because I don't
>> believe it's possible to specify different MDA settings for different
>> accounts (am I wrong about that?).
> Yes, you're wrong - luckily ;-) The MDA setting is a user-specific
> setting, so you can generate a modified rcfile that uses a distinct mda
> script (or arguments) for each user.  Now, that's for the easy case
> where you have one destination address per upstream account.  It won't
> work with --mda on the command line though.
The problem with this approach, if I am understanding what you are 
saying correctly, is that we have multiple remote mailboxes /being 
delivered to the same local user account./ If the MDA setting were 
specific to the remote account being queried that would work fine, but 
if it's specific to the local account, it's problematic.

I suppose we could theoretically create dummy local users for the 
various remote accounts being polled, and write the RC file to "deliver" 
each remote account to a separate dummy user, but that seems awfully 
kludgy. It seems like it would be a lot cleaner to add the identifier + 
%-escape functionality I proposed. What do you think?

Thanks again,

Jonathan Kamens

P.S. I apologize for the misleading Subject line I used to start this 
thread. When I started writing my message to the list, I was thinking in 
terms of modifying fetchmail to allow arbitrary headers to be added to 
messages before delivery, but my thinking evolved as I wrote the message 
and I obviously ended up proposing something different, but I forgot to 
go back and update the Subject. I'm not going to change the Subject line 
now, though, because that would just confuse everybody's threading. :-)

Re: [fetchmail-devel] Add feature: add header to messages?

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

Am 15.11.2011 14:29, schrieb Jonathan Kamens:

> We've run into a fetchmail use case which doesn't seem to be easily
> solved with existing functionality, and I'm writing to ask (a) are we
> missing something and (b) if not, would the fetchmail maintainers
> consider accepting a patch to solve the problem?

Hi Jonathan,

if I understand you correctly, (a) would apply, but as a second line of
defence, I'm willing to consider (b).

> The mailboxes receiving these messages are often BCC'd, which means that
> the recipient address doesn't appear in To or CC. Furthermore, the mail
> servers we're downloading from unfortunately don't insert
> X-Delivered-To, or Received lines showing the recipient address, or
> anything like that. In short, there's no way to tell from looking at the
> message fed into the MDA what address it was sent to.

And configuring a filter on the upstream server isn't possible either?
Sounds like a rather limited service to me.

> We could hard-code a command-line option for the custom MDA command
> identifying the mailbox, but as far as I can tell, that fails if you've
> got more than one account in the .fetchmailrc file, because I don't
> believe it's possible to specify different MDA settings for different
> accounts (am I wrong about that?).

Yes, you're wrong - luckily ;-) The MDA setting is a user-specific
setting, so you can generate a modified rcfile that uses a distinct mda
script (or arguments) for each user.  Now, that's for the easy case
where you have one destination address per upstream account.  It won't
work with --mda on the command line though.

For more complex cases that can't be solved that way, I'd be willing to
consider patches against fetchmail's 7 alpha versions (the "master"
branch in Git), such as the proposed one.

> So, my questions are (a) is there a way I'm missing to solve this
> problem, (b) if not, and we implemented the functionality I described,
> would the maintainers take a patch, and (c) if not, is there some other
> way to solve this problem that the maintainers would suggest we
> implement instead?

I'd have to ponder a bit about (c) if the (a) doesn't help.

Hope that helps.

Best regards,
Matthias Andree

Re: [fetchmail-devel] [PATCH] fetchmail workaround for a bug in Zimbra

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

Am 19.11.2011 00:43, schrieb Mikulas Patocka:
> Hi
> 
> Zimbra occasionally returns this response:
> 
> fetchmail: IMAP> A0007 FETCH 1 RFC822.HEADER
> fetchmail: IMAP< * 1 FETCH ()
> fetchmail: IMAP< A0007 OK FETCH completed
> 
> It happens when there is a corrupted message without a header in the 
> database. (I don't know how this message could be created, I just see it 
> there).
> 
> When fetchmail encounters such resonse, it gives up and disconnects.
> 
> The attached patch changes it so that PS_TRANSIENT is returned in this 
> case and fetchmail continues to fetch following messages correctly.
> 
> Mikulas
> 
> --- imap.c_	2011-11-18 17:28:35.638698000 -0500
> +++ imap.c	2011-11-18 18:04:41.745220000 -0500
> @@ -1166,7 +1166,8 @@
>  
>  	/* try to recover for some responses */
>  	if (!strncmp(buf, "* NO", 4) ||
> -		!strncmp(buf, "* BAD", 5))
> +		!strncmp(buf, "* BAD", 5) ||
> +		strstr(buf, "FETCH ()"))
>  	{
>  	    return(PS_TRANSIENT);
>  	}

Dear Mikulas,

thanks a lot for the contribution.  I have applied the patch, currently
on the legacy_63 branch (gitorious.org), for inclusion in the next 6.3.X
release (6.3.22).  I don't currently foresee a release date, as there
aren't many, or critical, fixes since 6.3.21 yet.  A release might be a
couple of weeks out.

For 7.X and later versions, I have considered rewriting the IMAP reply
parser, but chances are that the behaviour is in violation of RFC3501
and will still need special casing/work arounds.

I'll have to check more places of the RFC than my time currently allows;
Dovecot for one returns

. FETCH 248 RFC822.HEADER
* 248 FETCH (RFC822.HEADER {0}
)

in response to a blank message which seems more useful.

Best regards
Matthias

[fetchmail-devel] Add feature: add header to messages?

[Jonathan K. <ji...@ka...>]

Hello everyone,

We've run into a fetchmail use case which doesn't seem to be easily 
solved with existing functionality, and I'm writing to ask (a) are we 
missing something and (b) if not, would the fetchmail maintainers 
consider accepting a patch to solve the problem?

In a nutshell, our custom MDA wants to see the recipient addresses of 
incoming messages; it's not there anywhere; and we can't figure out any 
scalable way to get fetchmail to provide it to the MDA.

Our .fetchmailrc fetches messages from multiple mailboxes with different 
addresses. These messages are fed into our proprietary application using 
a custom MDA script that we wrote. Our application does different things 
based on which mailbox each message is from.

The mailboxes receiving these messages are often BCC'd, which means that 
the recipient address doesn't appear in To or CC. Furthermore, the mail 
servers we're downloading from unfortunately don't insert 
X-Delivered-To, or Received lines showing the recipient address, or 
anything like that. In short, there's no way to tell from looking at the 
message fed into the MDA what address it was sent to.

We could hard-code a command-line option for the custom MDA command 
identifying the mailbox, but as far as I can tell, that fails if you've 
got more than one account in the .fetchmailrc file, because I don't 
believe it's possible to specify different MDA settings for different 
accounts (am I wrong about that?).

The idea I've come up with is to add a new "id" per-mailbox 
configuration setting to allow the user to specify an arbitrary 
identifier for the mailbox, and a "%I" command-line escape for the MDA 
settings to allow the identifier for the account from which the current 
message originated to be passed into the MDA.

So, my questions are (a) is there a way I'm missing to solve this 
problem, (b) if not, and we implemented the functionality I described, 
would the maintainers take a patch, and (c) if not, is there some other 
way to solve this problem that the maintainers would suggest we 
implement instead?

Thanks,

Jonathan Kamens

[fetchmail-devel] New Japanese PO file for 'fetchmail' (version 6.3.20-rc3)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Japanese team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/ja.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Japanese PO file for 'fetchmail' (version 6.3.20-rc3)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Japanese team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/ja.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Danish PO file for 'fetchmail' (version 6.3.20-rc3)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Danish team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/da.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: [fetchmail-devel] flaw concerning fetchmail 6.3.21 error message

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

Am 29.09.2011 21:01, schrieb Oskar Schirmer:
> Use Case:
>   fetching mail from a server using pop3s, port 995,
>   with option "ssl" given, but no sslproto explicitely
>   selected.
>   Operating System: Linux, Slackware 12.2.
>   Compiler: gcc 4.2.4
>   Pop3 Server: qmail
>   Fetchmail versions tested: 6.3.8 and 6.3.21
> 
> Problem:
>   on each invocation, fetchmail states the following
>   error message, which is superfluous:
> 
> Invalid SSL protocol '' specified, using default (SSLv23).
> 
>   [note: when giving some "sslproto xy", this message is
>    given twice, with an empty protocol name on the second line]
> 
> Reason for Symptom:
>   socket.c checks given protocol names to be one of "ssl2", "ssl3", etc,
>   but fails to check against empty string "". As it checks against
>   NULL string, though, the reason for the bug may be confusion in
>   "no protocol given" value policy internal to fetchmail sources
>   (i.e. empty string vs. null string). A better solution than the
>   one given here might resolve this policy issue, instead.

Thanks, Oskar.

That warrants investigation, but I don't see this here with recent
fetchmail versions, only with older ones.  That doesn't preclude that
there are buggy code paths triggered by a configuration I haven't yet
tested, or by your network environment (server behaviour - note qmail's
POP3 server has some bugs).

Please help me and show me how to reproduce this, according to
http://www.fetchmail.info/fetchmail-FAQ.html#G3 - note however I'll
probably not be able to look into that before next week.

Thanks again.

Best regards,
Matthias

[fetchmail-devel] flaw concerning fetchmail 6.3.21 error message

[Oskar S. <os...@sc...>]

Use Case:
  fetching mail from a server using pop3s, port 995,
  with option "ssl" given, but no sslproto explicitely
  selected.
  Operating System: Linux, Slackware 12.2.
  Compiler: gcc 4.2.4
  Pop3 Server: qmail
  Fetchmail versions tested: 6.3.8 and 6.3.21

Problem:
  on each invocation, fetchmail states the following
  error message, which is superfluous:

Invalid SSL protocol '' specified, using default (SSLv23).

  [note: when giving some "sslproto xy", this message is
   given twice, with an empty protocol name on the second line]

Reason for Symptom:
  socket.c checks given protocol names to be one of "ssl2", "ssl3", etc,
  but fails to check against empty string "". As it checks against
  NULL string, though, the reason for the bug may be confusion in
  "no protocol given" value policy internal to fetchmail sources
  (i.e. empty string vs. null string). A better solution than the
  one given here might resolve this policy issue, instead.

Solution:
  To have the bogus error message go away, check against empty string
  additionally, patch as follows:



diff -ur fetchmail-6.3.21/socket.c fetchmail-6.3.21-patch/socket.c
--- fetchmail-6.3.21/socket.c	2011-08-21 15:34:58.000000000 +0200
+++ fetchmail-6.3.21-patch/socket.c	2011-09-29 10:34:33.777407663 +0200
@@ -881,6 +881,8 @@
 			_ctx[sock] = SSL_CTX_new(TLSv1_client_method());
 		} else if (!strcasecmp("ssl23",myproto)) {
 			myproto = NULL;
+		} else if (!strcmp("",myproto)) {
+			myproto = NULL;
 		} else {
 			fprintf(stderr,GT_("Invalid SSL protocol '%s' specified, using default (SSLv23).\n"), myproto);
 			myproto = NULL;

Re: [fetchmail-devel] [patch] Small cleanups

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

Am 26.08.2011 10:13, schrieb Thomas Jarosch:
> Hello Matthias,
> 
> attached are three small patches against the "master" branch.
> 
> They just do some cleanup which came up after an
> automatic code audit with "cppcheck".

Merged with one additional fix-up, thank you.

In a function returning "void" you can't "return NULL;" but you just
"return;". :)

> Overall the code quality is pretty good :)

Perhaps according to what cppcheck believes, but you haven't really read
sink.c yet...

[fetchmail-devel] [patch] Small cleanups

[Thomas J. <tho...@in...>]

Hello Matthias,

attached are three small patches against the "master" branch.

They just do some cleanup which came up after an
automatic code audit with "cppcheck".

Overall the code quality is pretty good :)

Cheers,
Thomas

Re: [fetchmail-devel] fetchmail 7.0.0-alpha2+MAPI alpha preview release

[Jack R. <jre...@co...>]

On Aug 22, 2011, at 2:34 PM, Jack Repenning wrote:

> fetchmail-7.0.0-alpha2+MAPI.tar.xz passes basic testing (IMAP, not MAPI) on Mac OS X 10.7.1 'Lion':

24 hours and ~550 messages later, working  perfectly, not so much as a single log-whine.

-==-
Jack Repenning
Technologist
CollabNet Cloud Services
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
twitter: http://twitter.com/jrep

Re: [fetchmail-devel] fetchmail 7.0.0-alpha2+MAPI alpha preview release

[Jack R. <jre...@co...>]

fetchmail-7.0.0-alpha2+MAPI.tar.xz passes basic testing (IMAP, not MAPI) on Mac OS X 10.7.1 'Lion':

configure had no complaints I could spot
make reported a lot of SSL-related deprecation warnings, but was otherwise happy
gcc is i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
installed into /usr/local
fetches via IMAP from Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1
with config settings:
set postmaster "jrepenning"
set bouncemail
set no spambounce
set properties ""
#set logfile /Users/jrepenning/Library/Logs/fetchmail.log
set syslog
# poll option idle gives quicker fetches, 
# but doesn't survive network changes
set daemon 300
poll exchange.collab.net with protocol IMAP
       user 'jrepenning' there with password 'XXXXX'
       is 'jrepenning' here
       stripcr ssl
       mda '/usr/bin/procmail -d %T'
       fetchall





-==-
Jack Repenning
Technologist
CollabNet Cloud Services
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
twitter: http://twitter.com/jrep

[fetchmail-devel] fetchmail 6.3.21 critical fix release

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

The 6.3.21 release of fetchmail is now available at the usual locations,
including <http://developer.berlios.de/projects/fetchmail>.

The source archive is available at:
<http://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=18743>

Here are the release notes:

fetchmail-6.3.21 (released 2011-08-21, 26011 LoC):

# CRITICAL BUG FIX
* The IMAP client no longer inserts NUL bytes into the last line of a message
  when it is not closed with a LF or CRLF sequence. Reported by Antoine Levitt.
  As a side effect of the fix, and in order to avoid a full rewrite, fetchmail
  will now CRLF-terminate the last line fetched through IMAP, even if it is
  originally not terminated by LF or CRLF. This bears no relevance if your
  messages end up in mbox, but adds line termination for storages (like Maildir)
  that do not require that the last line be LF- or CRLF-terminated.

# CONTRIB/ addition
* There is a patch against fetchnews's source, contrib/rawlog.patch, that can
  log (and hexdump non-printing characters) raw socket data to a file. It proved
  useful to debug Antoine's bug described above.


By popular demand, diffs from the previous release have been omitted.

[fetchmail-devel] fetchmail 7.0.0-alpha2+MAPI alpha preview release

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

Greetings,

in an effort to get sufficient testing, I have released the next alpha
version of fetchmail 7.0.0.

This version ports the MAPI support from GSoC 2008 forward onto the
current branch and onto openchange 0.11, but is untested -- I have no
Exchange account and cannot test beyond "it compiles, with massive
warnings".  Chances are it works on 32-bit versions of Ubuntu 11.04
(natty narwhal), but chances are MAPI support does not work at all.

I need help to bring this forward.

The alpha version isn't available through BerliOS, but only from
DOWNLOAD: <http://home.pages.de/~mandree/fetchmail/>

The corresponding git tag is SNAPSHOT_7-0-0-alpha2+MAPI, the branch is
"master".

Please send feedback to fet...@li....

Happy fetches!
Matthias

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

fetchmail-7.0.0 (not yet released):

NOTE THIS IS AN ALPHA RELEASE THAT HAS NOT BEEN THOROUGHLY TESTED!

NOTE THAT THE MAPI FEATURE IS ENTIRELY UNTESTED AND UNSUPPORTED!

# MAJOR CHANGES
* The UIDL handler code is now much faster, especially noticable with lots of
  mail kept on a POP3 server. Where the 6.3.X code was of O(n^2) complexity,
  we're down to O(n log n).
  Contributed by Rainer Weikusat, MAD Partners Ltd./MSS GmbH.
* The POP3 code now always uses UIDL, except if "fetchall" is in effect.
  Fixes BerliOS Bug #16172. Fixes Debian Bug#345788.
* Fetchmail now enables SSL support by default. If this is undesired,
  ./configure --without-ssl should help.

# FEATURES ADDED
* Fetchmail can now retrieve credentials from PWMD. This needs to be enabled at
  compile-time and requires run-time configuration. See README.PWMD for details.
  Contributed by Ben Kibbey, author of libpwmd and pwmd.
* Fetchmail now supports a retrieve-error command line or rcfile option that
  takes exactly one argument, abort (default), continue or markseen.  This
  specifies the policy used by fetchmail to handle messages whose bodies
  fail to be retrieved due to server errors.  Both the continue and markseen
  options will skip the message with errors and allow the session to
  continue so that subsequent messages can be retrieved.  The markseen
  option will also mark the message with errors as seen.
  The default policy is to abort the session whenever a server error occurs.
  Contributed by Craig Brown.
* Fetchmailconf offers cram-md5 and apop authentication.
* EXPERIMENTAL/UNSUPPORTED:
  MAPI support through OpenChange. Yang-Yan Li, Google Summer of Code 2008.
  With fixes from Mojmir Svoboda.
  Ported to OpenChange 0.11 by Matthias Andree.
  May not work properly on 64-bit computers.
  Note the code requires further cleanups and fixes and has not yet been audited
  for security. Do not use as privileged user. Use at your own risk.
  If you're ready to take all these risks, ./configure --enable-MAPI is the key.

# REMOVED FEATURES
* IMAP2 protocol support was removed.
* POP2 protocol support was removed.
* RPOP (not actually a protocol, but a variant of POP3) was removed
* POP3: the uidl option has been removed. It is always on.
* POP3: LAST is no longer used. It was removed from POP3 in 1994, and it could
  cause mail loss when the connection was interrupted or if clients besides
  fetchmail polled the mailbox.
* Trio was removed, fetchmail expects reasonable stdio.h quality levels.
* Support for systems that do not conform to C89 and POSIX 2001 was removed,
  this means that BeOS, EMX, NeXTSTEP quirks are no longer worked around.
* The MX and host alias DNS lookups that fetchmail performs in multidrop mode
  have been removed. They were based on the mistaken assumption that the
  IMAP/POP3 server was also the MX server, which is rarely the case.  They have
  never supported IPv6 (including IPv6-mapped IPv4) either.
  Non-DNS based alias keywords such as "aka" remain.
* Kerberos IV support was removed.
* fetchmail no longer supports SSL v2, nor the corresponding SSL2 option to
  --sslproto. SSLv2 is insecure and had been deprecated 15 years ago. fetchmail
  will actively forbid SSLv2 negotiation by means of SSL_OP_NO_SSLv2.
  To fix Debian Bug#622054.
* A lot of outdated and/or unsafe-to-use material got dropped from contrib/.

# REGRESSION FIXES
* The mimedecode feature now properly detects multipart/mixed-type matches, so
  that quoted-printable-encoded multipart messages can get decoded.
  (Regression in 5.0.0 on 1999-03-27, as a side effect of a PGP-mimedecode fix
  attributed to Henrik Storner.)

# BUG FIXES
* The mimedecode feature failed to ship the last line of the body if it was
  encoded as quoted-printable and had a MIME soft line break in the very last
  line.  Reported by Lars Hecking in June 2011.
  Bug introduced on 1998-03-20 when the mimedecode support was added by ESR
  before release 4.4.1 through code contributed by Henrik Storner.
  Workaround for older releases: do not use mimedecode feature.
* Fetchmail now detects singly-quoted % expansions in the mda option and refuses
  to deliver for safety reasons. Fixes Debian Bug#347909.

# CHANGES
* A foreground fetchmail can now accept a few more options while another copy is
  running in the background.
* APOP is no longer a protocol, but an authentication method. In order to use
  it, use protocol POP3 auth APOP, or on the commandline, -p pop3 --auth apop.
  If no authentication method is specified, APOP is automatically tried if
  offered by the server before we resort to sending the password as clear text.