fetchmail-users — User questions and discussion

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.

 

[fetchmail-users] fetchmail 6.3.8-rc1 release candidate

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

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

Greetings,

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

One more workaround was added to support repolling after failure of
opportunistic TLS upgrade - this time when the server refused
authentication.

Several parts of the documentation have been corrected and the Received:
format that fetchmail expects was documented. There is also a new
contrib/ script, delete-later.

Details:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
fetchmail 6.3.8 changes since 6.3.7:

# BUG FIXES:
* Fix pluralization of oversized-message warning mails.
* Fix manual page: --sslcheck -> --sslcertck, and do not set trailing 
  "recommended:" in bold. Fixes Debian Bug #413059, reported by Rafal Czlonka.
* Repoll immediately if a protocol error happens during the authentication 
  attempt after a failed opportunistic TLS upgrade.
  Fixes comment #9 in Gentoo Bug #163782, reported by Takuto Matsuu.
* Fix rendering of the "24 - 26, 28, 29" paragraph in the exit codes section. 
  Reported by Nico Golde.

# DOCUMENTATION:
* Extend --mda documentation, discourage use of qmail-inject.
  Based on a patch by Rob MacGregor.
* Document SOCKS configuration facility (SOCKS_CONF environment variable).
  Thanks to Jochen Hayek, Michael Shuldman and Rob MacGregor.
* Use envelope option in multidrop example. Patch by Rob MacGregor.
* Document expected Received: line format when parsing for envelope addressees.
* Stripped option documentation from sample.rcfile, since this is bound to go
  out of synch with the manual page, which is the only reference on options.

# CONTRIB:
* Add delete-later and delete-later.README, a script and documentation for
  a MySQL/Tcl-based client-side "delete-after" feature.
  Kindly donated by Yoo GmbH, Großvoigtsberg, Germany (Carsten Ralle).

# KNOWN BUGS AND WORKAROUNDS:
  (this section floats upwards through the NEWS file so it stays with the
  current release information)
* fetchmail does not handle messages without Message-ID header well
  (See sourceforge.net bug #780933)
* Sun Workshop 6 (SPARC) is known to miscompile the configuration file lexer in
  64-bit mode.  Either compile 32-bit code or use GCC to compile 64-bit
  fetchmail.  Note that fetchmail doesn't take advantage of 64-bit code,
  so compiling 32-bit SPARC code should not cause any difficulties.
* fetchmail does not track pending deletes over crashes
* the command line interface is a bit narrow-minded sometimes, for instance,
  fetchmail -s doesn't work with a running daemon
* some of the logging output is not very helpful
* some of the documentation is still not up to date
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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/Fq4vmGDOQUufZURAh5CAJ9eVxplbQV1HJmEo1cIFFMrPIn+bACeJPm/
0dtsJenupmlzyECQ4KNmYEI=
=qutF
-----END PGP SIGNATURE-----

Re: [fetchmail-users] fetchmail and socks5

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

Jochen Hayek schrieb:

> Now that we (the fetchmail community) know this, fetchmail can also get an internal
> 
>     putenv("SOCKS_CONF=/dev/null")
> 
> somewhere around its
> 
>     SOCKSinit("fetchmail");
> 
> and than a command line switch (e.g. --socks_conf=/etc/socks.conf )
> in order to change it back,
> so that somebody, who really wants to employ socks, actually makes use of it:
> 
>     putenv("SOCKS_CONF=/etc/socks.conf")
> 
> But there are dozens of alternatives ...

But why would fetchmail then need its own command line switch at all?
I mean - if the SOCKS library reads the environment, we can just
document this. I'll do that now.

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

Adding even more code to handle yet another option however doesn't seem
justified in this case -- this new option would just be one different
formulation for exactly the same purpose - and we already have env(1)
and shells to handle this. It's not the putenv, but the dozens of code
lines in the fetchmail dump, option parser, rcfile parser, fetchmailconf
and everywhere else I've forgotten.

I hope that's acceptable.

If it's not, please find some good excuses for me for duplicating the
environment modification code that is already in env(1) - and please one
that keeps compatibility with 6.3.7. :-)

Best,
MA

Re: [fetchmail-users] fetchmail and socks5

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

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

    MA> Well - Dante doesn't have run-time switches, it redirects all
    MA> the network-related functions to itself, 
    MA> fetchmail has not means to circumvent SOCKS if linked against it.
    MA> Such run-time configuration would have to happen by means of socks.conf.

