fetchmail-users — User questions and discussion

[fetchmail-users] Re: Re: WARNING: Running as root is discouraged.

[Michelle K. <lin...@fr...>]

Hallo Matthias,

Am 2006-01-08 22:56:51, schrieb Matthias Andree:

> It's been a long time - désolé. I hope it's still useful :-)

:-)

> Set procmail setuid-root if you trust it (I don't trust it though).
> 
> Better pick: Replace procmail by maildrop, compile it so that the
> fetchmail user is allowed to use -d, and install maildrop setuid-root.
> It will be a better match for courier-imap anyhow. (Maildir++, quota,
> same user database and all the nice parts of integration.)

Unfortunatly "courier-maildrop" is no option for me, because I have
setup a whole "office" web interface with php5 and the filters are
set directly in procmail.

The syntax of maildrop is driving me crazy and I have not the time
and LUST to recode all from scratch again!

Greetings
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/3/88452356    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

[fetchmail-users] Re: Please blacklist Subject "fetchmail-users digest..."

[Michelle K. <lin...@fr...>]

Am 2006-01-08 22:13:15, schrieb Matthias Andree:

> It's impolite to send messages to lists with meaningless subjects, and
> people with inferior mailers and without a chance to split the digest up
> locally still have the option to switch their subscription to the
> "plain" format.

Right, but what I do not understand is, that for example "procmail"
has a realy nice example in its manpages how to split a digest into
singel parts using "formail".

I am on three lists which sends digest only and I get each day 5-20
singel messages into my Mailbox without any headache.

<seufz>Nobody like RTFM</seufz>

Greetings
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/3/88452356    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

[fetchmail-users] fetchmail 6.3.2-rc4 final release candidate

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

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

Greetings,

a recently reported Debian bug spoiled my plans to have -rc3 as the
final release candidate, but I hope it was the penultimate - to avoid
embarrassment with the final 6.3.2, I've chosen to insert -rc4.

This release candidate fixes a segfault after sending a bounce.

This release candidate (#4) for 6.3.2 is available from
http://mandree.home.pages.de/fetchmail/

I have requested a CVE Id from MITRE to track this problem and will add
it to the security announcement before 6.3.2 release.

Changes in fetchmail 6.3.2-rc4 (from -rc3):

# SECURITY FIX IN THIS RELEASE
* CVE-2006-XXXX: Fix segfault or bus error after bouncing a message.  This bug
  was introduced into 6.3.0 when removing alloca(); it caused fetchmail to free
  random memory.  Reported by Nathaniel W. Turner, Debian Bug#348747.
  See fetchmail-SA-2006-01.txt

# CHANGES RELEVANT TO PACKAGERS:
* Added fetchmail-SA-2006-01.txt to the distribution.

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

iD8DBQFDzxDdvmGDOQUufZURAiVYAJ4q2xxCuGVrxcP+VJ/fronZz7R/twCgsJXS
jVwe62uMCA+5wYN2iIQ5F1Y=
=V2fc
-----END PGP SIGNATURE-----

[fetchmail-users] fetchmail 6.3.2-rc3 final release candidate

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

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

Greetings,

the final release candidate (#3) for 6.3.2 is available from
http://mandree.home.pages.de/fetchmail/

I released this candidate to give translators some more days to catch up
with the upstream before 6.3.2 is released. Spanish is severely lagged
behind with a potential new translator, and other languages could also
use some updating.

- ---------------------------------------------------------------------
If the translation of YOUR language is missing or out of date, please
help!  Contact me for details on the fetchmail-devel@ mailing list.
- ---------------------------------------------------------------------

(French request for help with translating fetchmail to French:)
| Si vous parlez le français très bien, je vous prie de m'aider et
| devenir traducteur de fetchmail. En ce cas, je vous donnerai une
| traduction complète à commencer sans trop d'effort. Mon français n'est
| pas assez bon afin de m'appeler traducteur officiel.
| 
| J'avais déjà posé cette question dans la liste traduc@ mais je n'y ai
| pas trouvé un autre traducteur.
| 
| Merci.
(end of French)

These are the changes since 6.3.2-rc2:

# CHANGES THAT WILL NOT APPEAR IN THE FINAL NEWS FILE
  because they are revisions of -rc internal changes
  or are too minor:
* The Maillennium workaround warning was changed to put the Maillennium
  server name into quotes.
* A few compiler warnings were fixed
* COPYING was revised

# CHANGES RELEVANT TO PACKAGERS:
* The outdated BUGS document was removed from the distribution.  Matthias Andree

# OTHER USER-VISIBLE CHANGES:
* fetchmail.man: Fix accented characters in Héctor García's name.  Merged from
  downstream debian/patches/01_man_page.dpatch. Matthias Andree.
* Add missing --help text for "--sslcertck" option. Matthias Andree.
* fetchmailconf.py: Accept --help and --version. Matthias Andree.
* fetchmail --version  now prints the copyright notice. Matthias Andree.

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDzREdvmGDOQUufZURAr11AJ0Y4RDi6xcYG1ljtjgPdewh+LCzFwCePN3m
tit+cOqUH7B18BVlIZ84ZA8=
=ISlw
-----END PGP SIGNATURE-----

[fetchmail-users] Re: fetchmail-users -- confirmation of subscription -- request 274731

[Paul D. <pa...@pe...>]

On Sun, 15 Jan 2006 12:27:31 +0100, fet...@be... wrote:

> fetchmail-users -- confirmation of subscription -- request 274731
> 
> We have received a request from 68.230.78.84 for subscription of your
> email address, <pa...@pe...>, to the
> fet...@li... mailing list.  To confirm the
> request, please send a message to
> fet...@li..., and either:
> 
> - maintain the subject line as is (the reply's additional "Re:" is
> ok),
> 
> - or include the following line - and only the following line - in the
> message body: 
> 
> confirm 274731
> 
> (Simply sending a 'reply' to this message should work from most email
> interfaces, since that usually leaves the subject line in the right
> form.)
> 
> If you do not wish to subscribe to this list, please simply disregard
> this message.  Send questions to
> fet...@li....


	-Paul

Re: [fetchmail-users] Header Problems.

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

On Fri, 13 Jan 2006, rahul wrote:

> My fetchmail configration is:-
> 
> poll 209.216.x.x  with proto POP3
> localdomains example.com
> envelope "Delivered-To:"
> user cat...@ex... there with password "123456"
> is * here
> fetchall

What part about my answer (which you even quoted)

> > Look for "qvirtual".

did you not understand?

Now please stop wasting everybody's time, read the manual page and
adjust your fetchmail configuration.

Thank you.

-- 
Matthias Andree

Re: [fetchmail-users] Header Problems.

[rahul <rah...@ya...>]

Hi,

I FOLLOW THE SAME URL WHICH YOU HAVE SEND
http://fetchmail.berlios.de/fetchmail-FAQ.html#T2

I have configured .qmail file in /var/qmail/alias
like:-

cat .qmail-1-default
| ../bin/qmail-inject -a -f"$SENDER"
"${LOCAL#1-}@$HOST"


My fetchmail configration is:-

poll 209.216.x.x  with proto POP3
localdomains example.com
envelope "Delivered-To:"
user cat...@ex... there with password "123456"
is * here
fetchall


When i download mails through fetchmail,Now this time
you can see somthing different see the log:-

tail -f /var/log/qmail/send/current
@4000000043c796fc01f9ce54 new msg 1435879
@4000000043c796fc01f9da0c info msg 1435879: bytes 2764
from <rah...@ya...> qp 16283 uid 89
@4000000043c796fc02203274 starting delivery 2738: msg
1435879 to local exa...@ex...
@4000000043c796fc02203a44 status: local 1/10 remote
0/20
@4000000043c796fc026d48d4 delivery 2738: failure:
Sorry,_no_mailbox_here_by_that_name._(#5.1.1)/


HERE YOU CAN SEE SPECIAL HEADER "example.com-1-"
ADDED, HOW CAN I RESOLVE IT PLEASE HELP.



****Headers Detail****

Cc:   	us...@ex...

Content-Transfer-Encoding:  	8bit
Content-Type:  	text/plain; charset=iso-8859-1
Date:  	Mon, 2 Jan 2006 03:27:28 -0800 (PST) [03:27:28
AM PST]

Delivered-To:  	1-...@ex...

DomainKey-Signature:  	a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding;
b=2A5uUPvemgNlni1VGY/cByhG46J5QUZT5LONmUGG+hEL3Q2CnlsVYaxsZXDAer9/KSEVM2iDe8k22W8gsgwRFyfINgBiVqfR79OIwdsQefDcgcWuG8yF+7wzpx7swS/AHtkl2F1V0IrvGQaxHVrZe8aBCVnVK5V6Dzrfh9JAs5I=
;

From:  	rahul <rah...@ya...>
MIME-Version:  	1.0
Message-ID:  
<200...@we...>

Received:    * (qmail 9691 invoked from network); 2
Jan 2006 03:27:56 -0800    * from
web32115.mail.mud.yahoo.com (68.142.207.129) by
209.216.23.17 with SMTP; 2 Jan 2006 03:27:55 -0800   
* (qmail 38250 invoked by uid 60001); 2 Jan 2006
11:27:28 -0000    * from [203.197.202.18] by
web32115.mail.mud.yahoo.com via HTTP; Mon, 02 Jan 2006
03:27:28 PST

Return-Path:  	<rah...@ya...>
Subject:  	*****SPAM***** Test Mail !!!
To:  	us...@ex...
X-Spam-Checker-Version:  
SpamAssassin 2.63 (2004-01-11) on
admin.intersofttechnologies.com
X-Spam-Flag:  	YES
X-Spam-Level:

*******************END Headers Detail***************

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

> rahul <rah...@ya...> writes:
> 
> > I AM AGAIN POSTING THE SAME MESSAGE. I CAN NOT
> CHANGE
> > RUNNING QMAIL SERVER, PLEASE HELP ME TO RESOLVE
> THIS
> > PROBLEM. 
> 
> Even if you cannot change your server, the answer is
> in the manual page,
> as I wrote earlier in my message that you have
> already read,
>
<http://lists.ccil.org/pipermail/fetchmail-friends/2006-January/009913.html>
> 
> The answer is also in the FAQ:
> <http://fetchmail.berlios.de/fetchmail-FAQ.html#T2>
> 
> Look for "qvirtual".
> 
> -- 
> Matthias Andree
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [fetchmail-users] Header Problems.

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

rahul <rah...@ya...> writes:

> I AM AGAIN POSTING THE SAME MESSAGE. I CAN NOT CHANGE
> RUNNING QMAIL SERVER, PLEASE HELP ME TO RESOLVE THIS
> PROBLEM. 

Even if you cannot change your server, the answer is in the manual page,
as I wrote earlier in my message that you have already read,
<http://lists.ccil.org/pipermail/fetchmail-friends/2006-January/009913.html>

The answer is also in the FAQ:
<http://fetchmail.berlios.de/fetchmail-FAQ.html#T2>

Look for "qvirtual".

-- 
Matthias Andree

[fetchmail-users] Header Problems.

[rahul <rah...@ya...>]

Hi,

I AM AGAIN POSTING THE SAME MESSAGE. I CAN NOT CHANGE
RUNNING QMAIL SERVER, PLEASE HELP ME TO RESOLVE THIS
PROBLEM. 


I have two users one is remote user
(us...@ex...).
&
second is us...@do.... us...@do... mails
forward to xy...@ex... a/c.

When i send mail from yahoo.com to
(To:-us...@ex...) &  (Cc:- us...@ex...).

when i check mails us...@ex... a/c its
received....
 But
when i check xy...@ex... a/c through webmail and
check my yahoo mail with headers, 
see the headers below:-

****Headers Detail****

Cc:   	us...@ex...

Content-Transfer-Encoding:  	8bit
Content-Type:  	text/plain; charset=iso-8859-1
Date:  	Mon, 2 Jan 2006 03:27:28 -0800 (PST) [03:27:28
AM PST]

Delivered-To:  	1-...@ex...

DomainKey-Signature:  	a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding;
b=2A5uUPvemgNlni1VGY/cByhG46J5QUZT5LONmUGG+hEL3Q2CnlsVYaxsZXDAer9/KSEVM2iDe8k22W8gsgwRFyfINgBiVqfR79OIwdsQefDcgcWuG8yF+7wzpx7swS/AHtkl2F1V0IrvGQaxHVrZe8aBCVnVK5V6Dzrfh9JAs5I=
;

From:  	rahul <rah...@ya...>
MIME-Version:  	1.0
Message-ID:  
<200...@we...>

Received:    * (qmail 9691 invoked from network); 2
Jan 2006 03:27:56 -0800    * from
web32115.mail.mud.yahoo.com (68.142.207.129) by
209.216.23.17 with SMTP; 2 Jan 2006 03:27:55 -0800   
* (qmail 38250 invoked by uid 60001); 2 Jan 2006
11:27:28 -0000    * from [203.197.202.18] by
web32115.mail.mud.yahoo.com via HTTP; Mon, 02 Jan 2006
03:27:28 PST

Return-Path:  	<rah...@ya...>
Subject:  	*****SPAM***** Test Mail !!!
To:  	us...@ex...
X-Spam-Checker-Version:  
SpamAssassin 2.63 (2004-01-11) on
admin.intersofttechnologies.com
X-Spam-Flag:  	YES
X-Spam-Level:

*******************END Headers Detail***************

My fetchmail Version is 6.3.1.

my fetchmailrc file is:-
poll 209.216.253.97  with proto POP3
localdomains example.com localhost
envelope 'Delivered-To: 1-'
user xy...@ex... there with password "12345" is *
here
fetchall

Please  see /var/log/qmail/send/current log:

-@4000000043b91fee05a26bc4 info msg 882491: bytes 2937
from <rah...@ya...> qp 25416 uid 506
@4000000043b91fee09aaec14 starting delivery 114: msg
882491 to remote 1-...@ex...

If you see my current log, qmail add 
"1-...@ex..."

us...@ex... USER exist in qmail
BUT
1-...@ex... DOES NOT EXIST IN QMAIL. 

HOW CAN I REMOVE "1-" so that the mail should
delivered locally?

Any direction would be appreciated!!!  


--Thanks
Rahul  

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [fetchmail-users] Re: WARNING: Running as root is discouraged.

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

Michelle Konzack <lin...@fr...> writes:

> Am 2005-11-17 11:02:01, schrieb Matthias Andree:
>> Thomas Wolff schrieb am 2005-11-11:
>> 
>> > There is this new warning "WARNING: Running as root is discouraged." 
>> > which is somehow disturbing.
>> 
>> Yes, and that is deliberate.
>> 
>> Networking clients should never run with root privileges, and fetchmail
>> is no exception. Fetchmail does not need root privileges to forward
>> mail, the only conceivable scenario where it needs root privileges is
>> one where it calls an MDA for a different user.
>
> If fetchmail can not started by the $USER and it run global from a
> script for all $USERS with "mda /usr/bin/procmail -d %T" what must
> I change that it continue to work

It's been a long time - désolé. I hope it's still useful :-)

Set procmail setuid-root if you trust it (I don't trust it though).

Better pick: Replace procmail by maildrop, compile it so that the
fetchmail user is allowed to use -d, and install maildrop setuid-root.
It will be a better match for courier-imap anyhow. (Maildir++, quota,
same user database and all the nice parts of integration.)

-- 
Matthias Andree

Re: [fetchmail-users] Fetchmail & Merak Mail Server

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

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

> Alternatively, put it this way - you have no choice.  You can either
> enable UIDL support or try to find another solution that doesn't use
> fetchmail :)

Only that the other solution would also have to use fetchall+nokeep
approaches or UIDL...

-- 
Matthias Andree

[fetchmail-users] Re: blacklisting digest replies

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

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

> On 08/01/06, Matthias Andree <mat...@gm...> wrote:
>> BTW, can the list filters please be adjusted so as to ban + reject
>> "fetchmail-users digest" in subjects?
>
> It doesn't look like mailman can handle this.  The closest it comes is
> allowing you to make a subject with that line a spam marker, which
> then requires an admin to review and act upon - a less than ideal
> approach.

OK, but Mailman can disable digest altogether.

>> I'm not looking at messages with these headers anyways, because they are
>> meaningless. People with incapable mailers deserve to suffer more than
>> those with capable mailers, and they can always switch to the plain
>> version, or split the digest up with maildrop or procmail helper
>> programs.
>
> Or simply copy-n-paste the correct subject when hitting reply :)

That won't do. People who reply to -digest posts 1. often hijack
threads, 2. break threading. Followups to my posts (as per In-Reply-To
or References) will appear in boldface and in the same thread. Just
pasting the right subject on the reply to the digest will break
threading and such followup hiliting.

Given that I'm one of the de-facto unpaid support guys, I decide what
hoops people can expect me to jump, and breaking threads, replying to
digest and other shipwrecks is expecting too much.

I expect proper mail formatting as "payment" for my spare time.

I've taken the liberty to change Subject, so it will pass my filter.

-- 
Matthias Andree

Re: [fetchmail-users] Please blacklist Subject "fetchmail-users digest..."

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

Rob Funk <rf...@fu...> writes:

> Matthias Andree wrote:
>> BTW, can the list filters please be adjusted so as to ban + reject
>> "fetchmail-users digest" in subjects?
>
> You do realize that under such a policy, your message (and this reply) 
> would be rejected.... :-)

Yes, I do. It doesn't matter, because we don't have such list messages
under such a policy.

> Ah, but others here are.  I don't see any need for any one person to look 
> at all the threads.

I'm filtering such subjects now. If someone feels he's found a bug,
he'll have to use a more catchy subject if he wants me to see the post
(or perhaps file a bug at the berlios tracker).

>> People with incapable mailers deserve to suffer more than 
>> those with capable mailers, and they can always switch to the plain
>> version, or split the digest up with maildrop or procmail helper
>> programs.
>
> On the -users list I don't see much reason for being too strict or telling 
> people they're using the wrong MUA.  (This isn't linux-elitists, after 
> all.)  I could see an argument for it on -devel, but it hasn't been an 
> issue there.

