fetchmail-users — User questions and discussion

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

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

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

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

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

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

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

--
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

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

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

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

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

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

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

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

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


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

-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

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

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

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

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

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

Thanks,

-- 
Matthias Andree

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

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

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

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

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

--
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

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

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

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

thanks for all of your help :)

pongthep

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

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

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

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

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

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

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

-- 
Matthias Andree

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

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

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

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

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

--
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

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

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

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

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

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

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

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

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

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

-- 
Matthias Andree

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

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

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

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

David,

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

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

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

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

HTH,

-- 
Matthias Andree

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

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

Matthias Andree wrote:

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

Thanks, David

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

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

Hallo Matthias,

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

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

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

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

Matthias Andree wrote:

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

Thanks, David

Re: [fetchmail-users] SSL authentication problems with Gmail

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

Jakob Hirsch schrieb am 2006-01-05:

> Matthias Andree wrote:
> 
> > 2. Debian's ca-certificates package has the Thawte root certificate in
> >    the default place, this proved sufficient to verify Google's
> >    certificate (which is signed by Thawte) in fetchmail 6.3.1 even with
> 
> just a little unimportant addition: pop.googlemail.com has a certificate
> signed by Thawte, while pop.gmail.com's is signed by Equifax.

Right, I know I confused something WRT the signing authorities from
memory.  Thank you!

-- 
Matthias Andree

Re: [fetchmail-users] SSL authentication problems with Gmail

[Jakob H. <jh...@pl...>]

Matthias Andree wrote:

> 2. Debian's ca-certificates package has the Thawte root certificate in
>    the default place, this proved sufficient to verify Google's
>    certificate (which is signed by Thawte) in fetchmail 6.3.1 even with

just a little unimportant addition: pop.googlemail.com has a certificate
signed by Thawte, while pop.gmail.com's is signed by Equifax.

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

[Simon B. <ba...@gm...>]

Matthias Andree wrote:
> > What about using one of the system-wide temporary directories instead?
> 

[ Nice explanation skipped -- thanks! ]

> 
> Debian for instance uses a fetchmail user for the system wide fetchmail
> daemon, home directory is /var/run/fetchmail, yet they use
> /var/mail/.i-forgot-the-UIDL-name for their idfile. If they used
> /var/run/fetchmail/.i-forgot-the-UIDL-name, everything would be fine. No
> need for ${TMPDIR-/tmp}.

I thought about adding something similar to the FreeBSD port, but I thought
of having one fetchmail instance per user (if that is possible). OTOH, this
will not work if there are many users.

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

-- 
Best regards / Viele Grüße,                             ba...@Fr...
 Simon Barner                                                ba...@gm...

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

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

Simon Barner schrieb am 2006-01-05:

> Matthias Andree wrote:
> > Beginning with release 6.3.0, fetchmail needs not only need write access
> > to the idfile ($HOME/.fetchids), but also to the directory holding this
> > file. fetchmail 6.2.X and older versions got away if just the idfile had
> > write permission.
> > 
> > The reason is that fetchmail 6.3.0 and newer now writes the ids to a
> > temporary file, to avoid truncation of the idfile if running short of
> > diskspace; a truncated idfile might lead to many duplicate messages,
> > which might, in turn, aggravate the "low space" situation.
> 
> What about using one of the system-wide temporary directories instead?

The basic idea is: the UIDs are somewhat precious (and we have had
issues to that extent in the bug trackers). That's why I chose to write
a temporary file and atomically (i. e. rename(2)) replace the original
file. This guarantees that we'll always have the old UID file available
even if writing the new fails at some point. In unlucky situations,
6.2.5.X and older might end up with an empty ID file, would start
refetching and flooding /var/mail with dupes.

Rename(2) only works within the same device or perhaps mountpoint (some
file systems such as AFS and Coda even turn every directory into a
filesystem of its own). Besides that, I will not use directories with
public write access (/tmp, /var/tmp), these are minefields, and handling
subdirectories within them still doesn't guarantee we can rename without
truncating the output file.

Plus, creating backup files still requires write permission on the
directory...

Debian for instance uses a fetchmail user for the system wide fetchmail
daemon, home directory is /var/run/fetchmail, yet they use
/var/mail/.i-forgot-the-UIDL-name for their idfile. If they used
/var/run/fetchmail/.i-forgot-the-UIDL-name, everything would be fine. No
need for ${TMPDIR-/tmp}.

-- 
Matthias Andree

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

[Simon B. <ba...@gm...>]