>>>>> On Sat, 17 Mar 2007 15:18:02 +0100,
>>>>> Michael Shuldman
>>>>> (whose comments are cited below with "    MS> "),
>>>>> had this to say in article <200...@ba...>
>>>>> in newsgroups gmane.network.socks.dante.general
>>>>> concerning the subject of "Re: 2007-03-16 / how to tell socks enabled application to not go via the socks server"

> Jochen Hayek wrote,

    >> But how can a socks enabled (compiled, linked, ...) application
    >> instruct the socks5 library to not go via the socks5 server
    >> other than by removing /etc/socks.conf ?

    MS> Maybe you could set the environmentvariable SOCKS_CONF.  
    MS> What happens if you do "SOCKS_CONF=/dev/null application"?

That does exactly what you and I expect.

Thanks a lot!



Now that we (the fetchmail community) know this, fetchmail can also get an internal

    putenv("SOCKS_CONF=/dev/null")

somewhere around its

    SOCKSinit("fetchmail");

and than a command line switch (e.g. --socks_conf=/etc/socks.conf )
in order to change it back,
so that somebody, who really wants to employ socks, actually makes use of it:

    putenv("SOCKS_CONF=/etc/socks.conf")

But there are dozens of alternatives ...

Re: [fetchmail-users] fetchmail and socks5

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

On 3/16/07, Jochen Hayek <Joc...@ha...> wrote:
>
> I don't want to appear picky (although I probably am),
> but if a usual DAU (and I myself have grown out of that state during some 25 years in IT),
> who certainly has the right to use a Linux, BSD or whatever distro instead of compiling everything himself from scratch
> and who esp. has the right to use a fetchmail, that comes with that distro,
> and such a distro may provide him with a socks enabled fetchmail,
> and if he experiments in one corner (socks),
> then he does not necessarily need to expect impact in a slightly different corner (fetchmail).

I'm with you on that one.  Sadly the problem is that whoever created
the binary package didn't understand the impact of what they were
doing when they compiled in SOCKS support.

> So ... it would be nice to have a socks enabled fetchmail
> defaulting to "do *not* use socks until I tell you via command line or via RC option".

If you're able to supply patches to make this happen then I suspect
the developers would be interested (not a dig, just a suggestion).
I've also submitted a patch for the man page (which should make it
into 6.3.8 with luck) to document this behaviour.

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

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

On 3/16/07, jay shi <jay...@ya...> wrote:
> Hi Rob & friends,
>                Sorry for my long mail, i just put for understanding purpose only.Plz don't ignore my mail, i am in trouble .
>                well i use ur specified option "envelope 1 Delivered-To"  but still getting no  effect. The user foo & bar getting double mails.
>               what should i do next ?

Right, please go back and read the FAQ.  It tells you what you're
supposed to be providing.

1) Version of fetchmail.  Until that's (at least) 6.3.7 don't bother
going any further.

2) Contents of .fetchmailrc

3) Command line arguments

4) Output of "--nosyslog --nodetach -vvv" (yes, that's three -v
options, enabling debug mode) for a problem email

5) Matching entries from the log of your SMTP server (and what it is)

See also the FAQ:

http://www.fetchmail.info/fetchmail-FAQ.html#M8

-- 
                 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 <mat...@gm...> writes:
> 
>     MA> Well - Dante doesn't have run-time switches, 
>     MA> it redirects all the network-related functions to itself,
>     MA> fetchmail has not means to
>     MA> circumvent SOCKS if linked against it.
> 
>     MA> Such run-time configuration would have to happen by means of socks.conf.
> 
>     MA> I am not sure if that's possible with "via: direct" statements
>     MA> somehow for your configuration.
> 
> I asked the dante people for help (-> news.gmane.org:gmane.network.socks.dante.general : "how to tell socks enabled application to not go via the socks server"),
> and I will come back to you, if there will be a viable solution..

Thank you.

Re: [fetchmail-users] fetchmail and socks5

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

