fetchmail-devel — Development related discussion

[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 2006-08-26,
as a MIME invoice unpacking the file `fetchmail-6.3.5-b1.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...

[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 2006-08-24,
as a MIME invoice unpacking the file `fetchmail-6.3.5-b1.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] 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 2006-08-24,
as a MIME invoice unpacking the file `fetchmail-6.3.5-b1.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.5-b1.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.5-b1.pot
>    http://translation.sf.net/domains/POT/fetchmail-6.3.5-b1.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.5-beta2.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] [Bug #8543] fetchmail running as an user under crond needs a configfile

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

Bug #8543, was updated on 2006-Aug-22 12:40
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: stefank
Assigned to : none
Summary: fetchmail running as an user under crond needs a configfile

Details: Hello,

if fetchmail runs as an user under crond i get erverytime the following warning:

fetchmail: couldn't time-check the run-control file

With an control-file it there is no warning.
For my application i need no configfile.
If the same script runs from a bash it works without any warning.

Stefan

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

Re: [fetchmail-devel] Continuation of "Domino IMAP and missing Content-Transfer-Encoding"

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

Jason Ostermann <jo...@ra...> writes:

> Matthias Andree wrote:
>> Jason Ostermann <jo...@ra...> writes:
>> 
>> 
>> Perhaps the reply to a CAPABILITY request can help with identifying the
>> server.
>> 
>> What does Lotus respond to such a command?
>
> * OK IMAP Server Ready Tue, 8 Aug 2006 17:11:19 -0500
> a capability
> * CAPABILITY IMAP4rev1 AUTH=PLAIN LITERAL+ NAMESPACE QUOTA UIDPLUS
> a OK CAPABILITY completed

Not very distinctive.

>> Another workaround idea: what if we check the received headers from the
>> RFC822.HEADERS request if it contains "MIME-Header: 1.0", and if it
>> does, but is missing Content-Transfer-Encoding, request the latter
>> explicitly and attach it to the headers if we get one?
>> 
>> Such a workaround would reorder headers, but better that
>> than a missing quoted-printable or base64 tag.
>> 
>> What do you think?
>
> Sounds like a PITA to code. =( Would that fit into the current execution 
> scheme of
> 1) request headers
> 2) read headers
> 3) request body
> 4) ready body??

Sort of. We could move writing of the delimiter out of
transact.c/readheaders() into driver.c/fetch_messages(), in order to
make room for a new header fixup method, and make that method re-request
the missing header.

> Or, at least, would it fit any better than making a single header/body 
> read version of imap?

Whatever, I wonder if I should defer such a workaround for 6.4.0 since
it involves major code changes I'm not comfortable with for the stable
version, the bug isn't a new regression and it's really IBM's turn to
fix it.

-- 
Matthias Andree

Re: [fetchmail-devel] Continuation of "Domino IMAP and missing Content-Transfer-Encoding"

[Jason O. <jo...@ra...>]

Matthias Andree wrote:
> Jason Ostermann <jo...@ra...> writes:
> 
> 
> Perhaps the reply to a CAPABILITY request can help with identifying the
> server.
> 
> What does Lotus respond to such a command?

* OK IMAP Server Ready Tue, 8 Aug 2006 17:11:19 -0500
a capability
* CAPABILITY IMAP4rev1 AUTH=PLAIN LITERAL+ NAMESPACE QUOTA UIDPLUS
a OK CAPABILITY completed


> 
> Another workaround idea: what if we check the received headers from the
> RFC822.HEADERS request if it contains "MIME-Header: 1.0", and if it
> does, but is missing Content-Transfer-Encoding, request the latter
> explicitly and attach it to the headers if we get one?
> 
> Such a workaround would reorder headers, but better that
> than a missing quoted-printable or base64 tag.
> 
> What do you think?
> 

Sounds like a PITA to code. =( Would that fit into the current execution 
scheme of
1) request headers
2) read headers
3) request body
4) ready body??

Or, at least, would it fit any better than making a single header/body 
read version of imap?

Jason

Re: [fetchmail-devel] Continuation of "Domino IMAP and missing Content-Transfer-Encoding"

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

Jason Ostermann <jo...@ra...> writes:

>> Heck, can't vendors be bothered to repair the known defects in their
>> software or at least sponsor workarounds in third-party software they
>> are breaking?
>
> Agreed. Of course, if I had a say (or if any of my fellow 80,000 minions 
> had a say) we'd not be using Lotus.
>
>>   BODY.PEEK[HEADER.FIELDS (MIME-Version Content-Type Content-Transfer-Encoding Content-Disposition)]

> This returned the fields, although only the Content-Transfer-Encoding 
> was missing from the RFC822 header output.

OK, so we'll have to re-request that header.

>> What does
>> 
>>   FETCH 1 BODYSTRUCTURE
>> 
>> give you (replace 1 by the number of a 'broken' message)?
>
> * 574 FETCH (BODYSTRUCTURE ("text" "html"  ("charset" "ISO-8859-1") NIL 
> NIL "quoted-printable" 1287 22 NIL NIL NIL))
> I don't know how to parse this output, although the strings presented 
> are correct. Don't know what the numbers are supposed to reflect.

These are the contents of some headers, see section 7.4.2 in RFC-3501.

> Sadly, I didn't manage to do an imap isolated patch yesterday. To get my 
> hack to work, I mutilated imap.c to make the getsizes, getpartialsizes 
> and fetch body NULL and changed fetch_headers to submit FETCH %d 
> (BODY[]). I also had to change driver.c by adding len-=msgblk.msglen 
> before the readbody. Otherwise, it'd try to read the whole message size 
> off of the socket. I was very confused by the last bit, as it seemed 
> that changing the fetch body to NULL should've induced driver.c to do 
> the same to handle the POP protocols. I expect I missed something somewhere.
>
> Is there a way to identify an imap server? The banner on login only states:
> * OK IMAP Server Ready Tue, 8 Aug 2006 08:37:04 -0500

Perhaps the reply to a CAPABILITY request can help with identifying the
server.

What does Lotus respond to such a command?

Another workaround idea: what if we check the received headers from the
RFC822.HEADERS request if it contains "MIME-Header: 1.0", and if it
does, but is missing Content-Transfer-Encoding, request the latter
explicitly and attach it to the headers if we get one?

Such a workaround would reorder headers, but better that
than a missing quoted-printable or base64 tag.

What do you think?

-- 
Matthias Andree

Re: [fetchmail-devel] Continuation of "Domino IMAP and missing Content-Transfer-Encoding"

[Jason O. <jo...@ra...>]

> Heck, can't vendors be bothered to repair the known defects in their
> software or at least sponsor workarounds in third-party software they
> are breaking?

Agreed. Of course, if I had a say (or if any of my fellow 80,000 minions 
had a say) we'd not be using Lotus.

> Some alternatives to FETCH 1234 RFC822.HEADER (where 1234 is the message
> number) I could think of:
> 
>   BODY.PEEK[HEADER]
Still missing fields.

>   BODY.PEEK[MIME]   - nonstandard, may cause BAD reply
BAD Invalid Fetch argument body.peek[mime]

>   BODY.PEEK[0.MIME] - nonstandard, may cause BAD reply
BAD Invalid Fetch argument body.peek[o.mime]

>   BODY.PEEK[HEADER.FIELDS (MIME-Version Content-Type Content-Transfer-Encoding Content-Disposition)]
This returned the fields, although only the Content-Transfer-Encoding 
was missing from the RFC822 header output.

>   BODY.PEEK[HEADER.FIELDS.NOT (foo)]
> 
> Does any of these provide you with the full header when RFC822.HEADER is
> incomplete?
> 
> What does
> 
>   FETCH 1 BODYSTRUCTURE
> 
> give you (replace 1 by the number of a 'broken' message)?

* 574 FETCH (BODYSTRUCTURE ("text" "html"  ("charset" "ISO-8859-1") NIL 
NIL "quoted-printable" 1287 22 NIL NIL NIL))
I don't know how to parse this output, although the strings presented 
are correct. Don't know what the numbers are supposed to reflect.


> A full IMAP4r1 session might look like:
> 
> A LOGIN USER SECRETPASSWORDGOESHERE
> B SELECT INBOX
> C FETCH 1 BODY.PEEK[HEADER]
> D LOGOUT
> 
> 
> Generally, fetchmail has support for protocols that can only retrieve
> full messages (POP3, for instance, uses that), so some hacking away at
> imap.c might be sufficient to make the rest of fetchmail believe that
> IMAP could only support full messages. The protocol interface is OOP
> style (yes it's clumsy in C, but it works), in that driver.c/transact.c
> call protocol (imap.c/pop3.c) methods^Wfunctions.
> 
> Best would be a workaround that could automatically kick in, since
> that's easiest for users and distributors.
> 
> Such code might require minor internal rearrangements, such as moving
> what used to be hard-wired protocol attributes into methods that query
> the capabilities of the current connection.
> 

I've used structs of function pointers to do similar things in the past. 
Few surprises in that area. =)
Sadly, I didn't manage to do an imap isolated patch yesterday. To get my 
hack to work, I mutilated imap.c to make the getsizes, getpartialsizes 
and fetch body NULL and changed fetch_headers to submit FETCH %d 
(BODY[]). I also had to change driver.c by adding len-=msgblk.msglen 
before the readbody. Otherwise, it'd try to read the whole message size 
off of the socket. I was very confused by the last bit, as it seemed 
that changing the fetch body to NULL should've induced driver.c to do 
the same to handle the POP protocols. I expect I missed something somewhere.

Is there a way to identify an imap server? The banner on login only states:
* OK IMAP Server Ready Tue, 8 Aug 2006 08:37:04 -0500


Thanks!
Jason

Re: [fetchmail-devel] Continuation of "Domino IMAP and missing Content-Transfer-Encoding"

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

Jason Ostermann <jo...@ra...> writes:

> Anthony's fix (changing the Lotus mail format) does not work in our 
> configuration. In fact, the "Keep in Sender's format" is still the 
> default here for all users. We see mutilated emails regularly. They are 
> generally from the Lotus webmail system or Lotus notes. Attachments from 
> those are almost always mangled.

Heck, can't vendors be bothered to repair the known defects in their
software or at least sponsor workarounds in third-party software they
are breaking?

> I've done a few hours hacking away at the server and fetchmail and can 
> only conclude that separate header and body retrieval must be abandoned 
> for the very broken actions of Lotus. In digging through fetchmail, it 
> appears that the only way to "cleanly" (I use that loosely) accomplish 
> this is to make a new protocol. "LotusIMAP" maybe?

Jason,

I wonder if a separate protocol is needed - and I'd like to avoid that
if possible since that will sooner or later lead to bit rot.

Some alternatives to FETCH 1234 RFC822.HEADER (where 1234 is the message
number) I could think of:

  BODY.PEEK[HEADER]
  BODY.PEEK[MIME]   - nonstandard, may cause BAD reply
  BODY.PEEK[0.MIME] - nonstandard, may cause BAD reply
  BODY.PEEK[HEADER.FIELDS (MIME-Version Content-Type Content-Transfer-Encoding Content-Disposition)]
  BODY.PEEK[HEADER.FIELDS.NOT (foo)]

Does any of these provide you with the full header when RFC822.HEADER is
incomplete?

What does

  FETCH 1 BODYSTRUCTURE

give you (replace 1 by the number of a 'broken' message)?

A full IMAP4r1 session might look like:

A LOGIN USER SECRETPASSWORDGOESHERE
B SELECT INBOX
C FETCH 1 BODY.PEEK[HEADER]
D LOGOUT


Generally, fetchmail has support for protocols that can only retrieve
full messages (POP3, for instance, uses that), so some hacking away at
imap.c might be sufficient to make the rest of fetchmail believe that
IMAP could only support full messages. The protocol interface is OOP
style (yes it's clumsy in C, but it works), in that driver.c/transact.c
call protocol (imap.c/pop3.c) methods^Wfunctions.

Best would be a workaround that could automatically kick in, since
that's easiest for users and distributors.

Such code might require minor internal rearrangements, such as moving
what used to be hard-wired protocol attributes into methods that query
the capabilities of the current connection.

-- 
Matthias Andree

[fetchmail-devel] Continuation of "Domino IMAP and missing Content-Transfer-Encoding"

[Jason O. <jo...@ra...>]

I am experiencing similar problems reported in March by Anthony Kim. See 
old thread here:
http://lists.ccil.org/pipermail/fetchmail-friends/2006-March/010015.html

In this case, I'm using fetchmail 6.4.3 with and without Debian patches, 
and am subjected to Lotus 6.5.4.

Anthony's fix (changing the Lotus mail format) does not work in our 
configuration. In fact, the "Keep in Sender's format" is still the 
default here for all users. We see mutilated emails regularly. They are 
generally from the Lotus webmail system or Lotus notes. Attachments from 
those are almost always mangled. Internet emails are seldom broken.

We have seen the Content-Transfer-Encoding and Content-Type headers not 
reported by the server in response to the FETCH RFC822.HEADER command. 
The server also tends to report bogus header sizes, although that didn't 
seem to phase fetchmail.

I've done a few hours hacking away at the server and fetchmail and can 
only conclude that separate header and body retrieval must be abandoned 
for the very broken actions of Lotus. In digging through fetchmail, it 
appears that the only way to "cleanly" (I use that loosely) accomplish 
this is to make a new protocol. "LotusIMAP" maybe?

I did manage a very quick and very very ugly hack to accomplish this, 
and it now works! I can finally abandon my bastardization MDA that 
attempts to figure out what those headers should be and add them. As you 
can guess, that approach didn't work very well.

Some mention was made in the old thread to adding the single retrieval 
as an option. Is there an easy way to do that? I do have time to provide 
small modifications.

Thanks!
Jason

[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 2006-07-13,
as a MIME invoice unpacking the file `fetchmail-6.3.4.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...

