fetchmail-users — User questions and discussion

Re: [fetchmail-users] option -v not working...

[Dave P. <sd...@gm...>]

* Dave Patterson <sd...@gm...> [2006-06-28 08:58:29 +0700]:


> Let me play with a couple settings here and I'll get back
> to list. 
Ok, here it is:

set syslog DOES send status report to /var/log/mail.log, file cannot be read by
normal user, this setting cannot be overriden by command line option
--nodetach

set logfile MUST be given the full path to logfile
(/home/dave/.fetchmaillog) NOT ~/.fetchmaillog or the .fetchmailrc line
'set logfile' is ignored and status is printed to screen.  This option CAN
be overridden by the option --nodetach

'set syslog' line before 'set logfile' line in .fetchmailrc has the effect
of using 'set syslog' first, the second option ignored... (as most .rc files
are executed top to bottom in common usage)

-- 
Cheers,

  Dave 

Re: [fetchmail-users] [BUG] fetchmail daemon does not resume fetching after a network outage

[Uli Z. <ul...@ri...>]

Am 28.06.2006 um 02:46 schrieb Matthias Andree:

> While I'll certainly plug the leak (it may take until the week-end  
> though), there might still be a related MacOS X bug.  There is no  
> obligation to call freeaddrinfo() before calling getaddrinfo()  
> again, plus this function is required to be thread-safe (i. e. it  
> needs to be
> reentrant).

Well, you *can* call getaddrinfo() a second time before calling  
freeaddrinfo() first in Mac OS X without a crash or anything, and  
it's thread-safe since Mac OS X 10.2 (though not before). The only  
thing is that if you call it again with exactly the same query data  
and without calling freeaddrinfo() in between, it will report the  
data it cached from the last call. You might call this a bug, but  
Apple most probably will call it a feature ... Note that on Mac OS X,  
getaddrinfo() is nothing more than a wrapper around the system's so- 
called "lookupd" daemon, which handles all network addressing issues  
with code that's completely different from all other Unix  
implementations.

> However, you say that the problems happen after a certain...
>
>> In my test case, getaddrinfo() may need up to 180s to time out.  
>> However, I had set fetchmail's "timeout" parameter to only 60s. In  
>> my  tests, during the time when the Internet connection was down,  
>> at  least one "timeout after 60 seconds waiting to connect to  
>> server xy"  did indeed appear in the log for each server.
>
> ...amount of time.

If with "amount of time" you refer to the fact that the Internet must  
be down a certain amount of time for the issue to occur, this seems  
to be because the DNS data is cached for a certain amount of time,  
either by getaddrinfo() itself, or by Mac OS X's local caching BIND,  
or possibly by the caching name server of my router. Only when  
there's no cache anymore and getaddrinfo() (unsuccessfully) tries to  
retrieve that query data anew from the Internet, the timeout  
interruption will occur and prevent freeaddrinfo() from being called.

At least that's how I interpret all these error lines in my  
logfiles. ;-)

> Can you check with "lsof" or similar tools (that can list open  
> files and sockets) how many files and sockets fetchmail holds open  
> at the time when the problems start? It might be that the OS itself  
> is leaking sockets here which might appear in fetchmail's address  
> space.

I don't think there's a problem, but I will test it anyway and report  
as soon as I'll find time for another forced network outage.

>> So I'm quite sure that's the bug: Care must be taken that  
>> freeaddrinfo() is called even if SockOpen() is interrupted by a  
>> timeout.
>
> Certainly, and to avoid leaking memory on disconnected computers  
> would be reason enough to justify such a fix.

Maybe it's a good idea to check for all occurrences of freeaddrinfo()  
whether they are certain to be performed whenever they should.  
Glimpsing at the code, e.g. in servport.c, line 65, the default  
switch condition is a goto jump that prevents freeaddrinfo() from  
being called, although it should be called (getaddrinfo() had  
returned 0/success before, so "res" had been allocated). It seems  
that calling freeaddrinfo() was not taken all too seriously  
throughout fetchmail.

>> So you must either make ai0 a global variable (which won't work if  
>> you plan to make fetchmail open more than one socket  
>> simultaneously), or declare it in the calling code (driver.c or  
>> whatever) and pass it to SockOpen.
>
> "you'll have to" or "you may have to" sounds more polite than "you  
> must" (no offense taken, don't worry).

Well, the force of the laws of logic isn't polite ... ;-)  (This was  
not meant to be a social "must" but rather a logical one, as I indeed  
see no other programming techniques to deal with that issue.)

> Bugs related to signal handling (which is used for timeout  
> handling) require extra care. I myself will have to review the code  
> again before making changes in that area.
> [...]
> I don't think I'll be able to handle this before Saturday, perhaps  
> Sunday; but providing patches for you to test should be feasible.

