fetchmail-devel — Development related discussion

Re: [fetchmail-devel] Add MAPI support to fetchmail

[Yangyan L. <yan...@gm...>]

Hi Matthias,

http://lwn.net/Articles/192409/ tells us why it's useful for FLOSS to talk
with MAPI, and OpenChange are working on two different aspects: provide
interoperability with Exchange protocols and provide a transparent
replacement to Microsoft Exchange Server with native Exchange protocols
support and direct communication with Microsoft Outlook.

Fetchmail will be able to pull mail from Exchange, as well as push mail to
Exhange, if MAPI support is added. It seems that there are few software
under linux platform which support MAPI. One I know is Evolution, which
provides MAPI support with a plugin developed by OpenChange. So it will be
useful to add MAPI support to Fetchmail.

It's not decided whether I am the chosen one of this GSoC project, and
this will be decided before April 21, 2008. However, I'd like to contribute
to  this project even if I'm not the chosen one.

Best regards

2008/4/2, Matthias Andree <mat...@gm...>:
>
> Yangyan Li schrieb:
>
> > Hi all,
> >
> > I am a student attended to join in GSoC 2008 (
> > http://code.google.com/soc/2008), and I am going join one project of
> > OpenChange (http://www.openchange.org) to add MAPI support to Fetchmail,
> > perhaps as a plugin.
> >
> > Now, I am puzzled how to add MAPI support to Fetchmail. I've found that
> > in Fetchmail there is a plugin option which allows users to use an external
> > program to establish the TCP connection. If I add MAPI support in this way,
> > I have to write an adapter to translate between MAPI and one of the
> > protocols Fetchmail supports. These is no need to change Fetchmail code in
> > this approach. However, seems the plugin option is incompatible with -f
> > option and mda option in Fetchmail.
> >
> > Are there any other approaches to add MAPI support to Fetchmail?
> >
>
> Hi Yangyan,
>
> In order to answer that question, I'd need to know which protocols, or
> directions, would MAPI support address? I'm pretty much agnostic of the
> Windows internals... So is MAPI good for:
>
> - fetchmail pulling mail from some server, as alternative to IMAP, POP3
> and thereabouts?
>
> - fetchmail pushing mail locally to some other server, as alternative to
> SMTP/LMTP or MDA?
>
> - both?
>
> I think we should then fork a branch in the repository, as a side branch
> off of BRANCH_6-3, so that the support can later be merged into a
> to-be-created 6-4 branch or onto the trunk.
>
> Best regards
>
> --
> Matthias Andree
>
> Life is what happens to you while you're busy making other plans.
>                                                -- John Lennon, 1980
>

Re: [fetchmail-devel] Add MAPI support to fetchmail

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

Yangyan Li schrieb:
> Hi all,
> 
> I am a student attended to join in GSoC 2008 
> (http://code.google.com/soc/2008), and I am going join one project of 
> OpenChange (http://www.openchange.org) to add MAPI support to Fetchmail, 
> perhaps as a plugin.
> 
> Now, I am puzzled how to add MAPI support to Fetchmail. I've found that 
> in Fetchmail there is a plugin option which allows users to use an 
> external program to establish the TCP connection. If I add MAPI support 
> in this way, I have to write an adapter to translate between MAPI and 
> one of the protocols Fetchmail supports. These is no need to change 
> Fetchmail code in this approach. However, seems the plugin option is 
> incompatible with -f option and mda option in Fetchmail.
> 
> Are there any other approaches to add MAPI support to Fetchmail?

Hi Yangyan,

In order to answer that question, I'd need to know which protocols, or 
directions, would MAPI support address? I'm pretty much agnostic of the 
Windows internals... So is MAPI good for:

- fetchmail pulling mail from some server, as alternative to IMAP, POP3 and 
thereabouts?

- fetchmail pushing mail locally to some other server, as alternative to 
SMTP/LMTP or MDA?

- both?

I think we should then fork a branch in the repository, as a side branch 
off of BRANCH_6-3, so that the support can later be merged into a 
to-be-created 6-4 branch or onto the trunk.

Best regards

-- 
Matthias Andree

Life is what happens to you while you're busy making other plans.
   						-- John Lennon, 1980

[fetchmail-devel] Add MAPI support to fetchmail

[Yangyan L. <yan...@gm...>]

Hi all,

I am a student attended to join in GSoC 2008 (
http://code.google.com/soc/2008), and I am going join one project of
OpenChange (http://www.openchange.org) to add MAPI support to Fetchmail,
perhaps as a plugin.

Now, I am puzzled how to add MAPI support to Fetchmail. I've found that in
Fetchmail there is a plugin option which allows users to use an external
program to establish the TCP connection. If I add MAPI support in this way,
I have to write an adapter to translate between MAPI and one of the
protocols Fetchmail supports. These is no need to change Fetchmail code in
this approach. However, seems the plugin option is incompatible with -f
option and mda option in Fetchmail.

Are there any other approaches to add MAPI support to Fetchmail?

Thanks!
Yangyan

Re: [fetchmail-devel] Fetchmail 6.3.8: "Invalid SSL protocol..." Error

[Stefano <fet...@po...>]

Evidently, I should have looked more closely at the latest development  
code in the repository.  The particular problem I was having does  
indeed appear to have been fixed in BRANCH_6-3 (checked it out and  
built a few hours ago).

However, is there not a chance that a similar problem will return in  
the event that the "defeat opportunistic STLS" block *is* executed?   
It seems that the only thing that was done is to avoid going through  
that block in the particular case of a required re-poll when an  
opportunistic STLS negotiation was not attempted.  Without changing  
the sslproto = "" aspect of that block, or the handling in socket.c,  
does the potential for the problem to return not remain?

Quoting Matthias Andree <mat...@gm...>:

> On Sat, 15 Mar 2008, Stefano wrote:
>
>> I recently installed Fetchmail (6.3.8) to collect my mail from various
>> accounts, so that they could be automatically filtered and sorted. Since
>> installation, I had been getting the following error whenever it polled
>> my ISP's server (POP3):
>>
>> Invalid SSL protocol '' specified, using default (SSLv23).
>>
>> This does not happen when accessing other IMAP servers, but they don't
>> support IMAP.  Given that I had added a cron job to check the accounts
>> periodically, I kept receiving messages from the cron daemon with these
>> errors; rather irritating.  Thus began my quest to track down and
>> silence the error.
>
> Well, try the attached patch and see if it helps, it's actually simpler.
>
> If the NEWS or TODO.txt parts of the patch fail, nevermind.
>
>> I had read about this problem while trying to solve it, but it didn't
>> seem to have been fixed in the latest development code, so I took a stab
>> at it.
>
> It should be fixed in the SVN repository though,
>
> http://mknod.org/svn/fetchmail/branches/BRANCH_6-3/
>
> (That's where my patch comes from.)
>
> If not, we'll check again how to fix this.
>
> Thanks a lot for your report and patch!
>
> --
> Matthias Andree
>

Re: [fetchmail-devel] Fetchmail 6.3.8: "Invalid SSL protocol..." Error

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

On Sat, 15 Mar 2008, Stefano wrote:

> I recently installed Fetchmail (6.3.8) to collect my mail from various  
> accounts, so that they could be automatically filtered and sorted. Since 
> installation, I had been getting the following error whenever it polled 
> my ISP's server (POP3):
>
> Invalid SSL protocol '' specified, using default (SSLv23).
>
> This does not happen when accessing other IMAP servers, but they don't  
> support IMAP.  Given that I had added a cron job to check the accounts  
> periodically, I kept receiving messages from the cron daemon with these  
> errors; rather irritating.  Thus began my quest to track down and  
> silence the error.

Well, try the attached patch and see if it helps, it's actually simpler.

If the NEWS or TODO.txt parts of the patch fail, nevermind.

> I had read about this problem while trying to solve it, but it didn't  
> seem to have been fixed in the latest development code, so I took a stab  
> at it.

It should be fixed in the SVN repository though,

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

(That's where my patch comes from.)

If not, we'll check again how to fix this.

Thanks a lot for your report and patch!

-- 
Matthias Andree

[fetchmail-devel] Fetchmail 6.3.8: "Invalid SSL protocol..." Error

[Stefano <fet...@po...>]

I recently installed Fetchmail (6.3.8) to collect my mail from various 
accounts, so that they could be automatically filtered and sorted. 
Since installation, I had been getting the following error whenever it 
polled my ISP's server (POP3):

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

This does not happen when accessing other IMAP servers, but they don't 
support IMAP.  Given that I had added a cron job to check the accounts 
periodically, I kept receiving messages from the cron daemon with these 
errors; rather irritating.  Thus began my quest to track down and 
silence the error.

The documentation seems to indicate that an empty SSL protocol type 
string is valid, and would cause a default negotiation. Yet I was 
getting the error despite having specified ssl23 in the run control file.

I finally tracked it down to the fact that the particular POP3 server 
they use was rejecting the CAPA command, and, upon re-poll, sslproto was 
being set to "" (line 454 or so of pop3.c).

The subsequent call to SSLOpen() (driver.c:1625 or so, if I recall) was 
generating the error, after my protocol specification had been changed 
to '', as described above.

My solution was to modify socket.c as in the attached patch.  This seems 
to me to cause the correct behaviour, and appears to be more in keeping 
with the documentation.

I apologise for being so long winded, but wanted to try giving a 
sufficient description of the problem, so that others will have an idea 
of where the error comes from in the event that the provided patch turns 
out to be total nonsense or causes other problems.

I had read about this problem while trying to solve it, but it didn't 
seem to have been fixed in the latest development code, so I took a stab 
at it.

[fetchmail-devel] [Bug #13207] fetchmailconf needs to quote mailbox names when writing file

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

Bug #13207, was updated on 2008-Feb-25 14:26
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: terry_n_brown
Assigned to : none
Summary: fetchmailconf needs to quote mailbox names when writing file

Details: Some IMAP servers have folders with spaces in their names, the Microsoft Exchange junk mail folder seems to be called
"Junk E-mail"
for example.

fetchmailconf reads quoted mailbox names from .fetchmailrc, but doesn't quote them when writing.

changing line 398 to 

         res = res + ' "%s"' % x

in version 1.52 $Revision: 4740

fixes this

Cheers -Terry


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

[fetchmail-devel] Maintainer wanted for fetchmailconf (was: Fetchmailconf)

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

Ken McLennan schrieb am 2008-01-24:

>     I'm not sure whether this list covers fetchmailconf, so please 
> forgive me if I've transgressed. I'm not even 100% sure that the problem 
> lies with fetchmailconf or whether it's an issue with python or tkinter, 
> however I'm sure there is someone here who uses fetchmailconf so I 
> thought that I'd ask.
> 
>    I use a popular Linux distro on my laptop which has a 1280 x 800 
> screen. When I flash up fetchmailconf in Expert mode (I'm writing this 
> from Windoze and I can't recall whether it's 'Expert' or 'Advanced') to 
> gain access to more settings I find that I can't get to the bottom part 
> of the form and therefore can't enter or change any settings in that 
> part of it. I've tried resizing the window (Gnome Desktop but 
> WindowMaker is the same. I assume all window managers will be) but that 
> changes the window, not the form drawn on it. Has anyone else come 
> across this problem and if so have you found a resolution?
> 
>     I know I can alter settings with my text editor, or I can use 
> fetchmailconf on my desktop and then copy the configuration files 
> across, but that's a pain in the rear and kinda defeats the purpose of 
> having the utility at all.

Hi Ken,

you're right, and even claiming fetchmailconf were only kept at back
burner would be a major exaggeration... I know virtually nothing of Tk,
so if there are magic attributes to set, someone let me know or send a
patch to make Tk add scrollbars automatically.

I'd be happy to see someone else restructure the whole UI and rewrite
that utility in a much more ergonomic and self-explaning way with a
modern toolkit, be that Gtk+, Qt, wxWidgets or perhaps something else
that is reasonably portable, and I don't mind if that then happens to be
C++, C# (if that person can help me getting C# autoconf/automake stuff
done and the possibility of excluding this from the build), Lua or Ruby
instead of Python.  Perl or shell might not be the best choice though.

If that doesn't happen before 6.4 enters release candidate status, I'll
probably drop fetchmailconf or toss it to contrib/ so as to mark it
unsupported.

Sorry, but I'm already way behind with 6.3.9, so I took the decision of
letting fetchmailconf long a go.

Volunteers to the rescue! (To coordinate efforts and avoid duplication
thereof, please use the fetchmail-devel mailing list. It's very low
traffic.)

Thanks in advance and best regards

-- 
Matthias Andree

Re: [fetchmail-devel] [PATCH] implementing max days to keep mails on imap server

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

Am Dienstag, den 15.01.2008, 21:06 +0100 schrieb PaulTT:
> > days, to be deleted, and it deletes only 1858 at a time, -not a
> > problem, indeed, maybe it's even better, not to overwhlm the imap
> > server- but it' not wanted, sigh....)
> 
> yes, the problem is in the buf size for the server's answer, MSGBUFSIZE.
> 
> is there a problem in increasing the buffer for that command? or maybe
> could it be better to send multiple times the command until it ends
> giving answers?

"until it ends giving answers" is probably not the right approach,
I'd rather split the whole transaction into smaller ones that delete
some messages.

-- 
Matthias Andree <mat...@gm...>

Re: [fetchmail-devel] [PATCH] implementing max days to keep mails on imap server

[PaulTT <pa...@gm...>]

> days, to be deleted, and it deletes only 1858 at a time, -not a
> problem, indeed, maybe it's even better, not to overwhlm the imap
> server- but it' not wanted, sigh....)

yes, the problem is in the buf size for the server's answer, MSGBUFSIZE.

is there a problem in increasing the buffer for that command? or maybe
could it be better to send multiple times the command until it ends
giving answers?



PaulTT again ;P

[fetchmail-devel] [PATCH] implementing max days to keep mails on imap server

[PaulTT <pa...@gm...>]

this patch adds the above feature to fetchmail

adding an option 'days X' in fechmailrc, it checks if there are mails
older than X days on the server (imap only), if they are older, it
deletes them.

i've got only a (small) problem: it seems to delete only 1858 messages at a time
(i've got a server here with something like 4000 msgs older than 300
days, to be deleted, and it deletes only 1858 at a time, -not a
problem, indeed, maybe it's even better, not to overwhlm the imap
server- but it' not wanted, sigh....)

thanx for the program, hoping to help

let me know, obviously, if i should make the patch niecr , thanx

PaulTT

[fetchmail-devel] [Bug #12859] 6.3.8 Query status 10

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

Bug #12859, was updated on 2008-Jan-06 14:34
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: wheeler
Assigned to : none
Summary: 6.3.8 Query status 10

Details: Connect to local smtp host fail.
Local smtp server is running and accept connections on port 25
OS OpenBSD 4.2, the same situation if compiling from sources, 6.3.2 working fine.


6.3.8 querying domain.com (protocol POP3) at Sun Jan  6 15:31:01 2008: poll started 
Jan  6 15:31:11 m02 fetchmail[27613]: Trying to connect to xx.xx.xx.xx/110...connected. 
Jan  6 15:31:11 m02 fetchmail[27613]: POP3< +OK <d3b...@do...> 
Jan  6 15:31:11 m02 fetchmail[27613]: POP3> CAPA 
Jan  6 15:31:11 m02 fetchmail[27613]: POP3< +OK Capability list follows 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< PIPELINING 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< TOP 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< USER 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< UIDL 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< . 
Jan  6 15:31:12 m02 fetchmail[27613]: m01.micromeg.eu: opportunistic upgrade to TLS failed, trying to continue. 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3> USER te...@do... 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< +OK Tell me your password. 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3> PASS * 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< +OK Welcome aboard! You have 5 messages. 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3> STAT 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< +OK 5 3686 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3> LAST 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< -ERR Sorry, the LAST command was removed in RFC1725. 
Jan  6 15:31:12 m02 fetchmail[27613]: Sorry, the LAST command was removed in RFC1725. 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3> UIDL 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< +OK ID list follows: 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< 1 2be0d4c361a1eb7ac3206036596d2d15 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< 2 e65621ce1baf2013ed59450aa1f8e299 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< 3 c2d7706ff1bd4cd02b7420209e182138 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< 4 fc504927c7bed230f15ba6cda12dc252 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< 5 0f119ea13d64f1c7069d309855805465 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< . 
Jan  6 15:31:12 m02 fetchmail[27613]: 5 messages for te...@do... at domain.com (3686 octets). 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3> LIST 1 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< +OK 1 569 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3> TOP 1 99999999 
Jan  6 15:31:12 m02 fetchmail[27613]: POP3< +OK Message follows 
Jan  6 15:31:12 m02 fetchmail[27613]: reading message te...@do...@domain.com:1 of 5 (569 octets) 
Jan  6 15:32:27 m02 fetchmail[27613]: SMTP connect to localhost failed 
Jan  6 15:32:27 m02 fetchmail[27613]: POP3> QUIT 
Jan  6 15:32:27 m02 fetchmail[27613]: POP3< Hi, 
Jan  6 15:32:27 m02 fetchmail[27613]: SMTP transaction error while fetching from te...@do...@domian.com and delivering to SMTP host localhost 
Jan  6 15:32:27 m02 fetchmail[27613]: 6.3.8 querying domain.com (protocol POP3) at Sun Jan  6 15:32:27 2008: poll completed 
Jan  6 15:32:27 m02 fetchmail[27613]: Query status=10 (SMTP) 
Jan  6 15:32:27 m02 fetchmail[27613]: normal termination, status 10 


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

Re: [fetchmail-devel] fetchmail-6.3.8 portability patches

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

Am Mittwoch, den 31.10.2007, 11:41 -0500 schrieb Peter O'Gorman:

> We built fetchmail on a number of platforms and had few issues, thank
> you!
> 
> Include the typedef for int16 in the #ifndef _AIX in smbencrypt.c
> 
> Correct check for u_int32_t in configure.ac (seems to be typedef'ed in
> namser.h on some platforms.)
> 
> In configure.ac change all CPFLAGS to CPPFLAGS, CEFLAGS to CFLAGS and
> LDEFLAGS to LDFLAGS otherwise the results of some tests (additional -L
> and -I flags) do not get used for later tests causing incorrect
> configure results. Makefile.am was also changed to reflect this.
> 
> m4/gethostbyname_r.m4 does AC_TRY_COMPILE, which unfortunately can
> pass even if there is no gethostbyname_r. Changed to AC_TRY_LINK.
> 
>  __attribute__ ((unused)) is a gccism, removed from
> libesmtp/gethostbyname.c.
> 
> In KAME/getnameinfo.c it's best to use the correct argument to
> inet_ntoa.
> 
> Patch attached, sorry if these issues have already been fixed in the
> development sources.

Hi Peter,

it was a long time since you wrote that mail, and I finally got around
to looking at your patch and merging it, it will be part of fetchmail
6.3.9 - portability work is always very welcome and much appreciated.

I had to add a NULL define for FreeBSD 6.2 to run the get*info() test
properly (it appears sys/types.h is insufficient on that OS), and I have
also needed to add an AC_DEFINE for HAVE_GETNAMEINFO).

Thanks a lot for your patch.

Best regards
Matthias

Re: [fetchmail-devel] please help from multiple mails

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

On Dec 21, 2007 5:56 AM, jaspal singla <ja...@te...> wrote:
> Thanks, for the response But the problem is that I have found 3
> Delivered To: address The pattern is like that:

Please, go and read my initial reply again.  It contains the answer to
this problem, as does the man page.

If you want further help, subscribe to fetchmail-users and supply the
information I requested in my initial reply.  This subject is
off-topic for this list and I will no longer reply here.

-- 
                 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] please help from multiple mails

[jaspal s. <ja...@te...>]

Thanks, for the response But the problem is that I have found 3
Delivered To: address The pattern is like that:

_________________________________________________________________________
Return-Path: <fpl...@ho...>
Delivered-To: exa...@ex...
>From fpl...@ho... Fri Dec 21 05:33:07 2007
Return-Path: <fpl...@ho...>
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on 
	latte-filter06.cybercon.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 
	autolearn=unavailable version=3.1.1
Delivered-To: exa...@ex...
Received: (qmail 12923 invoked by uid 89); 21 Dec 2007 05:33:07 -0000
Delivered-To: ha...@ex...
Received: (qmail 12919 invoked by uid 89); 21 Dec 2007 05:33:07 -0000
Received: by simscan 1.1.0 ppid: 12914, pid: 12915, t: 0.3113s
         scanners: attach: 1.1.0 clamav: 0.88/m:36/d:1351 spam: 3.1.1
Received: from unknown (HELO latte-mx01.cybercon.com) (192.168.167.10)
  by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Dec 2007 05:33:06 -0000
Received: (qmail 4451 invoked by uid 89); 21 Dec 2007 05:33:01 -0000
Received: by simscan 1.1.0 ppid: 4440, pid: 4443, t: 0.5224s
         scanners: attach: 1.1.0 clamav: 0.88/m:36/d:1351 spam: 3.1.1
Received: from unknown (HELO remote-station.example.com) (69.95.50.181)
  by 0 with SMTP; 21 Dec 2007 05:33:01 -0000
Message-ID: <001c01c84369$14afed00$0ba7c700@remotestation>
From: "Rowena Baca" <fpl...@ho...>
To: ha...@ex...
Subject: Changing careers but lack the right  Degree?
Date: Fri, 21 Dec 2007 00:33:17 -0500
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869

______________________________________________________________________

Where, test is the pop-ID;harleen is the localuser.

There is 3 Delivered To: But I want to skip the first two Deliverd To:.
I want to take delivered To: from the localuser name(harleen) not from
the pop-ID(test).

My fetchmailrc are as:

________________________________________________________________________

 
set postmaster "postmaster"
set nobouncemail
set
properties"Delivered-To:bou...@bo..."

poll example.com with proto POP3
        no dns, aka example.com
        envelope "Delivered-To:" 
        user te...@ex... is * here
        password test
forcecr
smtphost        localhost
smtpaddress     example.com
dropdelivered

But. I am still getting multiple mails.Please, suggest some good
solution.

On Thu, 2007-12-20 at 20:12 +0000, Rob MacGregor wrote:
> Note - this would be far more relevant to the fetchmail-users list as
> it isn't related to the development of fetchmail.
> 
> On Dec 20, 2007 7:16 PM, Jaspal Singhal <ja...@te...> wrote:
> > Dear All,
> >
> > I am using fetchmail for downloading mails from other server.But the
> > problem I have faced is that :
> >
> > 1)When someone send mails to 2 or 3 people then on local mailserver every
> > user get or three mails depending on the mails in To or cc field.
> 
> When you follow up to the fetchmail-users list, be sure to provide:
> 
> 1) Version of fetchmail (if not already 6.3.8 then upgrade to 6.3.8)
> 2) Contents of .fetchmailrc
> 3) Output of "fetchmail --nosyslog --nodetach -vvv" for a problem email
> 
> I suspect however that you'll find that solving your second problem
> will make this vanish.
> 
> > 2) whe someone send mails to 2 or 3 users then in every mail headers I
> > have found 2 or 3 Delivered To: address but, only last Delivered To:
> > address is useful for me.Is that possible to take Delivered To: address
> > from the third one .Please, do needful I have got lots of problem
> > regarding this.
> 
> Yes - see the man page for the "envelope" option.  In your case you would use:
> 
> envelope Delivered-to 2
> 

Re: [fetchmail-devel] please help from multiple mails

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

Note - this would be far more relevant to the fetchmail-users list as
it isn't related to the development of fetchmail.

On Dec 20, 2007 7:16 PM, Jaspal Singhal <ja...@te...> wrote:
> Dear All,
>
> I am using fetchmail for downloading mails from other server.But the
> problem I have faced is that :
>
> 1)When someone send mails to 2 or 3 people then on local mailserver every
> user get or three mails depending on the mails in To or cc field.

When you follow up to the fetchmail-users list, be sure to provide:

1) Version of fetchmail (if not already 6.3.8 then upgrade to 6.3.8)
2) Contents of .fetchmailrc
3) Output of "fetchmail --nosyslog --nodetach -vvv" for a problem email