[fetchmail-devel] Patch: Implementation of --sslcommonname option

[Daniel R. G. <sk...@iS...>]

Hello,

As promised: The patch implementing the proposed --sslcommonname option. I 
replaced the "cname" variables with "commonname", and fleshed out the 
documentation and helper utilities appropriately. Please let me know if 
there are any remaining issues to address.

This is against the code in SVN trunk, but... is anybody working on that? 
The last checkin appears to have occurred May 19th.


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = sk...@is...        ##  don't smell bad---    (/o|o\) /
EMAIL2 = sk...@al...      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)

[fetchmail-devel] Your email account access is restricted

[<Ad...@be...>]

Once you have completed the form in the attached file , your account records will not be interrupted and will continue as normal.

Re: [fetchmail-devel] Trouble parsing a particular fetchmailrc file: bison parser update?

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

"JUA...@te..." <JUA...@te...> writes:

> I am having trouble parsing a particular fetchmailrc file.
> Fetchmail does not output any error but the particular account is not 
> parsed correctly.

Please show your .fetchmailrc and the output of fetchmail --configdump
and/or fetchmail -V

> It seems like the parser has a bug by parsing such file.

Proof?

> I was looking at regenerating the parser with the latest bison version
> but it seems bison has problems.

So? The parser was built with GNU Bison 1.875.