Well, that's more than OK with me! If you deal with bugs in  
connection with Mac OS X, what you are afraid of are months or years  
until a fix is applied - days are no problem at all.  :-)

> Note that I don't have MacOS X machines to test on either.

No problem, I can test this here.

> Thank you!

Well, thank you (in advance) for the fix!  :-)


             Bye
                     Uli
________________________________________________________

   Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
   http://www.ritual.org
   Fon: +49-700-ULIZAPPE
   Fax: +49-700-ZAPPEFAX
________________________________________________________

Re: [fetchmail-users] option -v not working...

[Dave P. <sd...@gm...>]

* Matthias Andree <mat...@gm...> [2006-06-28 02:53:30 +0200]:


> Hang on - this means that fetchmail was utterly confused because it
> couldn't open the literal ~ directory? And handle --version improperly?
> Looks a bit odd -- and --nodetach is supposed to override --logfile
> <scratches head>
> 
Oh.  I was thinking that it tried to write to syslog (which I don't allow
userspace to do) first, and reporting instead went to /dev/null due to
system config.  Let me play with a couple settings here and I'll get back
to list. 

-- 
Cheers,

  Dave 

Re: [fetchmail-users] option -v not working...

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

Dave Patterson <sd...@gm...> writes:

> * Rob MacGregor <rob...@gm...> [2006-06-26 17:57:10 +0100]:
>
>> On 6/26/06, Dave Patterson <sd...@gm...> wrote:
>> >
>> >Contents of .fetchmailrc :
>> >
>> ><cut>
>> >
>> >set syslog
>> >set logfile=~/.fetchmaillog
>> 
> Removed 'set syslog', edited 'set logfile' line to read:
>
> set logfile = /home/dave/.fetchmaillog
>
> All good now.  Thanks for your time.  I'll go crawl back under my rock.

Hang on - this means that fetchmail was utterly confused because it
couldn't open the literal ~ directory? And handle --version improperly?
Looks a bit odd -- and --nodetach is supposed to override --logfile
<scratches head>

I think I'll play with this a bit more before 6.3.5 and see if there's
something to make fetchmail better behaved.

I've put this onto my TODO.txt.

Thanks for sharing the details!

-- 
Matthias Andree

Re: [fetchmail-users] [BUG] fetchmail daemon does not resume fetching after a network outage

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

Uli Zappe <ul...@ri...> writes:

> When getaddrinfo() is called while the Internet is down, it may take
> quite some time until it returns the respective error. Now, if the
> "timeout" variable in fetchmail is set to a value shorter than this
> time that getaddrinfo() needs, a call to SockOpen() (socket.c, line
> 266) from (at least) line 1053 in driver.c will be interrupted by the
> timeout signal handler. In this situation, freeaddrinfo() (line 311  in
> socket.c) will never be called to close ai0 correctly. This, in  turn,
> seems to produce the corrupted behavior of future getaddrinfo()  calls
> (at least in Mac OS X's implementation).

I haven't yet investigated all details, but your research looks valuable
and plausible, thank you!

While I'll certainly plug the leak (it may take until the week-end
though), there might still be a related MacOS X bug.  There is no
obligation to call freeaddrinfo() before calling getaddrinfo() again,
plus this function is required to be thread-safe (i. e. it needs to be
reentrant). However, you say that the problems happen after a certain...

> In my test case, getaddrinfo() may need up to 180s to time out. However,
> I had set fetchmail's "timeout" parameter to only 60s. In my  tests,
> during the time when the Internet connection was down, at  least one
> "timeout after 60 seconds waiting to connect to server xy"  did indeed
> appear in the log for each server.

...amount of time. Can you check with "lsof" or similar tools (that can
list open files and sockets) how many files and sockets fetchmail holds
open at the time when the problems start? It might be that the OS itself
is leaking sockets here which might appear in fetchmail's address space.

> I have now set fetchmail's "timeout" variable to 6000 and repeated my
> tests. No timeout message occurred, and after the Internet connection
> was up again, fetchmail resumed fetching mails just as it should.
>
> So I'm quite sure that's the bug: Care must be taken that freeaddrinfo
> () is called even if SockOpen() is interrupted by a timeout.

Certainly, and to avoid leaking memory on disconnected computers would
be reason enough to justify such a fix.

> So you must either make ai0 a global variable (which won't work if you
> plan to make fetchmail open more than one socket simultaneously), or
> declare it in the calling code (driver.c or whatever) and pass it to
> SockOpen.