I suspect however that you'll find that solving your second problem
will make this vanish.

> 2) whe someone send mails to 2 or 3 users then in every mail headers I
> have found 2 or 3 Delivered To: address but, only last Delivered To:
> address is useful for me.Is that possible to take Delivered To: address
> from the third one .Please, do needful I have got lots of problem
> regarding this.

Yes - see the man page for the "envelope" option.  In your case you would use:

envelope Delivered-to 2

-- 
                 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] please help from multiple mails

[Jaspal S. <ja...@te...>]

Dear All,

I am using fetchmail for downloading mails from other server.But the
problem I have faced is that :

1)When someone send mails to 2 or 3 people then on local mailserver every
user get or three mails depending on the mails in To or cc field.

2) whe someone send mails to 2 or 3 users then in every mail headers I
have found 2 or 3 Delivered To: address but, only last Delivered To:
address is useful for me.Is that possible to take Delivered To: address
from the third one .Please, do needful I have got lots of problem
regarding this.


 jaspal singla
 Linux Engineer
 Tetra Information Services Pvt. Ltd.
 136, Lower Ground Floor, Sant Nagar.
 East of Kailash.
 New Delhi - 110065

 Phone : +91-11-66604033\ 34\ 35
 Fax   : +91-11-41620171

 Mumbai Office: mu...@te...
 Mobile : +91-9891065037

 Website : www.tetrain.com, www.linux4e.com


 "We Create and Manage Comprehensive Technology Solutions Scalable to your
