fetchmail-users — User questions and discussion

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

Re: [fetchmail-users] fetchmail and socks5

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

>>>>> 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.

Socksification is really not an easy peace of cake.

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.

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.

    RM> As long as there is a command line argument
    RM> to either disable socks or use an alternative socks config file
    RM> (which implicitly enables socks) 
    RM> then that should be fine.

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



I am sorry, but I cannot spend any more time on this issue.
The topic socksification and all that has already been far too expensive for me during the last couple of weeks.

I presented all the facts I could present to you.
Take it or leave it.



Oh, just a last "word":
After all I honestly do appreciate the abilities of socks servers
and the capabilities of explicit and implicit socksification.
If small applications get developed (or carefully migrated) with explicit socksification in mind,
the code doesn't even get spoilt,
your TCP-whatever programming still looks like in the RFC, Stevens or whatever,
and amazingly enough -- if your IT dept. socks server admin allows the connections, your application needs -- your application transparently gets through a firewall and does its job,
just as if there even wasn't any disturbing firewall
and just as if you were in the "real nature Internet", not within an Intranet.



Kind regards,
JH

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

[Richard <rch...@aa...>]

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?
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?
4) If I need to manually load the Equifax certificate into openssl - do you
know where I get the Public Equifax certificate from?
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.


Thanks Hannes

Richard.




-----Original Message-----
From: fet...@li...
[mailto:fet...@li...] On Behalf Of Hannes Erven
Sent: Monday, 19 March 2007 5:59 PM
To: fet...@li...
Subject: Re: [fetchmail-users] SSL Ceritficate errors in sendmail log

Hi Richard,


> fetchmail: Issuer Organization: Equifax
> fetchmail: Unknown Issuer CommonName
> fetchmail: Server CommonName: pop.gmail.com
> fetchmail: pop.gmail.com key fingerprint:
> 59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4
> fetchmail: Warning: server certificate verification: unable to get local
> issuer certificate


This means fetchmail cannot find Equifax's public certificate on your 
computer.


You need to either:

1. disable the certificate chain check by specifying the certificate's 
(pop.gmail.com's) fingerprint on the account using sslfingerprint, or

2. place the (equinox root) certificate in your system's certificate 
store, usually /etc/ssl, and run c_rehash (an openssl tool) there.
It is also possible to specify another directory using sslcertpath if 
you do not want to make the root equinox certificate available to all 
your users.

HTH,
-hannes
_______________________________________________
fetchmail-users mailing list
fet...@li...
https://lists.berlios.de/mailman/listinfo/fetchmail-users

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

[Hannes E. <h....@gm...>]

Hi Richard,


> fetchmail: Issuer Organization: Equifax
> fetchmail: Unknown Issuer CommonName
> fetchmail: Server CommonName: pop.gmail.com
> fetchmail: pop.gmail.com key fingerprint:
> 59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4
> fetchmail: Warning: server certificate verification: unable to get local
> issuer certificate


This means fetchmail cannot find Equifax's public certificate on your 
computer.


You need to either:

1. disable the certificate chain check by specifying the certificate's 
(pop.gmail.com's) fingerprint on the account using sslfingerprint, or

2. place the (equinox root) certificate in your system's certificate 
store, usually /etc/ssl, and run c_rehash (an openssl tool) there.
It is also possible to specify another directory using sslcertpath if 
you do not want to make the root equinox certificate available to all 
your users.

HTH,
-hannes

[fetchmail-users] SSL Ceritficate errors in sendmail log

[Richard <rch...@aa...>]

Hi 

I am running Centos 4.4 all up to date - and using fetchmail 6.2.5 to
consolidate various email accounts. I am a recently reformed windows system
admin and use webmin to administer the centos machine.

Whenever I receive (reasonable) errors in my fetchmail log - I also get the
following warnings:

fetchmail: 6.2.5 querying pop.gmail.com (protocol POP3) at Fri Mar 16
20:50:15 2007: poll started
fetchmail: Issuer Organization: Equifax
fetchmail: Unknown Issuer CommonName
fetchmail: Server CommonName: pop.gmail.com
fetchmail: pop.gmail.com key fingerprint:
59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4
fetchmail: Warning: server certificate verification: unable to get local
issuer certificate
fetchmail: Issuer Organization: Equifax
fetchmail: Unknown Issuer CommonName
fetchmail: Server CommonName: pop.gmail.com
fetchmail: Warning: server certificate verification: certificate not trusted
fetchmail: Issuer Organization: Equifax
fetchmail: Unknown Issuer CommonName
fetchmail: Server CommonName: pop.gmail.com
fetchmail: Warning: server certificate verification: unable to verify the
first certificate
fetchmail: POP3< +OK Gpop ready for requests from 202.72.167.234
7pf2474781nzn
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< USER
fetchmail: POP3< RESP-CODES
fetchmail: POP3< EXPIRE 0
fetchmail: POP3< LOGIN-DELAY 300
fetchmail: POP3< X-GOOGLE-VERHOEVEN
fetchmail: POP3< UIDL
fetchmail: POP3< .
fetchmail: POP3> USER cha...@gm...
fetchmail: POP3< +OK send PASS
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Welcome.
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for cha...@gm... at pop.gmail.com
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Farewell.
fetchmail: 6.2.5 querying pop.gmail.com (protocol POP3) at Fri Mar 16
20:50:21 2007: poll completed

This appears to be telling me that the centos system does not trust Google's
certificate issuer.

I realise this may not be the best forum - but does anyone know how I can
establish the trust to avoid these warnings?

Thanks

Richard.

Re: [fetchmail-users] fetchmail and socks5

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

On 3/18/07, Matthias Andree <mat...@gm...> wrote:
>
> Well, this feature has been automatically enabled in fetchmail since at
> least 6.2.5, and I think we should keep breaking compatibility in this
> respect until the next minor or major release -- I'll certainly consider
> changing the default for fetchmail 6.4 or 7.0 or whatever version, and
> I'm very much inclined to choose defaults that do not surprise the user.
>
> I wonder if there is really a common expectation. Other users might
> expect that *if* they have a socks.conf, *then* socks-enabled
> applications should use it.
>
> This isn't clear to me, and it's a bet the maintainer will always lose -
> one group will be happy and quiet, and the other group will shout. :-)

As long as the default is clearly documented it shouldn't matter what
it is.  I think the real problem here has been the lack of clear
documentation.

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.

> 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 :)

> If fetchmail were actively enabling socks, then we might just log
> additional information to the connecting... ("via socks server XYZ port
> N") but this isn't the case. I haven't looked too deep into SOCKS yet
> and I'm short on time. I plan to do 6.3.8-rc2 this week and 6.3.8 this
> month, so that I can move on to actually opening the 6.4 branch.

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

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

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

Jochen Hayek schrieb:
>>>>>> "MA" == Matthias Andree writes:
> 
>> Jochen Hayek writes:
> 
>     MA> But why would fetchmail then need its own command line switch at all?
> 
> Because that feature needs to get locked out, until it gets explicitly invited.
> 
> And the fact that ready-made fetchmails in distros come with not so obvious linked-in socks support
> is not really a contradiction,
> to the fact, that people don't want that feature until they say "I want it".

Well, this feature has been automatically enabled in fetchmail since at
least 6.2.5, and I think we should keep breaking compatibility in this
respect until the next minor or major release -- I'll certainly consider
changing the default for fetchmail 6.4 or 7.0 or whatever version, and
I'm very much inclined to choose defaults that do not surprise the user.

I wonder if there is really a common expectation. Other users might
expect that *if* they have a socks.conf, *then* socks-enabled
applications should use it.

This isn't clear to me, and it's a bet the maintainer will always lose -
one group will be happy and quiet, and the other group will shout. :-)

> Because a fetchmail switch "--use-socks" defaulting to false
> would have helped not costing me and others quite a couple of hours.

Sorry for that - it's documented now
<http://www.fetchmail.info/fetchmail-FAQ.html#K1> and will also be
documented in the manpage of fetchmail 6.3.8. Feel free to suggest
further changes, the FAQ is surely not cast in concrete.

