fetchmail-users — User questions and discussion

Re: [fetchmail-users] fetchmail at system startup

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

On 3/26/07, Joe Acquisto <jo...@j4...> wrote:
>
> Ah.  Well.  Point taken.  This is a SUSE SLES 9 install with their provided
> version of fetchmail.

Which could be any version, but fortunately that isn't important.

> The startup script does show it is looking for /etc/fetchmailrc.  But, it seems I recall clearly
> that I got this running, logged in as root, only after creating .fetchmailrc in root's home.
>
> fetchmailconfig did that, I believe.

Just keep in mind that any vaguely modern version of fetchmail will
warn you about running as root and future versions will refuse to run.

> I supposed that  during system startup the script at /etc/init.d will run (called via /etc/init.d/rc(x).d) while saying "fetchmail" while logged in, does the deed via /usr/sbin/fetchmail.  ?

If I understand you correctly, yes.  I'd suggest you take a look at
the init script yourself to see what it does and how.

-- 
                 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] fetchmail at system startup

[Joe A. <jo...@j4...>]

"Rob MacGregor" <rob...@gm...> Wrote: 3/25/2007 4:19 PM:
> On 3/25/07, Joe Acquisto <jo...@j4...> wrote:
>> My first foray into fetchmail.  Seem to have configured it properly, by 
>> some happenstance.  Even runs at system startup, as if I know what I was 
>> doing.  And that is certainly not certain.
>>
>> However, I am given pause.  I am a bit puzzled how one can specify an 
>> alternate startup file, within the startup file (--fetchmailrc = 
>> path/file).   A circular argument kind of thing.
>>
>> When I first started it (fetchmail, via system startup) it complained (from 
>> logs) that it could not find /etc/fetchmailrc.  Thinking that a typo, and 
>> having an "aha" moment regarding my above pondering, I copied my 
>> /root/.fetchmailrc to /etc/.  Alas, it still complained, so I renamed it, 
>> leaving off the leading ".".
>>
>> Now it seems to be quite happy reading /etc/fetchmailrc.  But I am not 
>> certain why.  Or if it is only reading that to find the "real" config file. 
>>  I hesitate to start hacking to find out, as it takes several minutes for 
>> this older Dell Poweredge to start up.  Boring.
> 
> My crystal ball tells me you're probably running some form of Linux
> and have some version of fetchmail installed, possibly from a binary
> package...
>
> Seriously, if you want help you need to provide information.  At the
> very least you need to fill in the blanks above.

Ah.  Well.  Point taken.  This is a SUSE SLES 9 install with their provided
version of fetchmail.

> Now, if you're running Linux then you'll most likely find the startup
> script as /etc/init.d/fetchmail.  If you look at that script you'll
> find what your package provider has set as the defaults for that
> build.

The startup script does show it is looking for /etc/fetchmailrc.  But, it seems I recall clearly
that I got this running, logged in as root, only after creating .fetchmailrc in root's home.

fetchmailconfig did that, I believe.

I supposed that  during system startup the script at /etc/init.d will run (called via /etc/init.d/rc(x).d) while saying "fetchmail" while logged in, does the deed via /usr/sbin/fetchmail.  ?

One learns by doing.

joe a.
 

Re: [fetchmail-users] fetchmail at system startup

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

On 3/25/07, Joe Acquisto <jo...@j4...> wrote:
> My first foray into fetchmail.  Seem to have configured it properly, by some happenstance.  Even runs at system startup, as if I know what I was doing.  And that is certainly not certain.
>
> However, I am given pause.  I am a bit puzzled how one can specify an alternate startup file, within the startup file (--fetchmailrc = path/file).   A circular argument kind of thing.
>
> When I first started it (fetchmail, via system startup) it complained (from logs) that it could not find /etc/fetchmailrc.  Thinking that a typo, and having an "aha" moment regarding my above pondering, I copied my /root/.fetchmailrc to /etc/.  Alas, it still complained, so I renamed it, leaving off the leading ".".
>
> Now it seems to be quite happy reading /etc/fetchmailrc.  But I am not certain why.  Or if it is only reading that to find the "real" config file.  I hesitate to start hacking to find out, as it takes several minutes for this older Dell Poweredge to start up.  Boring.

My crystal ball tells me you're probably running some form of Linux
and have some version of fetchmail installed, possibly from a binary
package...

Seriously, if you want help you need to provide information.  At the
very least you need to fill in the blanks above.

Now, if you're running Linux then you'll most likely find the startup
script as /etc/init.d/fetchmail.  If you look at that script you'll
find what your package provider has set as the defaults for that
build.