It's impolite to send messages to lists with meaningless subjects, and
people with inferior mailers and without a chance to split the digest up
locally still have the option to switch their subscription to the
"plain" format.

-- 
Matthias Andree

[fetchmail-users] Re: Please blacklist Subject "fetchmail-users digest..."

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

On 08/01/06, Matthias Andree <mat...@gm...> wrote:
> BTW, can the list filters please be adjusted so as to ban + reject
> "fetchmail-users digest" in subjects?

It doesn't look like mailman can handle this.  The closest it comes is
allowing you to make a subject with that line a spam marker, which
then requires an admin to review and act upon - a less than ideal
approach.

If anybody knows an approach that will simply bounce then I'll happily
look into it.  I'd rather not simply mark them as spam as they'll
likely simply get overlooked and dropped on the floor (as does pretty
much every mail caught by the spam filters).

> I'm not looking at messages with these headers anyways, because they are
> meaningless. People with incapable mailers deserve to suffer more than
> those with capable mailers, and they can always switch to the plain
> version, or split the digest up with maildrop or procmail helper
> programs.

Or simply copy-n-paste the correct subject when hitting reply :)

--
                 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] Please blacklist Subject "fetchmail-users digest..."

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

Matthias Andree wrote:
> BTW, can the list filters please be adjusted so as to ban + reject
> "fetchmail-users digest" in subjects?