needs"

Re: [fetchmail-devel] populate .fetchids

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

Am Donnerstag, den 15.11.2007, 22:19 +0100 schrieb Daniel Goering:
> Hi!
> 
> As I didn't find any hints on how to do this, I guess I have a feature
> request:
> 
> For people starting to use fetchmail -- like me -- it would be nice, if
> one could create the ~/.fetchids file from the mails currently on the
> server, without actually downloading all the mails.
> Otherwise you might end up redownloading thousands of messages just
> because you changed your retrival programm.

Hi Daniel,

indeed this is not in fetchmail yet, I've placed it in TODO.txt.

For the nonce, you can try to convert the UIDs from your previous
program, the .fetchids format is line-oriented (i. e. one line per UID)

login@server ID

and all different logins and servers mixed in the same .fetchids file.
Fetchmail does not expect a certain order, and there's a space (ASCII
code 0x20 hex/040 octal/32 decimal) between server and ID.

This is going to change in a later version, but not in 6.3.X.

HTH

Best regards
Matthias

[fetchmail-devel] populate .fetchids

[Daniel G. <g_d...@gm...>]

Hi!

As I didn't find any hints on how to do this, I guess I have a feature
request:

For people starting to use fetchmail -- like me -- it would be nice, if
one could create the ~/.fetchids file from the mails currently on the
server, without actually downloading all the mails.
Otherwise you might end up redownloading thousands of messages just
because you changed your retrival programm.