Oh, and when any program complains about the lack of a given file,
it's unlikely to be a typo :)

-- 
                 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] fetchmail at system startup

[Joe A. <jo...@j4...>]

My first foray into fetchmail.  Seem to have configured it properly, by some happenstance.  Even runs at system startup, as if I know what I was doing.  And that is certainly not certain.

However, I am given pause.  I am a bit puzzled how one can specify an alternate startup file, within the startup file (--fetchmailrc = path/file).   A circular argument kind of thing.
 
When I first started it (fetchmail, via system startup) it complained (from logs) that it could not find /etc/fetchmailrc.  Thinking that a typo, and having an "aha" moment regarding my above pondering, I copied my /root/.fetchmailrc to /etc/.  Alas, it still complained, so I renamed it, leaving off the leading ".".   

Now it seems to be quite happy reading /etc/fetchmailrc.  But I am not certain why.  Or if it is only reading that to find the "real" config file.  I hesitate to start hacking to find out, as it takes several minutes for this older Dell Poweredge to start up.  Boring.

Thanks for any assistance.

joe a.

Re: [fetchmail-users] fetchmail and socks5

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

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

> I'd be tempted to go with your second paragraph - if fetchmail is
> linked with the socks libraries *and* the required socks config file
> is in place then, by default, use socks.  As long as there is a
> command line argument to either disable socks or use an alternative
> socks config file (which implicitly enables socks) then that should be
> fine.

I have decided to do exactly that, even if it causes pain to those who
experiment with socks -- IOW, if you leave shards lying around, wear
tough shoes.

>> Not my essay, and I'm not enthusiastic about several of the assumptions
>> fetchmail makes, and I'm still pondering whether a complete redesign is
>> more of an effort than rewriting existing code...
>
> Which is more effort to maintain :)

Need not be your concern though. 8-)

> It probably wouldn't hurt for the --configdump option to include the
> fact that socks is compiled in - which, in theory, is little more
> than:
>
> #ifdef HAVE_SOCKS
>     "'socks',"
> #endif
>
> after line 186 of conf.c

Done for 6.3.8. Thanks for the report.

-- 
Matthias Andree

Re: [fetchmail-users] Fetchmail 6.3.7+NLS not deleting one specific message from server

[Chris <cpo...@ea...>]

On Thursday 22 March 2007 2:00 am, Rob MacGregor wrote:
> On 3/22/07, Chris <cpo...@ea...> wrote:
> > I think though that the key may be the "socket error while fetching from
> > cpo...@po...". It appears to my untrained eye that the
> > connection was dropped while fetching this particular message?
>
> Yes, and if it (the dropping of the connection upon issuing the DEL
> command) happens each time with the same email then I'd suspect that
> their POP server is badly broken.

Everything at Earthlink is badly broken, mail, usenet, techsupport and so 
forth.  
>
> > I also see, I
> > think, how UIDL comes into play. Each message is assigned a unique ID.
> > For instance, the 'bad' message above has an UIDL of 1huc3u2DT3Nl36v1,
> > and looking at the .fetchids file I see cpo...@po...
> > 1huc3u2DT3Nl36v1. Once I delete that message from the server the
> > .fetchids file is removed since all messages have been downloaded. Makes
> > sense.
>
> Glad it's all working for you.

Me too Rob, and thanks very much for your help. I've the FAQ bookmarked now 
and if/when I have another problem thats the very *first* place I'll check 
for a solution.

-- 
Chris
KeyID 0xE372A7DA98E6705C

Re: [fetchmail-users] Fetchmail 6.3.7+NLS not deleting one specific message from server

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

On 3/22/07, Chris <cpo...@ea...> wrote:

> I think though that the key may be the "socket error while fetching from
> cpo...@po...". It appears to my untrained eye that the
> connection was dropped while fetching this particular message?

Yes, and if it (the dropping of the connection upon issuing the DEL
command) happens each time with the same email then I'd suspect that
their POP server is badly broken.

> I also see, I
> think, how UIDL comes into play. Each message is assigned a unique ID. For
> instance, the 'bad' message above has an UIDL of 1huc3u2DT3Nl36v1, and
> looking at the .fetchids file I see cpo...@po...
> 1huc3u2DT3Nl36v1. Once I delete that message from the server the .fetchids
> file is removed since all messages have been downloaded. Makes sense.

Glad it's all working for you.

-- 
                 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] Fetchmail 6.3.7+NLS not deleting one specific message from server

[Chris <cpo...@ea...>]