"you'll have to" or "you may have to" sounds more polite than "you must"
(no offense taken, don't worry).

> My question now is how to proceed. Since you definitely know fetchmail's
> code much better than I do, it would make sense that you  fix the bug in
> all places where it might occur.

Bugs related to signal handling (which is used for timeout handling)
require extra care. I myself will have to review the code again before
making changes in that area.

> However, since the bug is crucial at least for me, I'd need a fix
> soon. So do you think you will come up with a fix in a short amount of
> time, of should I provide a fix temporarily (but I will probably
> overlook some of the situations where this bug might possibly occur -
> so far I'm only aware of driver.c line 1053 calling SockOpen())?

I don't think I'll be able to handle this before Saturday, perhaps
Sunday; but providing patches for you to test should be feasible.

Note that I don't have MacOS X machines to test on either.

Thank you!

-- 
Matthias Andree

Re: [fetchmail-users] [BUG] fetchmail daemon does not resume fetching after a network outage

[Uli Z. <ul...@ri...>]

Am 27.06.2006 um 05:12 schrieb Uli Zappe:

> The only explanation for this is that fetchmail somehow manages to  
> do something to the servers it calls that corrupts future  
> getaddrinfo() results for these (and only these) servers. Just what  
> that could possibly be, I have no idea.

After further inspection af the code and further testing, it seems I  
have found this "something":

When getaddrinfo() is called while the Internet is down, it may take  
quite some time until it returns the respective error. Now, if the  
"timeout" variable in fetchmail is set to a value shorter than this  
time that getaddrinfo() needs, a call to SockOpen() (socket.c, line  
266) from (at least) line 1053 in driver.c will be interrupted by the  
timeout signal handler. In this situation, freeaddrinfo() (line 311  
in socket.c) will never be called to close ai0 correctly. This, in  
turn, seems to produce the corrupted behavior of future getaddrinfo()  
calls (at least in Mac OS X's implementation).

In my test case, getaddrinfo() may need up to 180s to time out.  
However, I had set fetchmail's "timeout" parameter to only 60s. In my  
tests, during the time when the Internet connection was down, at  
least one "timeout after 60 seconds waiting to connect to server xy"  
did indeed appear in the log for each server.

I have now set fetchmail's "timeout" variable to 6000 and repeated my  
tests. No timeout message occurred, and after the Internet connection  
was up again, fetchmail resumed fetching mails just as it should.

So I'm quite sure that's the bug: Care must be taken that freeaddrinfo 
() is called even if SockOpen() is interrupted by a timeout. So you  
must either make ai0 a global variable (which won't work if you plan  
to make fetchmail open more than one socket simultaneously), or  
declare it in the calling code (driver.c or whatever) and pass it to  
SockOpen.

My question now is how to proceed. Since you definitely know  
fetchmail's code much better than I do, it would make sense that you  
fix the bug in all places where it might occur. However, since the  
bug is crucial at least for me, I'd need a fix soon. So do you think  
you will come up with a fix in a short amount of time, of should I  
provide a fix temporarily (but I will probably overlook some of the  
situations where this bug might possibly occur - so far I'm only  
aware of driver.c line 1053 calling SockOpen())?

             Bye
                     Uli
________________________________________________________

   Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
   http://www.ritual.org
   Fon: +49-700-ULIZAPPE
   Fax: +49-700-ZAPPEFAX
________________________________________________________

Re: [fetchmail-users] option -v not working...

[Dave P. <sd...@gm...>]

* Rob MacGregor <rob...@gm...> [2006-06-26 17:57:10 +0100]:

> On 6/26/06, Dave Patterson <sd...@gm...> wrote:
> >
> >Contents of .fetchmailrc :
> >
> ><cut>
> >
> >set syslog
> >set logfile=~/.fetchmaillog
> 
Removed 'set syslog', edited 'set logfile' line to read:

set logfile = /home/dave/.fetchmaillog

All good now.  Thanks for your time.  I'll go crawl back under my rock.

-- 
Cheers,

  Dave 

[fetchmail-users] [BUG] fetchmail daemon does not resume fetching after a network outage

[Uli Z. <ul...@ri...>]

Hi,

I'm encountering the following bug in fetchmail (versions from at  
least 6.2.5 up to 6.3.4) running in daemon mode on Mac OS X (versions  
from at least 10.4.2 up to 10.4.7) with a 60s poll interval.

Usually, daemon mode works just fine. If the Internet connection goes  
down for whatever reason, fetchmail will produce a SOCKET error ("No  
address associated with nodename"), as you would expect. If the  
Internet connection comes up again after a "short" amount of time,  
fetchmail will resume fetching mails as it should. However, if the  
Internet connection is down for a "longer" amount of time, fetchmail  
will keep reporting the same SOCKET errors if the Internet connection  
is finally up again, and never resume fetching mails until it is  
restarted (then everything works just fine again). I can't give an  
exact number for "longer", it can be everything from 15 to 90 minutes  
it seems (after 90 minutes, the issue *always* occurs, but sometimes  
it already occurs after 15 minutes).

Obviously, this makes using fetchmail in daemon mode highly  
unreliable as far as timely delivery of mails is concerned, and more  
or less unusable.

The issue is obviously tied to the the output of getaddrinfo(). If  
the issue occurs, it is because getaddrinfo() erroneously keeps  
returning the respective error after the the Internet connection is  
up again. At first I thought that this may be a bug in Mac OS X's  
getaddrinfo() implementation. However, no such bug was known, so I  
performed the following test myself (with extremely weird results):

At the beginning of fetchmail's daemon loop (after line 590 in  
fetchmail.c (of 6.3.4)) I inserted the following test code:

	struct addrinfo *ai, req;
	int gaiRes;
	memset(&req, 0, sizeof(struct addrinfo));
	req.ai_socktype = SOCK_STREAM;
	
	if (gaiRes=getaddrinfo("pop.1und1.com", "pop3s", &req, &ai))
	{
		report(stdout, GT_("GAI: 1und1: ERROR: %s\n"), gai_strerror(gaiRes));
	}
	else
	{
		freeaddrinfo(ai);
		report(stdout, GT_("GAI: 1und1: OK\n"));
	}

This is a code snippet basically taken from socket.c where the actual  
SOCKET error occurs. The queried host is one of the hosts I actually  
use with fetchmail. I repeated this code a second time for another  
host I actually use ("popmail.server.uni-frankfurt.de", "pop3s"), and  
a third time, as a comparison, for Apple's web server  
("www.apple.com", "http").

Then I took *exactly* this code (well, apart from replacing "report"  
by "printf") I inserted at the beginning of the fetchmail loop and  
put it in an endless loop (with 60s sleep after each loop) in a stand- 
alone Unix program.

Finally, I ran fetchmail in daemon mode and the test Unix program  
simultaneously (both as root), disrupted the Internet connection and  
looked what happened.

The really strange results are:

1. As long as the Internet connection is up, both programs (fetchmail  
and my test program) report "OK" for all three servers, as you would  
expect.

2. When the Internet connection goes down, for one server after  
another, a "No address associated with nodename" is displayed. The  
time it takes until this error shows up differs for the three servers  
(some caching issue, I suppose); however, it is synchronous on both  
programs (as soon as it is displayed on one program, it's also  
displayed on the other). Again, kind of what you would expect.

3. Now it gets weird. If the Internet connection comes up again, my  
test program immediately displays "OK" again for all three servers -  
that's how it should be. fetchmail, however, displays only "OK" for  
the Apple server; the two pop servers - that fetchmail actually works  
with in its code - keep displaying the "No address associated with  
nodename" error, which at least is consistent with the error messages  
in fetchmail's own code.


So to sum up:

Exactly the same getaddrinfo() code in fetchmail and a test program,  
run every 60s, produces exactly the same results for a server that  
otherwise is not called in fetchmail's original code, but different  
results for the two servers that are actually called in fetchmail's  
original code. In the latter case, the test program works as it  
should (no errors after the Internet connection is up again), while  
fetchmail does not work as it should (errors although the Internet is  
up again).

The only explanation for this is that fetchmail somehow manages to do  
something to the servers it calls that corrupts future getaddrinfo()  
results for these (and only these) servers. Just what that could  
possibly be, I have no idea.

Also, I have no way of knowing if this is only the case in connection  
with Mac OS X's getaddrinfo() implementation (I only have Macs here).  
My test program shows that Mac OS X's getaddrinfo() works fine under  
"normal" conditions, though.

So I guess the first thing to find out is if this bug is reproducible  
on other Unix systems, and then proceed from there.

             Bye
                     Uli
________________________________________________________

   Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
   http://www.ritual.org
   Fon: +49-700-ULIZAPPE
   Fax: +49-700-ZAPPEFAX
________________________________________________________

Re: [fetchmail-users] option -v not working...

[Dave P. <sd...@gm...>]

* Rob MacGregor <rob...@gm...> [2006-06-26 17:57:10 +0100]:

> So, what's in that logfile?
> 
dave@davescrunch:~$ cat .fetchmaillog
dave@davescrunch:~$

--
Cheers,

  Dave 

Re: [fetchmail-users] option -v not working...

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

On 6/26/06, Dave Patterson <sd...@gm...> wrote:
>
> Contents of .fetchmailrc :
>
> <cut>
>
> set syslog
> set logfile=~/.fetchmaillog

So, what's in that logfile?

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] option -v not working...

[Dave P. <sd...@gm...>]

* Rob MacGregor <rob...@gm...> [2006-06-26 10:12:26 +0100]:

 
> Version of fetchmail?
> 
Debian's fetchmail package # 6.3.4-1

('fetchmail -V' or fetchmail --version' results in fetchmail retrieving mail and passing it to Procmail, but the version request is ignored - interesting)

> 
> Any command line arguments passed to fetchmail (and what are they)?
> 
Command line arguments thus far have been '-V'  '--version' '--nodetach
--nosyslog' '-v'

Contents of .fetchmailrc :

<cut>

set syslog
set logfile=~/.fetchmaillog

poll pop.gmail.com with proto POP3 and options no dns 
    user 'XX...@gm...' with pass "XXX"  is 'dave' here options
    ssl 
    mda '/usr/bin/procmail -d %T'

    poll pop.mail.yahoo.com with protocol pop3,
    user XXX there is dave here,
    with password XXX;
    mda '/usr/bin/procmail -d %T'

    poll net1.ji-net.com with protocol pop3,
    user XXX there is dave here,
    with password XXX;
    mda '/usr/bin/procmail -d %T'

    poll 127.0.0.1 port 110 with protocol pop3,
    user 'XXX' with pass "XXX" is
    'dave' here,
    mda '/usr/bin/procmail -d %T

<cut>


Hmmm..

Cheers, Dave

Re: [fetchmail-users] option -v not working...

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

Dave Patterson <sd...@gm...> writes:

> * Matthias Andree <mat...@gm...> [2006-06-26 09:38:17 +0200]:
>
>  
>> Add --nodetach --nosyslog to the command line.
>> 
> No luck.
>> Otherwise, syslog (/var/log/mail, /var/log/maillog, or thereabouts).
>> 
> None there, either... 

--logfile (or set logfile) used?

-- 
Matthias Andree

Re: [fetchmail-users] option -v not working...

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

On 6/26/06, Dave Patterson <sd...@gm...> wrote:
> Hello all.  If this has been posted already, I apologize.
>
> I'm not able to get output to terminal using fetchmail -v

Version of fetchmail?

Contents of .fetchmailrc?

Any command line arguments passed to fetchmail (and what are they)?

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] option -v not working...

[Dave P. <sd...@gm...>]

* Matthias Andree <mat...@gm...> [2006-06-26 09:38:17 +0200]:

 
> Add --nodetach --nosyslog to the command line.
> 
No luck.
> Otherwise, syslog (/var/log/mail, /var/log/maillog, or thereabouts).
> 
None there, either... 

Regards, Dave

Re: [fetchmail-users] option -v not working...

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

Dave Patterson <sd...@gm...> writes:

> Hello all.  If this has been posted already, I apologize.
>
> I'm not able to get output to terminal using fetchmail -v

Add --nodetach --nosyslog to the command line.

> fetchmail executes normally (I think) as the mail is being delivered to
> procmail, and from there to my various boxes.  However, I have no
> indication as to messages retrieved, skipped, etc.  Where to look?

Otherwise, syslog (/var/log/mail, /var/log/maillog, or thereabouts).

-- 
Matthias Andree

Re: [fetchmail-users] option -v not working...

[Frederic M. <fre...@wo...>]

Dave Patterson wrote:
> Hello all.  If this has been posted already, I apologize.
>   

I think it has been answered several times and by people more 
knowledgeable than me... :-)