> A good example for the downsides of the bazaar approach ...
> (Sorry for this, but I couldn't resist.)

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...

I sympathize with you on the bazaar "appreciation", too.
The "many eyeballs" argument that is invoked so often doesn't hold water
IMO - those eyeballs are only looking after someone has encountered a
*local* problem (or in the rare case some distributor pays for the audit
or some company tries their automated code validator and shares the
results).

The accumulation of dozens of patches, with uncorrected programming
styles, which are really just patches that have often not properly been
integrated - this is a constant headache, and the security fixes that
went into 6.3.6 had to be large as a result of these inconsistencies and
ad-hoc hacking -- and the fallout caused regression fixes in 6.3.7 and
6.3.8. This is the thing I feared most, I did several 6.3.6 release
candidates, but still only field deployment revealed these issues. :-(

Getting distracted a bit, I'd also say beta and rc versions don't work
without contracted beta testers, since users will just wait for the
final release out of convenience - and that's understandable, consumers
don't want unripe garbage...

> A couple of words in the man page and in the FAQ,
> that will get found by search machines,
> so that googling for "fetchmail socks"
> will immediately reveal the problem.

Search engines aren't under my control -- let me know if you want
anything else or suggest changes to the FAQ URL I've given above.

> But still:
> when *I* couldn't connect to my ISP's IMAP server any longer
> I was ***far*** away from googling for "fetchmail socks",
> and it took me pretty long to find out,
> that I had gone through my socks server for quite a while
> (without being aware of it, as I never told fetchmail to do so)
> and that I could not connect to the IMAP server, only because my socks server was down.

If fetchmail were actively enabling socks, then we might just log
additional information to the connecting... ("via socks server XYZ port
N") but this isn't the case. I haven't looked too deep into SOCKS yet
and I'm short on time. I plan to do 6.3.8-rc2 this week and 6.3.8 this
month, so that I can move on to actually opening the 6.4 branch.

-- 
Matthias Andree

Re: [fetchmail-users] fetchmail and socks5

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

>>>>> "MA" == Matthias Andree writes:

> Jochen Hayek writes:

    MA> But why would fetchmail then need its own command line switch at all?

Because that feature needs to get locked out, until it gets explicitly invited.

And the fact that ready-made fetchmails in distros come with not so obvious linked-in socks support
is not really a contradiction,
to the fact, that people don't want that feature until they say "I want it".


Because a fetchmail switch "--use-socks" defaulting to false
would have helped not costing me and others quite a couple of hours.

And maybe far more hours to others, that were not as sick as me, to go here to tell you, there *is* a weird thing with fetchmail.


Pls don't get upset!
I certainly don't consider *you* responsible for that problem.


Who is responsible then? Hard to tell ...

When people attempt socksification of fetchmail (likewise other applications),
they are faced with the suggestion to do it via CPP macros.
If they are lucky, they don't even need to touch their code.
Apparently as long, as no /etc/socks.conf is created, the application continues working as before,
so nobody considers introducing a "--use-socks" switch.
Only at a far later stage impacts and problems appear and get discussed.
Meanwhile the recentyl introduced has long gotten an established feature,
and changing it would break compatibility ...
A good example for the downsides of the bazaar approach ...
(Sorry for this, but I couldn't resist.)

    MA> I mean - if the SOCKS library reads the environment, 
    MA> we can just document this.
    MA> I'll do that now.

A couple of words in the man page and in the FAQ,
that will get found by search machines,
so that googling for "fetchmail socks"
will immediately reveal the problem.

But I guess this thread here will get picked up the search machines anyway
and will also actually help already.


But still:
when *I* couldn't connect to my ISP's IMAP server any longer
I was ***far*** away from googling for "fetchmail socks",
and it took me pretty long to find out,
that I had gone through my socks server for quite a while
(without being aware of it, as I never told fetchmail to do so)
and that I could not connect to the IMAP server, only because my socks server was down.

Now that I know that, it's obviously easy to make use of that env. var. "SOCKS_CONF".
This already found its place in my ~/.profile -- maybe this should even go to /etc/profile :

    export SOCKS_CONF=/dev/null

And wherever I do want to go through the socks server,
I will "prepend" this to a command line:

    env SOCKS_CONF=/etc/socks.conf

e.g.

    env SOCKS_CONF=/etc/socks.conf socksify ftp ...
    env SOCKS_CONF=/etc/socks.conf socksify wget ...
    env SOCKS_CONF=/etc/socks.conf socksify curl ...

Nothing easier than that.

I hated it anyway, that "socksify" does not take command line switches,
and so you are not able to try different socks.conf on the the socksified command lines -- of course *after* the word socksify.
But as we do know by now: you can get this effect through that env. var. -- see above!

    MA> I'm not going to change the default behaviour in 6.3.X releases anyways:
    MA> incompatibilities do not belong in patchlevel update releases. 
    MA> So no putenvs without options.

    MA> Adding even more code to handle yet another option 
    MA> however doesn't seem justified in this case
    MA> -- this new option would just be one different
    MA> formulation for exactly the same purpose
    MA> - and we already have env(1) and shells to handle this.

You are very right.
I cannot blame you for this position.

    MA> It's not the putenv, 
    MA> but the dozens of code lines in the fetchmail dump, option
    MA> parser, rcfile parser, fetchmailconf
    MA> and everywhere else I've forgotten.

    MA> I hope that's acceptable.

It is.

    MA> If it's not, please find some good excuses for me for duplicating the
    MA> environment modification code that is already in env(1)

    MA> - and please one that keeps compatibility with 6.3.7. :-)

My idea was to *break* compatibility here,
as this feature has always been a very bad feature.

Cheers,
Jochen

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

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

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.

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

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

John <fet...@je...> writes:

> 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 ?

Not to my knowledge. You'd have to secure the LDAP database (or at least
the password records) tightly, because you'd have to put cleartext
passwords into the database -- unless you were trying certificate-based
authentication, that is.

-- 
Matthias Andree

Re: [fetchmail-users] Can fetchmail leave email on the POP3 srever for (say) 10 days?

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

"Richard" <rch...@aa...> writes:

> I have Centos 4.4 all up to date. Being a recently reformed Windows Sys
> Admin - I tend to manage centos mostly with Webmin - though I also use the
> Gnome interface through nx. I try to avoid the command line stuff where
> possible.

I find command-line interfaces more efficient in the long run -- even if
I don't suggest to start learning the modal vi editor first, pico, nano
or joe are user-friendly alternatives.

And the command-line interface is standard - in contrast to the various
incarnations of web interfaces - so there are more people around who are
able to support the former.

> The Webmin interface for configuring fetchmial allows me to specify whether
> or not to leave the email items on the POP3 server after downloading them.
> As far as I can see there is no way to specify to leave them there for (say)
> 10 days then delete them. Most POP clients support this behaviour. (Outlook
> & Outlook express certainly do)

Outlook & express are by no means setting standards -- with
long-standing serious MIME and quoting bugs still unfixed in Outlook 11
that Microsoft documented in the KB in the days of Outlook Express 4 a
decade ago...

Having said that, fetchmail up to and including 6.3.X versions do not
have such a feature yet, but the next major spin (which might be called
6.4, 6.5 or 7.0 eventually) might.

This has mostly historical reasons: ESR wanted to keep this feature out
and also (not sure if it's related) loathed touching client-side
"message seen" tracking like a toothache -- and I wanted to offer the
many dozens of 6.3.X fixes as painlessly and as soon as possible to
6.2.X users - which required leaving a few shortcomings as they were in
2003 and 2004, the days of ESR's last fetchmail release, 6.2.5, and I
can't work full-time on fetchmail and am currently the only active
developer.

For the nonce, check the contrib/ directory of recent fetchmail versions
and see if you can find stuff that helps you -- although I'm not able to
support what's in there unless I've personally written it.

There is a MySQL/Tcl/Expect based solution appearing in fetchmail
6.3.8's contrib/ directory (already included in -rc1, check the mailing
list archives for the announcement).

If you can't be bothered to do that, but your CentOS 4.4 has Python 2.4
or newer as the default Python install, getmail 4 by Charles Cazabon
might be an alternative that has this feature, but its resistance
against eavesdroppers and man-in-the-middle attacks is largely dependent
on the behavior of Python libraries and not always clear.

> Can anyone tell me whether this can be done - and if so - is it a limitation
> of the webmin interface which prevents me from specifying this?

Not up to and including fetchmail 6.3.X.

> I think Webmin allows me to run a command before and/or after
> downloading emails.  Perhaps I can achieve what I want this way?

Yes, you can - provided that command or script removes messages that
have arrived N days. :-)

> If I revert to editing a conf file - will that interfere with webmin's
> control of the conf file?

That depends on Webmin, of which I know naught beyond its bare existence.

> I would like to do this so that there is a copy of new emails somewhere if
> the Centos machine hard disk dies.

If you don't want to do this at an application level, but on a file
system level, look for DRBD (essentially RAID across the network in
Linux) - requires a second computer with fast disks, preferably
off-site, and a fast network connection.

-- 
Matthias Andree

[fetchmail-users] Using LDAP for user account information

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

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 ?

Re: [fetchmail-users] Can fetchmail leave email on the POP3 srever for (say) 10 days?

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

On 3/18/07, Richard <rch...@aa...> wrote:

> I have Centos 4.4 all up to date. Being a recently reformed Windows Sys
> Admin - I tend to manage centos mostly with Webmin - though I also use the
> Gnome interface through nx. I try to avoid the command line stuff where
> possible.

"All up to date" is meaningless - the actual version number of
fetchmail is required.  I would also strongly advise you to learn the
command line.  The GUI interfaces are often more limited than the
underlying tools (particularly with the likes of webmin which doesn't
evolve as rapidly as the tools it supports).

It also help you when the GUI breaks and you're trying to get it
running again :)