You do realize that under such a policy, your message (and this reply) 
would be rejected.... :-)

> I'm not looking at messages with these headers anyways, because they are
> meaningless.

Ah, but others here are.  I don't see any need for any one person to look 
at all the threads.

> People with incapable mailers deserve to suffer more than 
> those with capable mailers, and they can always switch to the plain
> version, or split the digest up with maildrop or procmail helper
> programs.

On the -users list I don't see much reason for being too strict or telling 
people they're using the wrong MUA.  (This isn't linux-elitists, after 
all.)  I could see an argument for it on -devel, but it hasn't been an 
issue there.


I'm more interested in getting people to actually subscribe to the list 
before getting into conversations on it.

-- 
==============================|   "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-users] Please blacklist Subject "fetchmail-users digest..."

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

BTW, can the list filters please be adjusted so as to ban + reject
"fetchmail-users digest" in subjects?

I'm not looking at messages with these headers anyways, because they are
meaningless. People with incapable mailers deserve to suffer more than
those with capable mailers, and they can always switch to the plain
version, or split the digest up with maildrop or procmail helper
programs.

One example for a capable mailer is Gnus, press Ctrl+D on the digest and
see individual messages you can reply to, with proper headers.

Thanks,

-- 
Matthias Andree

Re: [fetchmail-users] Re: fetchmail-users digest, Vol 1 #39 - 2 msgs

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