On Wednesday 21 March 2007 5:54 pm, Rob MacGregor wrote:
> On 3/21/07, Chris <cpo...@ea...> wrote:
> > Robb, I tried replying to this last night, when I got home from work
> > today I had this:
> >
> > The message's content type was not explicitly allowed
> >
> > Along with the signed message I'd sent encapsulated. I guess signed
> > messages are no longer allowed?
>
> There's been a problem of people sending HTML only emails to the list
> lately, resulting in the allowed types being clamped down on.  If you
> can did out the MIME type for the signed email I'll see about adding
> it to the list of allowed types.

I'll have to see if I can figure it out. This is probably not it but according 
to Kmail its OpenPGP/MIME.
>
> > Anyway, here is what I sent:
> >
> > Thanks Rob, I'll have to wait until another message gets stuck on the
> > server at earthlink to send the output. I did change logging from syslog
> > to a seperate fetchmaillog file, that should make things easier when it
> > happens again. I've also enabled uidl. One probably dumb question though,
> > when you say "don't use "-m procmail" but deliver directly to your SMTP
> > server" what do you mean?
>
> Well, by default fetchmail will try to connect to an SMTP on loopback.
>  If you're running an SMTP server
> (sendmail/postfix/exim/qmail/whatever) then you can have fetchmail
> just pass the email on to it.
>
> (If that's equally as clear as mud let me know - it's getting a late here
> :>)

I have courier-imap running and have Kmail setup using an IMAP account. 
Procmail tosses into the maildir folders I have setup. 

-- 
Chris
KeyID 0xE372A7DA98E6705C

Re: [fetchmail-users] Fetchmail 6.3.7+NLS not deleting one specific message from server

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

On 3/21/07, Chris <cpo...@ea...> wrote:
>
> Robb, I tried replying to this last night, when I got home from work today I
> had this:
>
> The message's content type was not explicitly allowed
>
> Along with the signed message I'd sent encapsulated. I guess signed messages
> are no longer allowed?

There's been a problem of people sending HTML only emails to the list
lately, resulting in the allowed types being clamped down on.  If you
can did out the MIME type for the signed email I'll see about adding
it to the list of allowed types.

> Anyway, here is what I sent:
>
> Thanks Rob, I'll have to wait until another message gets stuck on the server
> at earthlink to send the output. I did change logging from syslog to a
> seperate fetchmaillog file, that should make things easier when it happens
> again. I've also enabled uidl. One probably dumb question though, when you
> say "don't use "-m procmail" but deliver directly to your SMTP server" what
> do you mean?

Well, by default fetchmail will try to connect to an SMTP on loopback.
 If you're running an SMTP server
(sendmail/postfix/exim/qmail/whatever) then you can have fetchmail
just pass the email on to it.

(If that's equally as clear as mud let me know - it's getting a late 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-users] Fetchmail 6.3.7+NLS not deleting one specific message from server

[Chris <cpo...@ea...>]

On Wednesday 21 March 2007 2:04 am, Rob MacGregor wrote:
> On 3/21/07, Chris <cpo...@ea...> wrote:
> > I reported this back on the 11th of March, since then I've upgraded to
> > what I understand is the latest version. Looking at the required
> > information for a problem in the FAQ I'll try to provide it:
>
> Thanks for all that.  Typically there was still one thing that the FAQ
> doesn't ask for that would have helped :)  Can you provide the output
> of "fetchmail -v -v -v -m procmail" for the problem email (that
> should, hopefully, show what's happening).
>
> You may find that enabling UIDL support helps as it moves to problem
> of tracking seen emails from the server to fetchmail.
>
> It may be that the problem will go away if you don't use "-m procmail"
> but deliver directly to your SMTP server, but that's just a guess.

Robb, I tried replying to this last night, when I got home from work today I 
had this:

The message's content type was not explicitly allowed

Along with the signed message I'd sent encapsulated. I guess signed messages 
are no longer allowed? Anyway, here is what I sent:

Thanks Rob, I'll have to wait until another message gets stuck on the server 
at earthlink to send the output. I did change logging from syslog to a 
seperate fetchmaillog file, that should make things easier when it happens 
again. I've also enabled uidl. One probably dumb question though, when you 
say "don't use "-m procmail" but deliver directly to your SMTP server" what 
do you mean?

Chris
-- 
Chris
KeyID 0xE372A7DA98E6705C

Re: [fetchmail-users] Block email downloading using fetchmail and multidrop

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

On 3/21/07, Santa Clause <fu...@ho...> wrote:
> HI
> Please could you let me know if the following is possiable and how to do it.
>
> I am using fetchmail to download email from a "catchall account" at our isp.
> I want to know if it is possiable to block / delete a user when it is
> downloaded by fetchmail. The user must still be able to send and receive
> mail on the local server.

I'm not sure what you're asking.

As you asking - is it possible to stop a user directly connecting to
the remote POP server?

That, and the configuration of your local mail server, is nothing to
do with fetchmail.  To achieve that you'll need to configure your
firewall to only allow the host running fetchmail access to the POP
server.

-- 
                 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] Block email downloading using fetchmail and multidrop