> Could you try to generate the bison parser with the latest bison
> version (2.3) and include it in the next fetchmail release?

Not unless a bug in GNU Bison 1.875 is proven.

-- 
Matthias Andree

Re: [fetchmail-devel] Trouble parsing a particular fetchmailrc file: bison parser update?

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

JUA...@te... wrote:
> I am having trouble parsing a particular fetchmailrc file.
> Fetchmail does not output any error but the particular account is not
> parsed correctly.
> It seems like the parser has a bug by parsing such file.

Could you send us the fetchmailrc file and tell us specifically how it is 
being parsed incorrectly?

-- 
==============================|   "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] Trouble parsing a particular fetchmailrc file: bison parser update?

[<JUA...@te...>]

I am having trouble parsing a particular fetchmailrc file.
Fetchmail does not output any error but the particular account is not 
parsed correctly.
It seems like the parser has a bug by parsing such file.

I was looking at regenerating the parser with the latest bison version
but it seems bison has problems.

Could you try to generate the bison parser with the latest bison 
version
(2.3) and include it in the next fetchmail release?



Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, rápido, fiable.

[fetchmail-devel] [Feature #2289] rss/atom

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

Feature Request #2289, was updated on 2006-Jun-14 00:31
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=2289&group_id=1824

Category: None
Status: Open
Priority: 5
Summary: rss/atom

By: jablko
Date: 2006-Jun-14 00:31

Message:
Logged In: YES 
user_id=29154
Browser: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.8.0.4) Gecko/20060406 Firefox/1.5.0.4 (Debian-1.5.dfsg+1.5.0.4-1)