Cheers,
	Daniel

[fetchmail-devel] fetchmail-6.3.8 portability patches

[Peter O'G. <fet...@ml...>]

Hi,

We built fetchmail on a number of platforms and had few issues, thank
you!

Include the typedef for int16 in the #ifndef _AIX in smbencrypt.c

Correct check for u_int32_t in configure.ac (seems to be typedef'ed in
namser.h on some platforms.)

In configure.ac change all CPFLAGS to CPPFLAGS, CEFLAGS to CFLAGS and
LDEFLAGS to LDFLAGS otherwise the results of some tests (additional -L
and -I flags) do not get used for later tests causing incorrect
configure results. Makefile.am was also changed to reflect this.

m4/gethostbyname_r.m4 does AC_TRY_COMPILE, which unfortunately can
pass even if there is no gethostbyname_r. Changed to AC_TRY_LINK.

 __attribute__ ((unused)) is a gccism, removed from
libesmtp/gethostbyname.c.

In KAME/getnameinfo.c it's best to use the correct argument to
inet_ntoa.

Patch attached, sorry if these issues have already been fixed in the
development sources.

Peter

Re: [fetchmail-devel] broken behavior in Exchange Server 2003 IMAP4rev1

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

Sorry, this message was meant to be public. Resending to list, Adam - sorry for the dupe.

Am Sonntag, den 04.11.2007, 12:26 -0800 schrieb Adam Simpkins:

> If I have the time later, I might create a patch for this on my own.
> Would you consider accepting the patch if I came up with one?  It
> looks like I should probably just create a new method struct identical
> to the current "imap" one, but with a single fetch method that gets
> everthing, and fetch_body set to NULL.  Is that the preferred
> approach, or did you have something else in mind?

I will consider the patch, yes.

I think an command line option to switch existing IMAP behavior to
"fetch whole message" is more useful, in order to avoid code duplication
and user irritation at configuration time.

It's already _very_ confusing to have APOP and KPOP as "protocols" when
they are in fact just authentication variants of POP3. Let's not add to
that for IMAP.

New options need to be added to the manpage, the lexer and parser
(the .l and .y files) and to options.c.

-- 
Matthias Andree <mat...@gm...>

Re: [fetchmail-devel] broken behavior in Exchange Server 2003 IMAP4rev1

[Adam S. <sim...@ci...>]

On Fri, Nov 02, 2007 at 05:58:31PM +0100, Matthias Andree wrote:
> Am Donnerstag, den 01.11.2007, 18:06 -0700 schrieb Adam Simpkins:
> 
> > I tracked down the problem, and it occurs because the Exchange server
> > is rewriting the MIME boundary before sending it to the IMAP client.
> 
> So tell Exchange not to do that.
> Why would a client want to cater for servers who tamper with data? It's
> the MIME boundary today and the sender address tomorrow. And why would a
> client want to use such a server at all?

Yes, I agree Exchange is broken here.  Unfortunately, I don't have any
control over the mail server.  I have contacted my IT support contacts
about this problem with the server, but I haven't heard anything back
from them yet.  (And I don't have high hopes that they'll be willing
or able to fix this problem anyway.)


> [bug fixing for Lotus insanity transferred to MS Exchange?]
> > I don't suppose I can convince you to reconsider?  (I somehow doubt
> > I'll have much luck convincing Microsoft to fix exchange.)
> 
> Well, if I had time at my hands, I might offer to fix this for money.
> Given that 6.3.9 has been delayed for weeks already, I'd rather not make
> any offers in that direction.
> 
> I'm aware this isn't too helpful, but I don't see it as my foremost
> interest to work around server bugs - especially not if the changes to
> code would have to be rather intrusive.

Sure, I completely understand.  I've switched to POP3 for now, which
shouldn't have the problem.

If I have the time later, I might create a patch for this on my own.
Would you consider accepting the patch if I came up with one?  It
looks like I should probably just create a new method struct identical
to the current "imap" one, but with a single fetch method that gets
everthing, and fetch_body set to NULL.  Is that the preferred
approach, or did you have something else in mind?

-- 
Adam Simpkins
sim...@ci...

Re: [fetchmail-devel] broken behavior in Exchange Server 2003 IMAP4rev1

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

Am Donnerstag, den 01.11.2007, 18:06 -0700 schrieb Adam Simpkins:

> I tracked down the problem, and it occurs because the Exchange server
> is rewriting the MIME boundary before sending it to the IMAP client.

So tell Exchange not to do that.
Why would a client want to cater for servers who tamper with data? It's
the MIME boundary today and the sender address tomorrow. And why would a
client want to use such a server at all?

> It rewrites the boundary differently (using a different randomly
> generated string) for each IMAP request.  Because fetchmail downloads
> the headers and body separately, this results in a different boundary
> in the Content-Type header than in the message body.

...

[bug fixing for Lotus insanity transferred to MS Exchange?]
> I don't suppose I can convince you to reconsider?  (I somehow doubt
> I'll have much luck convincing Microsoft to fix exchange.)

Well, if I had time at my hands, I might offer to fix this for money.
Given that 6.3.9 has been delayed for weeks already, I'd rather not make
any offers in that direction.

I'm aware this isn't too helpful, but I don't see it as my foremost
interest to work around server bugs - especially not if the changes to
code would have to be rather intrusive.

Sorry.

Best regards
Matthias

Re: [fetchmail-devel] broken behavior in Exchange Server 2003 IMAP4rev1

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

On 11/2/07, Adam Simpkins <sim...@ci...> wrote:
> Hi,
<---SNIP--->>
> I tracked down the problem, and it occurs because the Exchange server
> is rewriting the MIME boundary before sending it to the IMAP client.
> It rewrites the boundary differently (using a different randomly
> generated string) for each IMAP request.  Because fetchmail downloads
> the headers and body separately, this results in a different boundary
> in the Content-Type header than in the message body.
<---SNIP--->
> In case it helps, my IMAP server reports itself as:
>   Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1

Can you use POP instead, and if so does it have the same bug?

I'd personally suggest filing a bug with Microsoft.  Re-writing emails
like that probably runs the risk of breaking digitally signed emails
that include headers (DKIM springs to mind, though I suspect it
doesn't sign that header by default).  Of course, I'd expect the
answer to be "Upgrade to the latest version" :)

-- 
                 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] broken behavior in Exchange Server 2003 IMAP4rev1