[Santa C. <fu...@ho...>]

HI
Please could you let me know if the following is possiable and how to do it.

I am using fetchmail to download email from a "catchall account" at our isp. 
I want to know if it is possiable to block / delete a user when it is 
downloaded by fetchmail. The user must still be able to send and receive  
mail on the local server.

This is my fetchmail.cron file (Runs every 10min)

fetchmail -f /etc/fetchmailrc
if [ $? = 0 ]
then
echo "Mail completed at `date`">>/etc/mail/fetchmail.log
elif [ $? = 1 ]
then
echo "No mail to retrieve at `date`">>/etc/fetchmail.log
fi


This is my fetchmail rc file:

set postmaster (ro...@co...)
set bouncemail
set properties ""
poll pop.connoisseur.co.za
protocol POP3
nodns
localdomains connoisseur.co.za
username web...@co... password mxg123 to * here
smtp 192.1.1.240
fetchall
forcecr


regards
Fution

_________________________________________________________________
Message offline contacts without any fire risk! 
http://www.communicationevolved.com/en-za/

Re: [fetchmail-users] Fetchmail 6.3.7+NLS not deleting one specific message from server

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

On 3/21/07, Chris <cpo...@ea...> wrote:
> I reported this back on the 11th of March, since then I've upgraded to what I
> understand is the latest version. Looking at the required information for a
> problem in the FAQ I'll try to provide it:

Thanks for all that.  Typically there was still one thing that the FAQ
doesn't ask for that would have helped :)  Can you provide the output
of "fetchmail -v -v -v -m procmail" for the problem email (that
should, hopefully, show what's happening).

You may find that enabling UIDL support helps as it moves to problem
of tracking seen emails from the server to fetchmail.

It may be that the problem will go away if you don't use "-m procmail"
but deliver directly to your SMTP server, but that's just a guess.

-- 
                 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] Fetchmail 6.3.7+NLS not deleting one specific message from server

[Chris <cpo...@ea...>]

I reported this back on the 11th of March, since then I've upgraded to what I 
understand is the latest version. Looking at the required information for a 
problem in the FAQ I'll try to provide it:

   1. Your operating system

Mandrake Linux 10.1 (Official) kernel 2.6.8.1-12mdk

   2. Your compiler version, if you built from source; otherwise, the name and 
origin of the RPM or other binary package you installed.

gcc (GCC) 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)
(hopfully this is whats being asked for, this came from my config.log)

   3. A copy of your POP or IMAP server's greeting line.

220-elasmtp-masked.atl.sa.earthlink.net ESMTP Exim 4.34 #1 Tue,
20 Mar 2007 20:22:57 -0400..
220-NO UCE.  EarthLink does not authorize the use of its computers or 
network..
220 equipment to accept, transmit, or distribute unsolicited e-mail..
(I hope the above is whats wanted)
                                       .
   4. The name and version of the SMTP listener or MDA you are forwarding to.

      Procmail 3.22

   5. Any command-line options you used.

     I usually just use $fetchmail -m procmail

   6. The output of fetchmail -V called with whatever other command-line 
options you used. (I've added in the -v -v -v yesterday evening)

[chris@cpollock ~]$ fetchmail -V -v -v -v -m procmail
This is fetchmail release 6.3.7+NLS.

Copyright (C) 2002, 2003 Eric S. Raymond
Copyright (C) 2004 Matthias Andree, Eric S. Raymond, Rob F. Funk, Graham 
Wilson
Copyright (C) 2005-2006 Sunil Shetye
Copyright (C) 2005-2007 Matthias Andree
Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. For details,
please see the file COPYING in the source or documentation directory.

Fallback MDA: (none)
Linux cpollock 2.6.8.1-12mdk #1 Fri Oct 1 12:53:41 CEST 2004 i686 AMD 
Sempron(tm) Processor 2800+ unknown GNU/Linux
Taking options from command line and /home/chris/.fetchmailrc
Poll interval is 120 seconds
Idfile is /home/chris/.fetchids
Progress messages will be logged via syslog
Fetchmail will forward misaddressed multidrop messages to cpollock.
Fetchmail will direct error mail to the postmaster.
Options for retrieving from cpo...@po...:
  True name of server is pop.earthlink.net.
  This host will be queried when no host is specified.
  Password = "*********".
  Protocol is POP3 (using default port).
  All available authentication methods will be tried.
  Server nonresponse timeout is 180 seconds.
  Default mailbox selected.
  Only new messages will be retrieved (--all off).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush off).
  Oversized messages will not be flushed before message retrieval 