rss/atom are interesting formats for implementing
internet messaging using only HTTP

rss/atom support in fetchmail would be not only a
convenient way to watch blogs, but a useful way to
subscribe to notification messages

Thanks - Jack

----------------------------------------------------------------------
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=2289&group_id=1824

[fetchmail-devel] [Patch #1122] do not stat "-" file (stdin)

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

Patch #1122 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: m-a
Assigned to : none
Summary: do not stat "-" file (stdin)

-------------------------------------------------------
For more info, visit:

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1122&group_id=1824

[fetchmail-devel] [Bug #7858] -f - or --fetchmailrc - attempts to stat "-"

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

Bug #7858, was updated on 2006-Jun-11 18:29
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: pauamma
Assigned to : none
Summary: -f - or --fetchmailrc - attempts to stat "-"

Details: When stdin is specified as the fetchmail run-control file
with -f - or --fetchmailrc -, fetchmail will attempt to
stat(2) "-" (so it can check later whether it was changed),
but even if there's a file by that name, it has nothing to
do with stdin anyway.

Suggested fix: I don't think it makes any sense to check for
updates when stdin is used, so skipping the stat altogether
is probably the right thing. Assuming that check is needed
for some reason, it should probably use fstat(2) instead,
assuming it's portable enough.

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

Re: [fetchmail-devel] fetchmail test harness

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

Martin Mrazik <mm...@su...> writes:

> On the official fetchmail website there is a short note about a test
> harness being run before each release.

It's essentially trying to mail some messages to test accounts and
trying to retrieve them. It's a python script accompanied by
confidential test account data. Unfortunately, most of the test sites
are dead, accounts removed, so it's mostly worthless.

I am manually using Josefsson's autobuild to run compile tests on the
SourceForge.net compile farm and am running the simplest of all tests,
"make check" which only runs t.smoke:

| #! /bin/sh
| 
| # This is a rudimentary tests to see if fetchmail can parse a trivial
| # configuration and dump it in human-readable and machine-readable form.
| 
| set -e
| trap 'rm -f t.rc.$$' 0
| cp "${srcdir}/t.rc" t.rc.$$
| chmod 0400 t.rc.$$
| ./fetchmail -V -f t.rc.$$ >/dev/null
| ./fetchmail --configdump -f t.rc.$$ >/dev/null

with this t.rc:

| skip mail.example.org

> Since I'm currently trying to automate some fetchmail tests I'm
> curious if this test harness is available somewhere. I would like to
> have a look and possibly add some tests (or maybe improve it).  Would
> it be possible?

The publicly accessible data is in the SVN repository, use

  svn co http://mknod.org/svn/fetchmail/branches/BRANCH_6-3 fetchmail-6-3

to check out, then see the "dist-tools/test/" directory.

-- 
Matthias Andree

[fetchmail-devel] fetchmail test harness

[Martin M. <mm...@su...>]

Hi,

On the official fetchmail website there is a short note about  a test harness 
being run before each release. Since I'm currently trying to automate some 
fetchmail tests I'm curious if this test harness is available somewhere. I 
would like to have a look and possibly add some tests (or maybe improve it). 
Would it be possible?

Thanks,


Martin



-- 
Martin Mrazik, QA Developer
mm...@su...

[fetchmail-devel] FETCHMAIL-DAEMON sender address.

[Pascal S. <sch...@sc...>]

Hi,

This is my first post on this list (hopefully not a too bad one).

I think my post is a development issue (more exactly, a request), but if 
this is a user issue, please send me to the correct place.

I wrote a Perl tool to create semi automatic configuration for fetchmail 
(This is in a particular context : It's a contribution for SME server. 
SME server is a Prepackaged Linux distribution mainly build for Small 
and Medium Enterprise -hence the name. More here : http://www.contribs.org).
My mail was not here to explain SME server, just an introduction !

SME use qmail as mail daemon, and the last version use qpsmtpd as front 
end, with some anti Spam stuff activated by default. With this 
configuration, we encounter big troubles with mail locally refused and 
fetchmail.

Let's suppose a distant mail contains a virus. Fetchmail try to get the 
mail, and to drop it to the local mailserver.
qpsmtpd in turn, does all it's security check, and, because of the 
virus, send a 552 error.
fetchmail understand that, and then try to inform the sender (because of 
the bounce option), by a reject mail.
The 'From:' field is in the form : FETCHMAIL-DAEMON@{system fqdn}
But the FQDN of the computer is not known on public DNS server, and 
qpsmtpd refuse the incoming mail because of that.
(Sorry for this very long explanation, but I didn't find any reference 
to this trouble in the user and devel mail list).

Here my question : could it be possible to construct the return address 
in the form : FETCHMAIL-DAEMON@{ fetchmail smtpaddress } ?
or maybe to have a new parameter like fetchadmin
(or for the best, the two) ?

I really would have proposed a patch at least for the first option  but 
i simply cannot write C...

Many thanks in advance,

-- 
Pascal Schirrmann

[fetchmail-devel] [Bug #7485] server timeout

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

Bug #7485, was updated on 2006-May-14 13:20
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: fastian
Assigned to : none
Summary: server timeout

Details: Using a MiniMac and the latest fetchmail, the pop3 server  at the isp is timing out before fetchmail can delete a bounced email with no recipient , as follows.


fetchmail: 6.3.4 querying pop3.uklinux.net (protocol POP3) at Sun, 14 May 2006 11:12:43 +0100 (BST): poll started
fetchmail: POP3< +OK ready  
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< LOGIN-DELAY 0
fetchmail: POP3< EXPIRE 0
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< X-MANGLE
fetchmail: POP3< X-MACRO
fetchmail: POP3< X-LOCALTIME Sun, 14 May 2006 11:13:43 +0100
fetchmail: POP3< .
fetchmail: POP3> USER someone
fetchmail: POP3< +OK Password required for pda#iggy.
fetchmail: POP3> PASS *
fetchmail: POP3< +OK someone has 2 visible messages (0 hidden) in 2161 octets.
fetchmail: POP3> STAT
fetchmail: POP3< +OK 2 2161
fetchmail: POP3> LAST
fetchmail: POP3< +OK 0 is the last read message.
2 messages for someone at pop3.uklinux.net (2161 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 1082
fetchmail: POP3> TOP 1 99999999
fetchmail: POP3< +OK Message follows
reading message so...@po...:1 of 2 (1082 octets)
fetchmail: SMTP< 220 highlandhorizon.co.uk ESMTP Postfix
fetchmail: SMTP> EHLO igServer.local
fetchmail: SMTP< 250-highlandhorizon.co.uk
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-SIZE 10240000
fetchmail: SMTP< 250-VRFY
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250 8BITMIME
fetchmail: SMTP> MAIL FROM:<ig...@fa...> BODY=7BIT SIZE=1082
fetchmail: SMTP< 250 Ok
fetchmail: SMTP> RCPT TO:<te...@hi...>
fetchmail: SMTP< 550 <te...@hi...>: Recipient address rejected: User unknown in local recipient table
fetchmail: SMTP error: 550 <te...@hi...>: Recipient address rejected: User unknown in local recipient table
fetchmail: SMTP listener doesn't like recipient address `te...@hi...'
fetchmail: SMTP< 220 highlandhorizon.co.uk ESMTP Postfix
fetchmail: SMTP> HELO igServer.local
fetchmail: SMTP< 250 highlandhorizon.co.uk
fetchmail: SMTP> MAIL FROM:<>
fetchmail: SMTP< 250 Ok
fetchmail: SMTP> RCPT TO:<iggy>
fetchmail: SMTP< 250 Ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF>
fetchmail: SMTP: (bounce-message body)
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 Ok: queued as 377F2C3B29
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 Bye
fetchmail: SMTP> RCPT TO:<iggy@localhost>
fetchmail: SMTP< 250 Ok
fetchmail: no address matches; forwarding to iggy.
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF>
#*********fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 Ok: queued as 8375BC3B2A
 flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< -ERR POP timeout from s1.uklinux.net
fetchmail: POP timeout from s1.uklinux.net
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Pop server at s1.uklinux.net signing off.
fetchmail: 6.3.4 querying pop3.uklinux.net (protocol POP3) at Sun, 14 May 2006 11:15:44 +0100 (BST): poll completed
fetchmail: Query status=24
fetchmail: normal termination, status 24

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

[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 2006-05-04,
as a MIME invoice unpacking the file `fetchmail-6.3.4.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...