Matthias Andree wrote:
> Beginning with release 6.3.0, fetchmail needs not only need write access
> to the idfile ($HOME/.fetchids), but also to the directory holding this
> file. fetchmail 6.2.X and older versions got away if just the idfile had
> write permission.
> 
> The reason is that fetchmail 6.3.0 and newer now writes the ids to a
> temporary file, to avoid truncation of the idfile if running short of
> diskspace; a truncated idfile might lead to many duplicate messages,
> which might, in turn, aggravate the "low space" situation.

What about using one of the system-wide temporary directories instead?

-- 
Best regards / Viele Grüße,                             ba...@Fr...
 Simon Barner                                                ba...@gm...

Re: [fetchmail-users] SSL authentication problems with Gmail

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

Sebastian Tennant <se...@sm...> writes:

> Doh!  Just when you think you've wrapped something up...
>
> I didn't attach the init script did I?  I attached my fetchmailrc,
> including my password!
>
> I've changed the password, and there were no other account details
> included, so no harm done... luckily!
>
> Take two.  Init script attached.

OK, that, and the relevant syslog except allow me to write a concluding
report, Sebastian's problems are completely solved.

1. grabbing the certificate from the server dialogue failed; although
   c_rehash had worked properly, it was the wrong certificate
   apparently. ("unable to get local issuer certificate")

   There are certainly people with a deeper understanding of the SSL
   certification process that can explain this better than I can.