(--limitflush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is enabled (stripcr on).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  No received-message limit (--fetchlimit 0).
  Fetch message size limit is 100 (--fetchsizelimit 100).
  Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4).
  No SMTP message batch limit (--batchlimit 0).
  No forced expunges (--expunge 0).
  Messages will be delivered with "procmail".
  Spam-blocking disabled
  No pre-connection command.
  No post-connection command.
  Single-drop mode: 1 local name recognized.
        cpollock
  No interface requirement specified.
  No monitor interface specified.
  No plugin command specified.
  No plugout command specified.
  No UIDs saved from this host.
  No poll trace information will be added to the Received header.

The below headers are for the message that was downloaded over 50 times 
yesterday without being deleted from earthlinks server, I had to manually 
delete it. 

Return-Path: <tod...@lo...>
 Received: from pop00.earthlink.net [209.86.93.201] 
        by localhost.localdomain with POP3 (fetchmail-6.3.7) 
        for <cpollock@localhost> (single-drop); Mon, 19 Mar 2007 15:07:01 
-0500 (CDT)
 Received: from noehlo.host ([127.0.0.1]) 
        by mx-mcdonald.atl.sa.earthlink.net (EarthLink SMTP Server) with SMTP 
id 1hto6T1sB3Nl36F0; Mon, 19 Mar 2007 16:05:39 -0400 (EDT)
 Received: from localhost ([62.97.195.108]) 
        by mx-mcdonald.atl.sa.earthlink.net (EarthLink SMTP Server) with SMTP 
id 1hto6QAx3Nl36F0 
        for <cpo...@ea...>; Mon, 19 Mar 2007 16:05:39 -0400 (EDT)
 Message-ID: <000001c76a61$9820b200$0100007f@localhost>
 From: "Arthur Davis" <tod...@lo...>
 To: <cpo...@ea...>
 Subject: Photoshop, Windows, Office
 Date: Mon, 19 Mar 2007 21:08:30 +0100
 Content-Type: text/plain; 
        charset="us-ascii"
 Content-Transfer-Encoding: 7bit
 X-Priority: 3 (Normal)
 X-MSMail-Priority: Normal
 X-Mailer: Microsoft Outlook, Build 10.0.2520
 Importance: Normal
 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.0000
 X-ELNK-Info: sbv=0; sbrc=.0; sbf=00; sbw=000;
 X-SenderIP: 62.97.195.108
 X-ASN: ASN-8542
 X-CIDR: 62.97.192.0/18

One other thing of note, 

Mar 19 15:07:17 localhost spamd[22069]: dkim: lookup failed: DNS query timeout 
for _policy._domainkey.localwebshopping.com 
Mar 19 15:11:25 localhost spamd[22069]: dkim: lookup failed: DNS query timeout 
for _policy._domainkey.localwebshopping.com 

The above was logged every time fetchmail poll'd the server. I doubt whether 
its a fetchmail problem but maybe someone can give me a clue as to what may 
be the cause. The happens very seldom but when it does the bad message blocks 
all other message downloads except itself.

Thanks, and I hope I provided the correct information above. If I didn't 
someone please let me know what I should have included.

Chris

-- 
Chris
KeyID 0xE372A7DA98E6705C

Re: [fetchmail-users] fetchmail and socks5

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

Jochen Hayek schrieb:

>> On 3/18/07, Matthias Andree <mat...@gm...> wrote:
> 
>     MA> That's the distributor's business, 
>     MA> not that of the fetchmail maintainers.
> 
> Well I think, at the end of the day it's "the user's" problem,
> and I guess 99% of the fetchmail users employ a ready-made installation,
> and fetchmail is giving them grief, if it assumes uncomfortable defaults.

Sorry to those who are bored by this discussion, but as this is still
boiling, I must conclude the participants are unhappy with the state of
the discussion. Let's try to break this down to objective criteria and
understand the actual cause of these emotions.

Up front, maintainers are loathe to change system behavior, because that
causes users pain, causes complaints, support work and all else we don't
want. Trying to satisfy contradictory requirements leads either to a
majority vote, a maintainer vote, or a configuration option.