> I'm not able to get output to terminal using fetchmail -v
>
> fetchmail executes normally (I think) as the mail is being delivered to
> procmail, and from there to my various boxes.  However, I have no
> indication as to messages retrieved, skipped, etc.  Where to look?
>   

In my case, when fetchmail runs in daemon mode (-d option), I also 
specify the --syslog option and the outputs are written to 
/var/log/mail.info but it really depends on the configuration of syslog.

Frederic

[fetchmail-users] option -v not working...

[Dave P. <sd...@gm...>]

Hello all.  If this has been posted already, I apologize.

I'm not able to get output to terminal using fetchmail -v

fetchmail executes normally (I think) as the mail is being delivered to
procmail, and from there to my various boxes.  However, I have no
indication as to messages retrieved, skipped, etc.  Where to look?

Cheers, Dave

RE: [fetchmail-users] Accessing user mailbox from another account

[Ian M. <ia...@in...>]

Frederic

It is only a way to permit cross mailbox access. Neither of the accounts
needs to be privileged, account A only needs access to mailbox B.
Considering how it works, I would be surprised if something similar did
not exist in many linux based pop3 servers out there.

The possibility for an attack on the server using the admin account
would exist regardless. An attacker can always try the administrator
account, but you have to take the following into account before that
would work:

- pop3 must be enabled for the admin account... Which normally it would
not be. 
- The admin account has not been renamed (also under windows the admin
account has a local spelling, so in france it is administrateur - you
have no way of knowing)
- Have loads of patience - usually after several failed tries the server
stops authenticating the connections and you don't know when it has
stopped authenticating and is simply failing all attempts.
- As far as I know any linux based pop3 server will allow access to the
email for the root account in the same way.

In my experience dictionary attacks have been a waste of time for over
10 years on most systems... Embedded systems excluded.



Ian Murphy
Integra XP
http://www.integra-xp.com
00 34 94 621 5265

Re: [fetchmail-users] Accessing user mailbox from another account

[Frederic M. <fre...@wo...>]

Ian Murphy wrote:
> Found a way of doing it. Both the pop3 and imap servers under MS
> exchange support a format of
>
> User		domain\privuser\mbx
> Passowrd	privuserpassword
>
> Which allows reading a users mailbox using the password of a privileged
> account - assuming the appropriate security has been setup in exchange.
>
> Mbx in this case is simply the user account name.
>   

I can't believe they did it ! It's silly to offer the opportunity to use 
a system user name and password to access a remote service... A 
dictionary attack on any pop3 or imap mailbox could yield a system 
password. Microsoft just never learn :-(

Well, at least, it solves your problem :-)