On 08/01/06, pongthep <pkr...@eg...> wrote:
> Sorry for dumping old thread.
> After failing with fetchmail 6.2.2 and retrieved mails with telnet for a while.
> Now I turn into FreeBSD5.4 with fetchmail 6.2.5 (old already).
> Same configuration, which did not work with fetchmail 6.2.2, works very nice with new fetchmail 6.2.5.

I'd advise using fetchmail from ports - it's always worked fine for
me.  Then you can easily script checking for new versions and pulling
the distfiles down ready for you to compile them.

That and upgrading to 6.3.1 to avoid all those nasty security problems :-)

--
                 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-users] Re: fetchmail-users digest, Vol 1 #39 - 2 msgs

[pongthep <pkr...@eg...>]

Sorry for dumping old thread.
After failing with fetchmail 6.2.2 and retrieved mails with telnet for a while.
Now I turn into FreeBSD5.4 with fetchmail 6.2.5 (old already).
Same configuration, which did not work with fetchmail 6.2.2, works very nice with new fetchmail 6.2.5.
So it seems my old fetchmail 6.2.2 was buggy or something wrong with that.
Just for your information.

thanks for all of your help :)

pongthep

* pongthep (pkr...@eg...) wrote:
> > However, some ISPs require you to login with your email address as the
> > username, so you might try putting "user my...@is..." in your
> > fetchmailrc instead of "user myname".
> > 
> > But this is all questions between you and your ISP.
> 
> I've tried "user my...@is..."
> resulting in:
> 
> fetchmail: 6.2.2 querying mail.isp.com (protocol POP3) at Sun Oct  2 00:32:28 2005: poll started
> fetchmail: POP3< +OK Hello there.
> fetchmail: POP3> CAPA
> fetchmail: POP3< +OK Here's what I can do:
> fetchmail: POP3< STLS
> fetchmail: POP3< TOP
> fetchmail: POP3< USER
> fetchmail: POP3< LOGIN-DELAY 10
> fetchmail: POP3< PIPELINING
> fetchmail: POP3< UIDL
> fetchmail: POP3< IMPLEMENTATION Courier Mail Server
> fetchmail: POP3< .
> fetchmail: POP3> STLS
> fetchmail: POP3< +OK Begin SSL/TLS negotiation now.
> fetchmail: POP3> CAPA
> fetchmail: POP3> USER my...@is...
> fetchmail: POP3> PASS 
> fetchmail: Unknown login or authentication error on my...@is...@mail.isp.com
> fetchmail: POP3> QUIT
> fetchmail: 6.2.2 querying mail.isp.com (protocol POP3) at Sun Oct  2 00:32:29 2005: poll completed
> fetchmail: Query status=15
> fetchmail: normal termination, status 15
> 
> "my...@is...@mail.isp.com" does not make any sense.
> i'm sure that my config i.e. username and password are correct.
> perhaps i have to be away from fetchmail, telnet can do it also.
> anyway, thank you very much.