> The Webmin interface for configuring fetchmial allows me to specify whether
> or not to leave the email items on the POP3 server after downloading them.
> As far as I can see there is no way to specify to leave them there for (say)
> 10 days then delete them. Most POP clients support this behaviour. (Outlook
> & Outlook express certainly do)
>
> Can anyone tell me whether this can be done - and if so - is it a limitation
> of the webmin interface which prevents me from specifying this? I think
> Webmin allows me to run a command before and/or after downloading emails.
> Perhaps I can achieve what I want this way? If I revert to editing a conf
> file - will that interfere with webmin's control of the conf file?

No, it can't.  The purpose if fetchmail is purely to fetch email from
remote servers, it isn't designed to behave like a POP client :)

There are (though you'll have to trawl the list archive) various tools
out there to expire messages that way.

As for webmin, I've never used it so couldn't say.

> I would like to do this so that there is a copy of new emails somewhere if
> the Centos machine hard disk dies.

Ah, you want a backup :)  Well, you've got a number of options.

For only protection against disk failure there's always another disk
and running RAID1 (hardware or software).  For proper backups grab an
external hard disk (USB works fine :>) and use the likes of rsnapshot
to take backups onto it.

-- 
                 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] Can fetchmail leave email on the POP3 srever for (say) 10 days?

[Richard <rch...@aa...>]

I tried posting this before I was properly subscribed. I don't think it has
been posted before. If it has - I can't find any responses. My apologies if
it has been posted before.

 

Hi

I have Centos 4.4 all up to date. Being a recently reformed Windows Sys
Admin - I tend to manage centos mostly with Webmin - though I also use the
Gnome interface through nx. I try to avoid the command line stuff where
possible.

The Webmin interface for configuring fetchmial allows me to specify whether
or not to leave the email items on the POP3 server after downloading them.
As far as I can see there is no way to specify to leave them there for (say)
10 days then delete them. Most POP clients support this behaviour. (Outlook
& Outlook express certainly do)

Can anyone tell me whether this can be done - and if so - is it a limitation
of the webmin interface which prevents me from specifying this? I think
Webmin allows me to run a command before and/or after downloading emails.
Perhaps I can achieve what I want this way? If I revert to editing a conf
file - will that interfere with webmin's control of the conf file?

I would like to do this so that there is a copy of new emails somewhere if
the Centos machine hard disk dies.


Thanks

Richard.