>>>>> "RMG2" == Rob MacGregor writes:

    >> [2007-03-15 14:11:49] johayek@HayekJ $ fetchmail --version
    >> This is fetchmail release 6.3.2+POP2+IMAP-GSS+RPA+NTLM+SDPS+SSL+OPIE+SOCKS+NLS.

    RMG2> Yeah that looks like it was configured with socks support.  Having
    RMG2> myself dug through the documentation and FAQ it appears that there is
    RMG2> socks support after all (it's not documented anywhere except the FAQ):

    RMG2> http://www.fetchmail.info/fetchmail-FAQ.html#K1

    RMG2> Rebuild fetchmail without the socks support.  

    RMG2> It looks like fetchmail will automatically use socks
    RMG2> if you build it with socks support

... resp. e.g. if your ready-made Linux distribution provides you with a fetchmail configured like that.

    RMG2> - there's no runtime switch.
    RMG2> (At least that's what a read of the source tells me)

    RMG2> So, in short, while you didn't intend to configure fetchmail
    RMG2> to use your socks server, 
    RMG2> you did by configuring socks support into fetchmail

I don't want to appear picky (although I probably am),
but if a usual DAU (and I myself have grown out of that state during some 25 years in IT),
who certainly has the right to use a Linux, BSD or whatever distro instead of compiling everything himself from scratch
and who esp. has the right to use a fetchmail, that comes with that distro,
and such a distro may provide him with a socks enabled fetchmail,
and if he experiments in one corner (socks),
then he does not necessarily need to expect impact in a slightly different corner (fetchmail).

Although addmittedly both corners are "a little" associated "through" TCP/IP resp. a substitute aka socks library.

So ... it would be nice to have a socks enabled fetchmail 
defaulting to "do *not* use socks until I tell you via command line or via RC option".

And that's where I started "a while ago":

    JH> I would actually prefer a command line option and an entry in the RC file.

    JH> Is there already a feature of fetchmail, that this could be made similar to?

Having a look at the sources myself, too,
I hoped, that the call to SOCKSinit would be an appropriate location to include such a switch,
but that hope sadly did not fulfill.



Alright, I think, I just admit,
that my idea of a fetchmail has not yet been implemented and is also not so easy to implement.



I asked the dante people for the help (-> news.gmane.org:gmane.network.socks.dante.general : "how to tell socks enabled application to not go via the socks server"),
and I will come back to you, if there will be a viable solution..

    RMG2> (and I'm guessing defining some
    RMG2> environment variables or putting entries in socks.conf).

I "just" made my socks.conf to point to a real socks5 server.
Before that, that socks.conf just waited to be taken care of ...




Cheers,
Jochen

Re: [fetchmail-users] fetchmail and socks5

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

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

    MA> Well - Dante doesn't have run-time switches, 
    MA> it redirects all the network-related functions to itself,
    MA> fetchmail has not means to
    MA> circumvent SOCKS if linked against it.

    MA> Such run-time configuration would have to happen by means of socks.conf.

    MA> I am not sure if that's possible with "via: direct" statements
    MA> somehow for your configuration.

I asked the dante people for help (-> news.gmane.org:gmane.network.socks.dante.general : "how to tell socks enabled application to not go via the socks server"),
and I will come back to you, if there will be a viable solution..


Cheers,
Jochen

Re: [fetchmail-users] fetchmail multidrop problem

[jay s. <jay...@ya...>]

Hi Rob & friends,
               Sorry for my long mail, i just put for understanding purpose only.Plz don't ignore my mail, i am in trouble .
               well i use ur specified option "envelope 1 Delivered-To"  but still getting no  effect. The user foo & bar getting double mails.
              what should i do next ?

Thanks & Regards
Jayesh
               

Rob MacGregor <rob...@gm...> wrote: Keep the traffic on the list.  If you don't then I'll simply ignore
any email from you...

On 3/15/07, jay shi  wrote:
> Hi Rob
>             Thanks For ur quick response
>             Now i ugrade the fetchmail to fetchmail 6.3.7 but still i am
> strugling
>
>             I used the option "envelope Delivered-To 1" in .fetchmailrc file
>
>             But while running the getmail it giving me the sysntax error

And what error would that be?  My crystal ball is broken today.

>             In man fetchmail  i got the following option
>
> -E 
 | --envelope 

>               (Keyword: envelope; Multidrop only)
>               In the configuration file, an enhanced syntax is used:
>               envelope [] 

>
>             what could be the  correct option ? for skipping lines

Ah, maybe it's "envelope 1 Delivered-To".  I've never come across a
mail system that's broken enough to insert multiple delivered to
headers before :)

-- 
                 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 mailing list
fet...@li...
https://lists.berlios.de/mailman/listinfo/fetchmail-users


 
---------------------------------
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.

Re: [fetchmail-users] fetchmail header (undisclosed recipients)

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

On 3/15/07, Sylvain Le Torrec <syl...@ad...> wrote:
> First, thank you for your quick answer

As I said before - you need to provide the headers from a sample email
so we can point out which header you should be using for the enevelope
header.  Blindly putting in values won't help you.

You also haven't provide any of the other diagnostic information that
the FAQ tells you to provide, except for the contents of your
fetchmailrc and version of fetchmail.  If you really want help then
please provide this.

-- 
                 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 header (undisclosed recipients)

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

Sylvain Le Torrec schrieb:
> First, thank you for your quick answer

Please trim your quotes. Only quote necessary material and delete the
rest. (Outlook makes people misbehave, that's just incredible.)

> I'm using fetchmail 6.2.4 (I know I have to upgrade it) with qmail

Newer versions have better documentation, too...

> -----------------------------------------
> See my fetchmailrc
> -----------------------------------------
> defaults
> set no bouncemail
> poll domain.mydomain.org protocol POP3
> localdomains mylocaldomain
> tracepolls
> envelope "Delivered-To:"
> qvirtual "Delivered-To:"

This is bogus, you need to specify the prefix that the UPSTREAM qmail
adds to Delivered-To headers (what they have in their virtualdomains
table on their right hand side), if for instance all headers looked like:

Delivered-To: let...@ba...z

You could use qvirtual "letorrec-".

> username myusername
> password mypasswd
> is *
> fetchall
> mda "sed 1,2d | /var/qmail/bin/qmail-inject"

Make that

mda "sed 1,2d | /usr/sbin/sendmail -i -f %F -- %T"

That should work with qmail (you MAY have to use /usr/lib/sendmail
instead) and prevent forwarding loops (by making recipients explicit -
the %T is it).

Also, will people *please* stop using this ghastly qmail-inject? It
offers no advantage, only the disadvantage of a nonstandard command line
interface. (qmail's sendmail compatibility wrapper even understands
qmail-inject's environment variables.)

HTH,
MA

[fetchmail-users] TR: fetchmail header (undisclosed recipients)

[Sylvain Le T. <syl...@ad...>]

First, thank you for your quick answer

I'm using fetchmail 6.2.4 (I know I have to upgrade it) with qmail
-----------------------------------------
See my fetchmailrc
-----------------------------------------
defaults
set no bouncemail
poll domain.mydomain.org protocol POP3
localdomains mylocaldomain
tracepolls
envelope "Delivered-To:"
qvirtual "Delivered-To:"
username myusername
password mypasswd
is *
fetchall
mda "sed 1,2d | /var/qmail/bin/qmail-inject"

# the last line allowed to not receiving 2 copies of a mail.        
-----------------------------------------

I found your mail in my postier account...

Reporting-MTA: dns; mail.berlios.de
X-Postfix-Queue-ID: 3666CC4720
X-Postfix-Sender: rfc822; root@mydomain
Arrival-Date: Thu, 15 Mar 2007 22:13:38 +0100 (CET)

Final-Recipient: rfc822; fet...@li...
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; mail forwarding loop for
    fet...@li...

my fetchmail doesn't know what to do with.... 
------------------------------------------

When there's a mail with "undisclosed recipients", my fetchmail dies and
it's blocked.

Thank you.

Sylvain Le Torrec
Informaticien - Agence de Santé des îles
Wallis et Futuna
BP 4G MATA UTU 98600 WALLIS
Tel : (681) 72 07 25 ou Poste 349
 

-----Message d'origine-----
De : fet...@li...
[mailto:fet...@li...] De la part de Rob
MacGregor
Envoyé : vendredi 16 mars 2007 09:10
À : fet...@li...
Objet : Re: [fetchmail-users] fetchmail header (undisclosed recipients)

Please, no HTML.

On 3/15/07, Sylvain Le Torrec <syl...@ad...> wrote:
>
> I don't find answers of my last questions in your FAQ.
>
> 1- On my server, I've got some mails where there is
"undisclosed-recipients"
> in the mail. Fecthmail doesn't know how to retrieve it, what can I do?

Read the FAQ and provide the information requested.  We'll also need
mail headers from one of the emails so we can point out which envelope
header you should be using (see the man page).

> 2- When an external user of my network sends a mail on my network, I
receive
> 2 copies of this mail.
>
> 3- If an external user sends a mail to 2 or more users, fetchmail
re-inject
> the mail in my qmail and this one sent the mail to other recipient. What I
> do to make fetchmail look only the mail address of my network.
>
> 4* – if an external user (from @domain.com) send a mail to my network
> (@mydomain.org) and to one or more user on domain.com, each user will
> receive 2 or more same mails.

These are all the same problem and related to your using multidrop
without defining the envelope header.

As Gerard said, please provide your fetchmail version.  You also need
to provide your fetchmailrc and any command line arguments you're
using - as per the FAQ you read :)

-- 
                 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 mailing list
fet...@li...
https://lists.berlios.de/mailman/listinfo/fetchmail-users

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