Frederic

RE: [fetchmail-users] Accessing user mailbox from another account

[Ian M. <ia...@in...>]

Found a way of doing it. Both the pop3 and imap servers under MS
exchange support a format of

User		domain\privuser\mbx
Passowrd	privuserpassword

Which allows reading a users mailbox using the password of a privileged
account - assuming the appropriate security has been setup in exchange.

Mbx in this case is simply the user account name.

Ian Murphy
Integra XP
http://www.integra-xp.com
00 34 94 621 5265
 

-----Mensaje original-----
De: fet...@be...
[mailto:fet...@be...] En nombre de Frederic Marchal
Enviado el: viernes, 23 de junio de 2006 14:14
Para: fet...@li...
Asunto: Re: [fetchmail-users] Accessing user mailbox from another
account

Ian Murphy wrote:
> Frederic, Thanks for responding,
>
> Mail is currently delivered to exchange. They are migrating to a linux

> server. No external boxes involved. This requires a visit to each and 
> every desktop to modify the mail client, so the migration will take 
> some time (multiple remote offices too to complicate matters) and will

> have to be done mailbox by mailbox.
>
> Step one will be switch the mx record to deliver email to the linux 
> server by default. Easy.
>
> Once email is arriving on the linux box, fetchmail is used to pull it 
> out and redeliver it to the exchange server. Again easy.
>   

Something is missing here... Why do you need fetchmail to do this ?
Don't you have one account per user with one password for each user on
the linux server ? It seems to me that this part you have got running
faces the same problem you are asking a solution for ? Fetchmail must
download the mails from the user's mailbox and it must know about all
the user names and passwords... How did you got it running ?

BTW, here, a .forward file per user would be perfect and more reliable
than fetchmail... If your server is running usermin, the user can even
remove the redirection by himself when he starts fetching his mails on
the linux server.

> When a users mail client is switched from exchange to using pop3 
> against the linux server the pull-from-linux-push-to-exchange will be 
> switched off for their mailbox.
>
> However the problem is that internal users will continue to send email

> via exchange, which will deliver to the now unmonitored exchange 
> mailbox.
>
> What I want to do is pull any mail which may arrive out of the exhange

> mailbox and deliver it to the users mailbox on the linux box. However 
> since users change their passwords, and its not a good idea, I didn't 
> want to make a big list of each user account and their password just 
> to achieve this.
>
> I was hoping either pop3 or imap would have an authentication type 
> which would allow me to do something like
>
> Fetch mail using user administrator password asecret from mailbox 
> johndoe on server 1.2.3.4 deliver to smtpserver 1.2.3.5
>   