2. Debian's ca-certificates package has the Thawte root certificate in
   the default place, this proved sufficient to verify Google's
   certificate (which is signed by Thawte) in fetchmail 6.3.1 even with
   --sslcertck (which I recommend to use, as it's safer).

   NOTE: older fetchmail versions fail to set the SSL default
   certificate path, you must set "--sslcertpath /etc/ssl/certs"
   manually (or whichever the path is; you can also specify this in the
   fetchmailrc file.).

3. Debian's init script diverts logging to syslog by default, and the
   reporter's syslog.conf split error messages out to a separate file,
   where they went unnoticed.
   
   I therefore take the right to advise against using the "=" and "!"
   operators in syslog.conf. "mail.info" is the correct left-hand-side
   to use in syslog.conf for fetchmail 6.2.5.X and 6.3.X.

4. Debian's init script supports an operation "debug-run", which avoids
   syslog, and logs everything on the console in verbose mode. This
   appears to be a simple way to procure all necessary debug information
   on Debian systems.

Happy fetchmailing,

-- 
Matthias Andree

[fetchmail-users] fetchmail 6.3.0 contained incompatible idfile change

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

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

Greetings,

in the original 6.3.0 announcement, I mentioned that we're more careful
about writing the .fetchids file. While this is true, the change
introduced a minor incompatibility.

This announcement attempts to avoid astonishment throught that change.

Beginning with release 6.3.0, fetchmail needs not only need write access
to the idfile ($HOME/.fetchids), but also to the directory holding this
file. fetchmail 6.2.X and older versions got away if just the idfile had
write permission.

The reason is that fetchmail 6.3.0 and newer now writes the ids to a
temporary file, to avoid truncation of the idfile if running short of
diskspace; a truncated idfile might lead to many duplicate messages,
which might, in turn, aggravate the "low space" situation.

For end users running fetchmail with default idfile on their own
account, nothing changes: they have write access to their home
directory.

For system-wide execution of the script as used by some distributions
(for instance Debian), it is now important that the idfile is in a
directory writable by fetchmail, else creation of the temporary file and
renaming into place will fail. Debian for instance places the idfile
under /var/mail, this will no longer work with 6.3.0.

I still think the new behavior is a step ahead,
towards a more reliable fetchmail.

Please accept my apologies for missing this in the 6.3.0/6.3.1 materials
I provided to Rob Funk and that we shipped with fetchmail 6.3.0.

Happy fetchmailing,

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

iD8DBQFDvF7dvmGDOQUufZURAiknAKCFQxw6GWYmrvh2TW/qASnSA2n66QCfVrR/
IY+E3PqfFeWJW560g5IPDmQ=
=uILr
-----END PGP SIGNATURE-----

[fetchmail-users] [JFTR] (HEADS UP Rob & Rob!) debugging on Debian

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

Greetings,

if fetchmail is started on Debian, the default init script appears to
support a "debug-run", which starts fetchmail in foreground mode,
logging to console, with verbose info -- this can help debug fetchmail
in some cases.

I hope we all remember this option next time a Debian user has trouble.

Happy mail fetching,

-- 
Matthias Andree

[fetchmail-users] Updated Cygwin Package: fetchmail-6.3.1-1

[Jason T. <ja...@ti...>]

New News:
=== ====
I have updated the version of fetchmail to 6.3.1-1.  The tarballs should
be available on a Cygwin mirror near you shortly.

The only change between this version and the previous one is the
following:

    o update to version 6.3.1

Old News:
=== ====
Fetchmail is a remote mail retrieval and forwarding utility intended
for use over on-demand TCP/IP links, like SLIP or PPP connections.
Fetchmail supports every remote-mail protocol currently in use on the
Internet (POP2, POP3, RPOP, APOP, KPOP, all IMAPs, ESMTP ETRN, IPv6,
and IPSEC) for retrieval. Then Fetchmail forwards the mail through SMTP
so you can read it through your favorite mail client.

See the fetchmail home page for more details:

    http://fetchmail.berlios.de/

Please read the README file:

    /usr/share/doc/Cygwin/fetchmail-6.3.1.README

since it covers requirements, installation, known issues, etc.

Standard News:
======== ====
To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

If you have questions or comments, please send them to the Cygwin
mailing list at: cy...@cy... .

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=you...@cy...

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

Re: [fetchmail-users] Fetchmail is running slow on Mac OS X

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

Stéphane Lux <ste...@lu...> writes:

> Am 02.01.2006 um 16:38 schrieb Rob Funk:
>
>> Stéphane Lux wrote:
>>> fetchmail: starting fetchmail 6.2.5 daemon
>>> fetchmail: 6.2.5 querying ... (protocol IMAP) at Sat, 31 Dec 2005
>>> 03:03:13 +0100 (CET): poll started
>>>
>>> Then nothing happens for about one minute  (timout?), then fetchmail
>>> ist running normaly:
>>
>> Normally delays of a minute or two indicate a DNS problem somewhere.
>
> What kind of DNS problem? Server or client? I can telnet to the port  
> 143 without a delay.

Probably the same as <https://bugzilla.mozilla.org/show_bug.cgi?id=231607>.

Try this on your fetchmail 6.3.1 source directory (requires Perl installed):

perl -ple 's/([AP])F_UNSPEC/\1F_INET/g' -i.bak \
     checkalias.c driver.c env.c servport.c

Then rebuild and reinstall fetchmail 6.3.1 and let us know if the
problem is gone.

Merci.

-- 
Matthias Andree

Re: [fetchmail-users] SSL authentication problems with Gmail

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

Sebastian Tennant <se...@sm...> writes:

>>> OK, added another `-v' and it just lists the Thawte server as well...
>>>
>>>   fetchmail[4584]: starting fetchmail 6.3.1 daemon
>>>   fetchmail[4584]: 6.3.1 querying pop.googlemail.com (protocol POP3) at Wed Jan  4 11:47:17 2006: poll started
>>>   fetchmail[4584]: Issuer Organization: Thawte Consulting cc
>>>   fetchmail[4584]: Issuer CommonName: Thawte Premium Server CA
>>>   fetchmail[4584]: Server CommonName: pop.googlemail.com
>>>   fetchmail[4584]: pop.googlemail.com key fingerprint: 46:8B:6C:F4:3E:4C:56:29:83:54:2C:37:42:F1:67:80
>>>   fetchmail[4584]: 6.3.1 querying pop.googlemail.com (protocol POP3) at Wed Jan  4 11:47:18 2006: poll completed
>>>   fetchmail[4584]: Query status=2 (SOCKET)
>>>   fetchmail[4584]: sleeping at Wed Jan  4 11:47:18 2006
>>
>>Looks like it never talks to the POP server.  Can you drop the "port
>>995" and "sslcertck" options from your fetchmailrc and see what you
>>get.
>
> Removed these lines and it works.  Thanks to everyone who helped.

Well, I checked the source code and found no code path where SSL
certificate verification would fail without leaving log messages, such
as 1. the actual error and 2. "SSL connection failed".

POP3 was configured explicitly, so "port 995" forth or back doesn't make
a difference either -- removing this option can only make things worse,
not better.

Remains the question after sslcertck -- it will log trouble, too, EXCEPT
if a certificate at greater depth causes a preverification failure
without setting the error code in the X.509 context variables (and we'd
still get "SSL connection failed" in this case).

It appears as though the server dropped the connection after the SSL
negotiation and before the greeting, or that your log information is
incomplete.  Your logging appears to be from syslog, so could you post
your syslog.conf or syslog-ng.conf (whichever you're *actually* using)?

Do you get more detailed logging with "fetchmail --nosyslog -vv -N -d0
--sslcertck --port 995"? Can you try running this and see if you still
get socket errors and if so, which errors they print?

Thanks in advance,

-- 
Matthias Andree

[fetchmail-users] SSL authentication problems with Gmail

[Sebastian T. <se...@sm...>]

>> OK, added another `-v' and it just lists the Thawte server as well...
>>
>>   fetchmail[4584]: starting fetchmail 6.3.1 daemon
>>   fetchmail[4584]: 6.3.1 querying pop.googlemail.com (protocol POP3) at Wed Jan  4 11:47:17 2006: poll started
>>   fetchmail[4584]: Issuer Organization: Thawte Consulting cc
>>   fetchmail[4584]: Issuer CommonName: Thawte Premium Server CA
>>   fetchmail[4584]: Server CommonName: pop.googlemail.com
>>   fetchmail[4584]: pop.googlemail.com key fingerprint: 46:8B:6C:F4:3E:4C:56:29:83:54:2C:37:42:F1:67:80
>>   fetchmail[4584]: 6.3.1 querying pop.googlemail.com (protocol POP3) at Wed Jan  4 11:47:18 2006: poll completed
>>   fetchmail[4584]: Query status=2 (SOCKET)
>>   fetchmail[4584]: sleeping at Wed Jan  4 11:47:18 2006
>
>Looks like it never talks to the POP server.  Can you drop the "port
>995" and "sslcertck" options from your fetchmailrc and see what you
>get.

Removed these lines and it works.  Thanks to everyone who helped.

>I'll stick my neck out and say that it's likely a local config or
>compilation error.  I had zero trouble getting fetchmail to pull my
>mail from GMail with the following fetchmailrc:
>
>poll pop.gmail.com
>        proto pop3
>        username "ME<AT>gmail.com"
>        password "PASS"
>        ssl

sdt

[fetchmail-users] Re: broken POP3 servers - future fetchmail policy (IMPORTANT) (was: [fetchmail]comcast.net and attachments - workaround)

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

Jakob Hirsch schrieb am 2006-01-04:

> Well, RFC 1939 says "Such message deletions are outside the scope of the
> POP3 protocol and are not considered a protocol violation." (thanks for
> pointing me to this chapter, btw)