We know the configuration option at run-time isn't feasible beyond
SOCKS_CONF -- which itself invalidates the need for a
command-line/rcfile option in fetchmail.

The questions I'm having:

1. What good is SOCKS, anyways?
   Why use SOCKS if I can have IPFW, IPFW2, PF, netfilter?

2. What was the original problem or surprise?
   You configured socks, which implies assigning socks proxies to
   certain destination addresses/networks.
   Your proxy went down, so you could not connect. So what?
   In SOCKS scenarios, the SOCKS proxy is the interface to the outside
   world, and indispensable in such configurations.
   Not a surprise to me.

   If there is a relevant standard (IETF, LSB, IEEE...) that states how
   socks-enabled applications should behave, I'll reconsider.

3. What is the scenario in production where each application had its own
   socks configuration? In what way is the SOCKS_CONF
   configuration mechanism insufficient?

   Why do you think fetchmail should try to be smarter than the user and
   stomp over his environment variables or configuration files?

4. Would not it be more fruitful if the end user talked to the
   distributor who packaged fetchmail with the *nondefault*
   --with-socks[5] option rather than offering socksify or similar?

   The upstream default - at compile time - already is "no socks".

> Obviously everybody may have his/her own position on what is (un)comfortable in this respect.
> But maybe "relevance of positions" should somehow relate to "competence and experience in *the* area and *not* *just* in IT".

I understand your double frustration, first the socks irritations as
such, and then that the upstream maintainers we don't see reasons to
change existing code soon in spite of your desperate attempts to
convince them.

Note that invoking experience in a certain area isn't a valid reason to
support your suggestions. I'll rather look at objective arguments.

I hope to ground the unhealthy emotions from this discussion and get to
the core arguments.

Best,
Matthias

Re: [fetchmail-users] fetchmail and socks5

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

On 3/20/07, Jochen Hayek <Joc...@ha...> wrote:

> () Have you already been in a situation, where you were forced to use socks,
>    in order to overcome firewall restrictions?

And that's the scary part.  What you're saying (though I doubt it's
what you mean to say) is that you've used socks so you can completely
bypass your organisations IT security policy regarding Internet
traffic.

> Well I think, at the end of the day it's "the user's" problem,
> and I guess 99% of the fetchmail users employ a ready-made installation,
> and fetchmail is giving them grief, if it assumes uncomfortable defaults.

Sorry, but there is nothing either the author's or supporters of
fetchmail can do if distributors want to make their own non-standard
changes to fetchmail's configuration or compile in all the possible
libraries.  There is enough time taken up with helping people as it is
(not to mention the amount of time this thread has taken up).

I do agree that the socks situation could have been better documented,
both in the output of fetchmail's configdump and in the man page.
That however is within "our" control and is being resolved.

> Obviously everybody may have his/her own position on what is (un)comfortable in this respect.
> But maybe "relevance of positions" should somehow relate to "competence and experience in *the* area and *not* *just* in IT".

And an understanding that you're not always right, no matter how much
pain a problem may have caused you :)

-- 
                 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] fetchmail and socks5

[Jochen H. <Joc...@Ha...>]

>>>>> "MA" == Matthias Andree <mat...@gm...> writes:

> Jochen Hayek schrieb:

>>>>>>> Rob MacGregor writes:

>>> On 3/18/07, Matthias Andree <mat...@gm...> wrote:

    RM> if fetchmail is linked with the socks libraries
    RM> *and* the required socks config file
    RM> is in place then, by default, use socks.

    >> Pls remember: readymade distro fetchmails may come linked with the socks library,
    >> but its user is still quite likely not aware of it.

    MA> That's the distributor's business, 
    MA> not that of the fetchmail maintainers.

Well I think, at the end of the day it's "the user's" problem,
and I guess 99% of the fetchmail users employ a ready-made installation,
and fetchmail is giving them grief, if it assumes uncomfortable defaults.

Obviously everybody may have his/her own position on what is (un)comfortable in this respect.
But maybe "relevance of positions" should somehow relate to "competence and experience in *the* area and *not* *just* in IT".

--
Pls leave responses strictly on this mailing list!

Re: [fetchmail-users] fetchmail and socks5

[Jochen H. <Joc...@Ha...>]

>>>>> "RF" == Rob Funk writes:

> Jochen Hayek wrote:

    >> Trust me (pls!), neither explicit nor implicit sockisification
    >> *usually* work out of the box, ie. w/o changing the code,
    >> so somebody ("a user"), who "moves" into an enforced socks server
    >> environment, will have to try / verify socksification on every single
    >> application on its own, and not all at once by toggling the one and
    >> only global switch.

    RF> IMHO, the goal should be that configuring socks in one place 
    RF> makes it work everywhere.