No. As far as I know, imap and pop3 provide access to one and only one
mailbox and more specifically to the mailbox that was named during the
authentication. In fact, you don't provide a user name with some rights
attached to it when you use pop3 or imap. You provide the name of a
mailbox. (Somebody fix this if I'm wrong !)

But that doesn't mean you have to create the dreaded list of
user/password now...

Can you tell exchange to redirect the mails of the users that already
moved to the linux server ? I'm thinking about an alias or something
like that to an internal server name such as us...@li....
That domain would be considered local by the linux server and the
exchange server would just have to know the route to that server.

Or could you divert the mails of those users to a single account on the
exchange server and fetch the mails from that account ?

Frederic



_______________________________________________
fetchmail-users mailing list
fet...@li...
http://lists.berlios.de/mailman/listinfo/fetchmail-users

Re: [fetchmail-users] Accessing user mailbox from another account

[Frederic M. <fre...@wo...>]

Ian Murphy wrote:
> Frederic, Thanks for responding,
>
> Mail is currently delivered to exchange. They are migrating to a linux
> server. No external boxes involved. This requires a visit to each and
> every desktop to modify the mail client, so the migration will take some
> time (multiple remote offices too to complicate matters) and will have
> to be done mailbox by mailbox. 
>
> Step one will be switch the mx record to deliver email to the linux
> server by default. Easy.
>
> Once email is arriving on the linux box, fetchmail is used to pull it
> out and redeliver it to the exchange server. Again easy.
>   

Something is missing here... Why do you need fetchmail to do this ?
Don't you have one account per user with one password for each user on
the linux server ? It seems to me that this part you have got running
faces the same problem you are asking a solution for ? Fetchmail must
download the mails from the user's mailbox and it must know about all
the user names and passwords... How did you got it running ?

BTW, here, a .forward file per user would be perfect and more reliable
than fetchmail... If your server is running usermin, the user can even
remove the redirection by himself when he starts fetching his mails on
the linux server.

> When a users mail client is switched from exchange to using pop3 against
> the linux server the pull-from-linux-push-to-exchange will be switched
> off for their mailbox. 
>
> However the problem is that internal users will continue to send email
> via exchange, which will deliver to the now unmonitored exchange
> mailbox.
>
> What I want to do is pull any mail which may arrive out of the exhange
> mailbox and deliver it to the users mailbox on the linux box. However
> since users change their passwords, and its not a good idea, I didn't
> want to make a big list of each user account and their password just to
> achieve this.
>
> I was hoping either pop3 or imap would have an authentication type which
> would allow me to do something like
>
> Fetch mail using user administrator password asecret from mailbox
> johndoe on server 1.2.3.4 deliver to smtpserver 1.2.3.5
>   

No. As far as I know, imap and pop3 provide access to one and only one
mailbox and more specifically to the mailbox that was named during the
authentication. In fact, you don't provide a user name with some rights
attached to it when you use pop3 or imap. You provide the name of a
mailbox. (Somebody fix this if I'm wrong !)

But that doesn't mean you have to create the dreaded list of
user/password now...

Can you tell exchange to redirect the mails of the users that already
moved to the linux server ? I'm thinking about an alias or something
like that to an internal server name such as us...@li....
That domain would be considered local by the linux server and the
exchange server would just have to know the route to that server.

Or could you divert the mails of those users to a single account on the
exchange server and fetch the mails from that account ?

Frederic

RE: [fetchmail-users] Accessing user mailbox from another account

[Ian M. <ia...@in...>]

Frederic, Thanks for responding,

Mail is currently delivered to exchange. They are migrating to a linux
server. No external boxes involved. This requires a visit to each and
every desktop to modify the mail client, so the migration will take some
time (multiple remote offices too to complicate matters) and will have
to be done mailbox by mailbox. 

Step one will be switch the mx record to deliver email to the linux
server by default. Easy.

Once email is arriving on the linux box, fetchmail is used to pull it
out and redeliver it to the exchange server. Again easy.

When a users mail client is switched from exchange to using pop3 against
the linux server the pull-from-linux-push-to-exchange will be switched
off for their mailbox. 

However the problem is that internal users will continue to send email
via exchange, which will deliver to the now unmonitored exchange
mailbox.

What I want to do is pull any mail which may arrive out of the exhange
mailbox and deliver it to the users mailbox on the linux box. However
since users change their passwords, and its not a good idea, I didn't
want to make a big list of each user account and their password just to
achieve this.

I was hoping either pop3 or imap would have an authentication type which
would allow me to do something like

Fetch mail using user administrator password asecret from mailbox
johndoe on server 1.2.3.4 deliver to smtpserver 1.2.3.5


Ian Murphy
Integra XP
http://www.integra-xp.com
00 34 94 621 5265
 

-----Mensaje original-----
De: Frederic Marchal [mailto:fre...@wo...] 
Enviado el: viernes, 23 de junio de 2006 11:49
Para: Ian Murphy
CC: fet...@li...
Asunto: Re: [fetchmail-users] Accessing user mailbox from another
account

Ian Murphy wrote:
> I have been charged with migrating an exchange 2000 instalation to a 
> linux server and am using fetchmail to handle interopability during 
> the migration period.
>  
> I am currently re-delivering email that arrives on the linux box to 
> MSExchange via smtp and its working like a dream.
>  
> I now need to be able to pull new email from the exchange server and 
> deliver it to the linux server. To avoid the need to know the users 
> passwords I want to give read/write access rights to their mailboxes 
> to a special account and to read all the mailboxes using a single 
> priviliged account.
>  
> Now, my problem, what is this type of access called ? I've been 
> looking at the fetchmail documentation for pop3 and imap access and am

> lost in the sea of authentication types and options, though it seems 
> pretty likely that it is possible.
>  
> Can anyone steer me in the right direction ?

I don't understand your current configuration and what you want to
achieve, especially, the part about what server is downloading what kind
of mail and from where...

Depending on the way I read your mail, I understand one of the two
following things:

1) You have both a linux *and* an msexchange server fetching inbound
e-mails from an outside server (your ISP for instance) and you want to
synchronize the e-mails between the two servers so that your users can
use any server.

2) Your mails are processed by the msexchange server which act now as a
relay for the linux server and you want your users to migrate at their
leisure from this server to the linux server before you decommission the
msexchange server and make the linux server your main mail server.