----- End forwarded message -----

[fetchmail-users] Re: fetchmail 6.3.0 contained incompatible idfile change

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

Simon Barner <ba...@gm...> writes:

> Do you think, a system-wide fetchmail is worth the trouble? (I know, you are
> biased since you are the current maintainer ;-)

Well, the "trouble" is having a working local SMTP or LMTP package
installed and adding an unprivileged fetchmail user and chrooting
fetchmail along with the needed libraries (DNS!) and picking sensible
defaults. The Debian init script is a good starting point, but needs
minor touch-ups, for instance, the mentioned .fetchids placement.

-- 
Matthias Andree

Re: [fetchmail-users] Re: [fetchmail-announce] fetchmail 6.3.0 contained incompatible idfile change

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

On 05/01/06, Simon Barner <ba...@gm...> wrote:
>
> I thought about adding something similar to the FreeBSD port, but I thought
> of having one fetchmail instance per user (if that is possible). OTOH, this
> will not work if there are many users.
>
> Do you think, a system-wide fetchmail is worth the trouble? (I know, you are
> biased since you are the current maintainer ;-)

Personally, yes.  With the caveat that it only works if you're not
making lots of changes.  If things are relatively static then it works
well.

If nothing else it stops the users from deleting or messing up their
fetchmail config files themselves, and ensures you avoid hammering POP
servers with lots of simultaneous connections.