Right, but I took your report as though your server doesn't wait until
QUIT, in which case it *is* a violation.

> Site policies always override RFC-specified behaviour, there's not much
> you can do about that.

If these site policies aren't explicitly allowed by the RFC, they site
is not in compliance, and all bets WRT client function are off.

> > If talking to the admins doesn't resolve their bad behavior, find a
> > different server.
> 
> It's my university's server...

So unless it's in the AUP ("Nutzungsbedingungen") or other relevant
documents, they're trashing your mail without informed consent, and thus
punishable according to German law.

Check the paperworks and unless you (perhaps implicitly) agreed to such
a policy, talk to them.

Most sites refuse new messages if the mailbox size exceeds a quota, or
delete old messages after a month or so.  That would solve the problem
on either side: you can use several clients, they can limit the disk
space consumption.

> > Loss scenario: What happens if the client crashes between the server's
> > shipping CRLF.CRLF and storing the message? Whoops, the server deleted
> > the message, and the client retry.
> 
> Not necessarily. Consider a normal POP3 server, only that he does an
> implicit DELE after each RETR. Of course, a client could still fail to
> store the message (or to forward it somewhere, like fetchmail) without the
> server noticing. But only if the client tries to behave nicely and sends
> QUIT even after something went wrong. In this case, nice behaviour does
> not pay off.

Will check.

> >> What changes do you plan for the seen tracking? To do it on the client
> >> side is already possible with the UIDL option.
> > UIDL is not an option, but a necessity.
> 
> For simply retrieving mail, delivering locally, retry in case of failure?
> I don't see why.

1. Because it is the only reliable alternative to "fetchall nokeep",
   independent of the current TOP-vs-RETR discussion.

2. Because the assumption fetchmail were the only client doesn't hold in
   many cases (such as yours) and isn't reasonable either.

3. Because servers are often subjected to what I see as "empirical
   programming" - write server code that appears to work with Outlook
   Express at first glance, rather than writing standards compliant code
   that is in compliance with RFC-1939.

-- 
Matthias Andree