Since case 2 seems more likely, I'll answer this one for now.

If your idea is to read all the mailboxes of all the users from one
account on the msexchange server and deliver them to the proper user
account on the linux server, then I don't think it is possible (at least
not with pop3 or imap but maybe with a samba connection and some
cron/bash scripts).

You have either to divert a copy of each incoming mail on the msexchange
server to one account on that server and read that single account with
fetchmail (provided your msexchange server adds the proper information
such as a X-Envelope header) or you have to forward the mails of each
user to the linux server using the msexchange equivalent to a .forward
file on linux (I don't know what that mechanism could be because I don't
know msechange).

Frederic

Re: [fetchmail-users] Accessing user mailbox from another account

[Frederic M. <fre...@wo...>]

Ian Murphy wrote:
> I have been charged with migrating an exchange 2000 instalation to a 
> linux server and am using fetchmail to handle interopability during 
> the migration period.
>  
> I am currently re-delivering email that arrives on the linux box to 
> MSExchange via smtp and its working like a dream.
>  
> I now need to be able to pull new email from the exchange server and 
> deliver it to the linux server. To avoid the need to know the users 
> passwords I want to give read/write access rights to their mailboxes 
> to a special account and to read all the mailboxes using a single 
> priviliged account.
>  
> Now, my problem, what is this type of access called ? I've been 
> looking at the fetchmail documentation for pop3 and imap access and am 
> lost in the sea of authentication types and options, though it seems 
> pretty likely that it is possible.
>  
> Can anyone steer me in the right direction ?

I don't understand your current configuration and what you want to 
achieve, especially, the part about what server is downloading what kind 
of mail and from where...

Depending on the way I read your mail, I understand one of the two 
following things:

1) You have both a linux *and* an msexchange server fetching inbound 
e-mails from an outside server (your ISP for instance) and you want to 
synchronize the e-mails between the two servers so that your users can 
use any server.

2) Your mails are processed by the msexchange server which act now as a 
relay for the linux server and you want your users to migrate at their 
leisure from this server to the linux server before you decommission the 
msexchange server and make the linux server your main mail server.

Since case 2 seems more likely, I'll answer this one for now.

If your idea is to read all the mailboxes of all the users from one 
account on the msexchange server and deliver them to the proper user 
account on the linux server, then I don't think it is possible (at least 
not with pop3 or imap but maybe with a samba connection and some 
cron/bash scripts).

You have either to divert a copy of each incoming mail on the msexchange 
server to one account on that server and read that single account with 
fetchmail (provided your msexchange server adds the proper information 
such as a X-Envelope header) or you have to forward the mails of each 
user to the linux server using the msexchange equivalent to a .forward 
file on linux (I don't know what that mechanism could be because I don't 
know msechange).

Frederic

[fetchmail-users] Accessing user mailbox from another account

[Ian M. <ia...@in...>]

I have been charged with migrating an exchange 2000 instalation to a
linux server and am using fetchmail to handle interopability during the
migration period.
 
I am currently re-delivering email that arrives on the linux box to
MSExchange via smtp and its working like a dream.
 
I now need to be able to pull new email from the exchange server and
deliver it to the linux server. To avoid the need to know the users
passwords I want to give read/write access rights to their mailboxes to
a special account and to read all the mailboxes using a single
priviliged account.
 
Now, my problem, what is this type of access called ? I've been looking
at the fetchmail documentation for pop3 and imap access and am lost in
the sea of authentication types and options, though it seems pretty
likely that it is possible.
 
Can anyone steer me in the right direction ? 
 
regards
 
Ian Murphy
Integra XP
http://www.integra-xp.com
00 34 94 621 5265
 
 

Re: [fetchmail-users] self-signed certs + fetchmail nuisance

[Volker K. <lis...@pa...>]

Hi Matthias,

> > fetchmail: Server certificate verification error: self signed
> > certificate

> This issue is fixed in the latest available release, 6.3.4, where
> sslfingerprint (on the command line or in the rcfile) should suppress these
> warnings unless sslcertck is enabled.

Thanks much! Recompiling the SUSE source rpm with the latest fetchmail
turned out to be very straightforward.

> - ask your ISP to provide proper SSL certificates

Did that, and was told that the current self-signed cert is on the
testing rack, and once email is moved to the next setup in a few weeks,
externally signed certs will be used, so the problem for me will solve
itself.

Thanks again,

Volker

-- 
Volker Kuhlmann			is list0570 with the domain in header
http://volker.dnsalias.net/	Please do not CC list postings to me.