[Adam S. <sim...@ci...>]

Hi,

I use fetchmail to grab my mail over IMAP from an Exchange server.
I've noticed that a number of multipart MIME messages become broken
after being downloaded by fetchmail.  The messages look fine when I
point my mail client directly at the IMAP server.  However, once
they've been downloaded by fetchmail, the boundary used in the message
body doesn't match the one in the Content-Type header.

I tracked down the problem, and it occurs because the Exchange server
is rewriting the MIME boundary before sending it to the IMAP client.
It rewrites the boundary differently (using a different randomly
generated string) for each IMAP request.  Because fetchmail downloads
the headers and body separately, this results in a different boundary
in the Content-Type header than in the message body.

This only happens for messages with a Content-Transfer-Encoding of
"binary".  Messages with a transfer encoding of "7bit" and "8bit" seem
to work just fine.


This looks like the same problem described with Lotus Domino 5 servers
in section X6 of the FAQ.  This message seems to indicate that you are
reluctant to modify fetchmail to work around this broken behavior:

  http://lists.berlios.de/pipermail/fetchmail-devel/2006-August/000760.html

I don't suppose I can convince you to reconsider?  (I somehow doubt
I'll have much luck convincing Microsoft to fix exchange.)


In case it helps, my IMAP server reports itself as:
  Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1

-- 
Adam Simpkins