() Have you already been in a situation, where you were forced to use socks,
   in order to overcome firewall restrictions?

() Have you ever (really) used a socks server?

() Did you experience trouble when doing so?

() Have you only just read an article on socks
   and are you presenting your ideas on that basis?

() Are you so much convinced of socks,
   that you recommended setting up a socks server
   to the IT dept. manager of the last bank you worked for?

    RF> [...]

Re: [fetchmail-users] Using LDAP for user account information

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

On 3/20/07, John <fet...@je...> wrote:
>
> I am building a server primarily for network users who won't have system
> accounts. Their mail will just be delivered to an IMAP server that they
> will log in to. All of their credientials are currently stored on LDAP
> and it is working fine. I want to use Fetchmail to allow users to
> request mail from external POP services and I want those users to be
> able to enter the details via a web front end that updates their LDAP
> profile. And then I want Fetchmail to get that configuration info for
> each user from LDAP.
>
> I was thinking in the most simplistic sense that the item in LDAP would
> just be a line exactly link I would enter in fetchmailrc and that
> fetchmail would just pull all such lines out of LDAP when reading its
> fetchmailrc file.

Ah, you'll have to write a script to do this I'm afraid.

Do keep in mind that if you run a single fetchmail instance then if
one of the servers being polled times out it'll impact all the other
polls as it's single threaded.  You may want to give some careful
thought to how to minimise that (the normal route of running fetchmail
as each user obviously won't work for you).

-- 
                 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] Using LDAP for user account information

[John <fet...@je...>]

Rob MacGregor wrote:
> On 3/18/07, John <fet...@je...> wrote:
>   
>> Is there an extension to Fetchmail that allows users' email account
>> details to be stored in their LDAP user profile and extracted by
>> Fetchmail rather than storing them in a fetchmailrc file ?
>>     
>
> ISTR somebody else asked this before and the answer then was no.  The
> problem is that you're usually only moving the admin problem from one
> place to another.
>
> Maybe if you said what you're trying to achieve somebody might be able to help.
>
>   
I am building a server primarily for network users who won't have system
accounts. Their mail will just be delivered to an IMAP server that they
will log in to. All of their credientials are currently stored on LDAP
and it is working fine. I want to use Fetchmail to allow users to
request mail from external POP services and I want those users to be
able to enter the details via a web front end that updates their LDAP
profile. And then I want Fetchmail to get that configuration info for
each user from LDAP.

I was thinking in the most simplistic sense that the item in LDAP would
just be a line exactly link I would enter in fetchmailrc and that
fetchmail would just pull all such lines out of LDAP when reading its
fetchmailrc file.

[fetchmail-users] fetchmail 6.3.8-rc2 release candidate

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

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

Greetings,

I have uploaded the second fetchmail 6.3.8 release candidate to the usual
download location: <http://home.pages.de/~mandree/fetchmail/>.

This release candidates adds strict verification of the POP3 APOP
timestamp for RFC-822 syntax to make an MD5 collision attack more
difficult - details:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
fetchmail 6.3.8 (not yet released) - CHANGES IN RC2 SINCE RC1

# SECURITY STRENGTHENING:
* Make the APOP challenge parser more distrustful and have it reject challenges
  that do not conform to RFC-822 msg-id format, in the hope to make mounting
  man-in-the-middle attacks (MITM) against APOP a bit more difficult.

  APOP is claimed insecure by Gaëtan Leurent for MITM scenarios for typical
  setups: based on MD5 collisions, it is purportedly possible to recover the
  first three characters of the shared secret (password), which would then make
  recovery of the shared secret a matter of hours or minutes; this would then
  enable the attacker to impersonate the client vis-à-vis the server.

  For further details, check
  * Gaëtan Leurent, "Message Freedom in MD4 and MD5 Collisions: Application
  to APOP", Fast Software Encryption 2007, Luxembourg. (Proceedings to appear in
  Springer's Lecture Notes on Computer Science.)
  * The mailing list discussion thread at
  <http://lists.berlios.de/pipermail/fetchmail-devel/2007-March/000887.html>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

WARNING: This message sets the Reply-To: header.
When replying to me personally, you need to edit the To: header!

Thank you.

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

iD8DBQFF/w9AvmGDOQUufZURAtWHAKCsM234Qe7gh8C9z1MsuH43wA4hiQCg0xOy
wrxZO6Dpj4P7XtDO4MuvzDo=
=5+Nu
-----END PGP SIGNATURE-----