--
                 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] Re: [pkg-fetchmail-maint] fetchmail 6.3.0 contained incompatible idfile change

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

Nico Golde <ni...@ng...> writes:

> Hallo Matthias,
>
> * Matthias Andree <mat...@gm...> [2006-01-05 14:47]:
>> in the original 6.3.0 announcement, I mentioned that we're more careful
>> about writing the .fetchids file. While this is true, the change
>> introduced a minor incompatibility.
>
> [...] 
> sorry, hab gerade probleme das nachzuvollziehen, kannst du 
> mir das nochmal auf deutsch erklären?

(he asked for a German explanation, so here goes)

Seit 6.3.0 schreibt fetchmail sein $idfile nicht mehr direkt, was zur
Trunkierung zum Beginn des Schreibens führt, sondern zunächst in eine
temporäre Datei, die später per rename() das eigentliche idfile ersetzt.

Früher konnte man - wie es Debian tut, einfach fetchmail eine ID-Datei
geben, die den passenden Besitzer hat; das hat jedoch immer wieder dazu
geführt, dass Leute viele Nachrichten mehrfach abholen mussten, wenn
fetchmail gecrasht ist, die Partition für's idfile voll war oder die
quota erschöpft etc.

Wegen des rename() und dem Anlegen der temporären Datei ist nötig, dass
fetchmail Schreibzugriff auf das Verzeichnis hat.