Re: [fetchmail-users] SSL Ceritficate errors in sendmail log

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

Richard schrieb:
> Thanks Hannes
> 
> I am pretty confused about how the certificate stores work in Linux. The
> attached screenshot shows that firefox knows all about several Equifax
> certificates on the linux machine.
> 1) Does firefox have a separate store?

Yes.

> 3) How do the firefox certificates get there? I didn't manually load them.
> Do they come as part of the firefox pacjage?

Some do.

> 4) If I need to manually load the Equifax certificate into openssl - do you
> know where I get the Public Equifax certificate from?

Obviously from Equifax - any decent CA provides their root certificates
for public download.

> 5) I don't seem to have /etc/ssl. Any other guesses? How do I find out where
> the store is? I'm pretty sure openssl is installed.

Check the package list and look for a subdirectory named "certs".

Oh, and please trim your quotes next time.

HTH
MA

Re: [fetchmail-users] fetchmail and socks5

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

Jochen Hayek schrieb:
>>>>>> Rob MacGregor writes:
> 
>> On 3/18/07, Matthias Andree <mat...@gm...> wrote:
> 
>     RM> if fetchmail is linked with the socks libraries
>     RM> *and* the required socks config file
>     RM> is in place then, by default, use socks.
> 
> Pls remember: readymade distro fetchmails may come linked with the socks library,
> but its user is still quite likely not aware of it.

That's the distributor's business, not that of the fetchmail
maintainers. See - if they change the defaults, they need to support
those changes. And the default fetchmail compilation options DO NOT
include socks support.

We cannot afford - and I personally do not even want - to support every
compilation or perhaps patch variant there is in practice.

> I recently spent quite some hours (to be honest: far too many) on evaluating,
> whether and with which socks server certain applications like "wget" and "curl" work resp. don't work.

I understand your frustration, but what has this got to do with
fetchmail? I'm very much with Rob Funk here, if there is a system-wide
configuration, we should just use it -- the possibility for local
override is documented now.

> 
> Trust me (pls!), neither explicit nor implicit sockisification *usually* work out of the box,
> ie. w/o changing the code,
> so somebody ("a user"), who "moves" into an enforced socks server environment, 
> will have to try / verify socksification on every single application on its own,
> and not all at once by toggling the one and only global switch.

echo >>$HOME/.profile 'SOCKS_CONF=/dev/null ; export SOCKS_CONF'
. .profile

Csh left as an exercise to the reader.

> I seriously plea for: the default shall be: "off".

Noted for consideration for the fetchmail 6.4 branch.

Re: [fetchmail-users] SSL Ceritficate errors in sendmail log

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

On 3/19/07, Richard <rch...@aa...> wrote:
>
> Thanks Hannes
>
> I am pretty confused about how the certificate stores work in Linux. The
> attached screenshot shows that firefox knows all about several Equifax
> certificates on the linux machine.
> 1) Does firefox have a separate store?

Yes

> 2) Could these three certificates all be the wrong ones?
> 3) How do the firefox certificates get there? I didn't manually load them.
> Do they come as part of the firefox pacjage?

Yes

> 4) If I need to manually load the Equifax certificate into openssl - do you
> know where I get the Public Equifax certificate from?

You could export it from Firefox

> 5) I don't seem to have /etc/ssl. Any other guesses? How do I find out where
> the store is? I'm pretty sure openssl is installed.

You may still have to create the directory, or create a sym link to
it's true location (on my box I have a sym link from /etc/ssl/cert.pem
to /usr/local/share/certs/ca-cert.pem).

-- 
                 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] fetchmail and socks5

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

Jochen Hayek wrote:
> Trust me (pls!), neither explicit nor implicit sockisification
> *usually* work out of the box, ie. w/o changing the code,
> so somebody ("a user"), who "moves" into an enforced socks server
> environment, will have to try / verify socksification on every single
> application on its own, and not all at once by toggling the one and
> only global switch.

IMHO, the goal should be that configuring socks in one place makes it work 
everywhere.  No, that's not the current situation, but if I need socks 
then that's what I want.

Therefore, if I'm a user needing socks, I want to be able to set up 
socks.conf and have as much work with socks as possible.  I don't want to 
have to look for --enable-socks runtime switches everywhere.

So if fetchmail currently tries to use socks if you've set up socks.conf, 
then I think that's the right thing to do.  If you don't want fetchmail 
to use socks, don't set up socks.conf.

-- 
==============================|   "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"