Das Grundproblem ist, dass das Debian-Startskript fetchmails idfile
nicht unterhalb /var/run/fetchmail (= ~fetchmail) anlegt, sondern in
/var/mail, wo fetchmail m. E. (ich hab' kein Debian) nicht schreiben
darf. Wenn Ihr das ändert, müsst Ihr im postinstall die Datei noch vom
alten Ort an den neuen verschieben, sonst zürnen Euch Eure User :-)

-- 
Matthias Andree

Re: [fetchmail-users] Re: [fetchmail]fetchmail 6.3.0 contained incompatible idfile change

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

Dembe <da...@de...> writes:

> We hadn't spotted this and so presumably our .fetchids file hasn't been
> updated. However, we've also not had any errors in the logs saying that
> fetchmail couldn't update the .fetchids file (our system is stable so we
> don't run fetchmail with any -v 's). Shouldn't this perhaps be put forward
> as a change for a next version so that if fetchmail doesn't have access
> to the .fetchids file, a warning error is logged (even if the debug
> options aren't being explicitly enabled)?

David,

fetchmail should be doing exactly that, log and print on standard error
messages like "Cannot open fetchids file ... for writing" or "Cannot
rename fetchids file ... to ..." and the like. I've checked this, it
works for me in 6.3.2-rc1.

The problem only matters for system-wide installs that pass an UIDL file
to fetchmail that is in a directory where the fetchmail user has no
write permission.  End-user installs and system-wide installs that leave
the default --idfile are unaffected by the change, as these have write
permission in their respective home directory.

I issued the report since Debian is known to put the UID file in a
directory that the fetchmail user cannot write, so they're going to fail
when they upgrade.

Note the error messages will appear localized when fetchmail is started
with LANG or LC_MESSAGES environment variables set.

HTH,

-- 
Matthias Andree

[fetchmail-users] Re: [fetchmail]fetchmail 6.3.0 contained incompatible idfile change

[Dembe <da...@de...>]

Matthias Andree wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Beginning with release 6.3.0, fetchmail needs not only need write access
>to the idfile ($HOME/.fetchids), but also to the directory holding this
>file. fetchmail 6.2.X and older versions got away if just the idfile had
>write permission.
>
We hadn't spotted this and so presumably our .fetchids file hasn't been
updated. However, we've also not had any errors in the logs saying that
fetchmail couldn't update the .fetchids file (our system is stable so we
don't run fetchmail with any -v 's). Shouldn't this perhaps be put forward
as a change for a next version so that if fetchmail doesn't have access
to the .fetchids file, a warning error is logged (even if the debug
options aren't being explicitly enabled)?

Thanks, David

[fetchmail-users] Re: [pkg-fetchmail-maint] fetchmail 6.3.0 contained incompatible idfile change

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

Hallo Matthias,

* Matthias Andree <mat...@gm...> [2006-01-05 14:47]:
> in the original 6.3.0 announcement, I mentioned that we're more careful
> about writing the .fetchids file. While this is true, the change
> introduced a minor incompatibility.

[...] 
sorry, hab gerade probleme das nachzuvollziehen, kannst du 
mir das nochmal auf deutsch erklären?
gruß nico
-- 
Nico Golde - JAB: ni...@ja... | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org
Forget about that mouse with 3/4/5 buttons -
gimme a keyboard with 103/104/105 keys!

[fetchmail-users] Re: [fetchmail]fetchmail 6.3.0 contained incompatible idfile change

[Dembe <da...@de...>]

Matthias Andree wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Beginning with release 6.3.0, fetchmail needs not only need write access
>to the idfile ($HOME/.fetchids), but also to the directory holding this
>file. fetchmail 6.2.X and older versions got away if just the idfile had
>write permission.
>
We hadn't spotted this and so presumably our .fetchids file hasn't been 
updated. However, we've also not had any errors in the logs saying that 
fetchmail couldn't update the .fetchids file (our system is stable so we 
don't run fetchmail with any -v 's). However, shouldn't this perhaps be 
put forward as a change for a next version so that fetchmail doesn't 
have access to the .fetchids file a warning error is logged (even 
without the debug options being enabled)?

Thanks, David