fetchmail-devel — Development related discussion

[fetchmail-devel] [Bug #18984] Relocating pidfile, FETCHMAILHOME, parallel

[<ad...@be...>]

Bug #18984, was updated on 2013-Apr-26 06:17
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: grarpamp
Assigned to : none
Summary: Relocating pidfile, FETCHMAILHOME, parallel

Details: I needed  to work around the lack of --password and also
fetch some things in parallel.

FETCHMAILHOME didn't seem to honor itself if set to an
empty writeable dir. [bug #1]

There was --pidfile, but it needed to be parallelizable to
avoid clobbering itself. By default it has no random part.
So --pidfile $(mktemp group1.pid.XXXXXX). [feat #1]

Looking to fix b#1 for others.
Note f#1 also applies to idfile, etc.


For detailed info, follow this link:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=18984&group_id=1824

[fetchmail-devel] [Bug #18983] Man page table rendering, keywords

[<ad...@be...>]

Bug #18983, was updated on 2013-Apr-26 05:47
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: grarpamp
Assigned to : none
Summary: Man page table rendering, keywords

Details: FreeBSD 8.x i386
nroff -man fetchmail.man
There seems to be some 'Keyword/Option Summary'
tables, but they just render to what may be a long linewrap
with the above nroff.

And from TODO, some projects use tables for this too.
'- Add info whether Keywords are global, server or user keywords'

       l l l lw34.  Keyword   Opt  Mode Function _ set daemon     -d        T{
       Set  a  background  poll  interval  in  seconds.   T}  set   postmaster
                     T{  Give  the  name  of  the  last-resort  mail recipient
       (default: user running fetchmail, "postmaster" if run by the root user)
       T}  set     bouncemail             T{  Direct  error mail to the sender
       (default) T} set no bouncemail             T{ Direct error mail to  the
       local postmaster (as per the 'postmaster' global option above).  T} set
       no  spambounce              T{  Do   not   bounce   spam-blocked   mail


For detailed info, follow this link:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=18983&group_id=1824

Re: [fetchmail-devel] [fetchmail-users] master: TODO.txt

[grarpamp <gra...@gm...>]

>> #### config flexibility
>> Consider making 'poll [thing]'s thing just a label string. And
>> breaking apart the config into types:  'polls' with 'poll [label]',
>> 'hosts' with 'host [label]', and 'accounts' with 'account [label]'.
>> Put whatever you want in a label ... 'blah' 'jo...@sc...',
>> 'foo.com', '1.2.3.4' ... but treat it as a label.
>
> Basically we're already quite close, we'd only have to make sure that
> adding a poll argument on the command line permits specifying an
> account. See <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705291>,
> for instance.
>
> Your notion of
> poll thing   host foo.example.org   account blah
> is spelt
> poll thing   via foo.example.org    user blah
> today :-)

Well sortof, except that in the absence of a 'via', the poll
'thing' is treated as actual user data, not merely a part of,
or a private label for, the FM config building engine. It
almost seems multiplexed and needs to explicitly not be.

I have one of mine constructed as, with n incremented
poll sections, but can't remember why...
poll user1@fqdn1
 via fqdn
 username user1@fqdn1

Additionally, who wants to literally poll a host as in 'poll host'?
You generally in mind want to poll an account, or some accounts,
and then figure out where they are.
Though there's probably value in some shorthand submechanism
to in fact poll everything that configures out to be residing at the
same host. But I think giving accounts their independance from
hosts and their configuration would come first.

This was/is all a sleepy draft... I think I meant the following but would
need to think on it all more...

# polls
poll play
 account play1
 account play2
poll kids
 ...

./fetch  # all polls, or maybe as ./fetch -p, whatever the default
./fetch -p play,kids  # some listed polls, perhaps even '-p !work'.

> Collect all poll types into a set for daemon or oneshot runs.

I don't think I meant this as a parallel thing, but if no specific
poll specified,
collate them all from the config for serial processing, whether daemon
or cmdline oneshot (-N).

> We lack group selection capability, though, as detailed in the Debian
> BTS report linked above.

Reading just the report, I thought it was a logic issue. Then
the response tied in with this.

> bug reports.

Routers often have a mode that emits the config as interpreted, but
with private info such as passwords hashed out, for posting, storing,
etc.


### parallel stuff

> And require particular attention in tracing output (and possibly imply

Possibly refer to some threading might be early bits below.

> Well, the other frequently asked feature is "poll multiple hosts at the
> same time" (especially on high-speed-but-high-latency-links, such as
> DSL, satellite), which needs to go hand in hand here.

Possibly refer to some maildir yes bits below.

> The actual multithreading-the-input is not too hard to come by, the

I'm not sure for fetchmail to be threaded/forked in general right away.
Though I did throw it in there with the different 'interval [time]' hints.

A gotcha with multiples... if a user has them, they may wish them to
appear to be reasonably separate to an observer. If they keep polling
the same accounts at the same time and not via different nets or shared
proxies, they're linkable. Though if the config was a bit more flexible the
equivalent of cron plus a random jitter driving ./fetch -a accountX
would work instead of threading out the 'interval [period + jitter]' polls.

Fetchmail > server... surely an account must be serial locked
to prevent dupes inbound and various server state issues.

> question is how to limit the output side, and to assess if that is
> necessary.

FM > MDA > maildir, maildir can handle it just fine. I often have 10
or more fetches dumping into a maildir at once. Except for
old offline archives, there's no mbox here :) Other than ensuring
fetchmail can be externally driven that way with say one FM
config file, and a state issue doc warning against polling the same
account in parallel, parallelizing FM itself seems a lot of work right now.

> If you think ISP-grade "POP collector option"
> you may want to configure "poll 50 accounts at the same time but only
> use 20 outbound SMTP threads".  This requires caching mail, either in
> RAM, or on disk.

You mean loop through all 50 polls with a 20 wide parallel sliding
window... I'd think FM > MDA > maildir would eliminate cache so long
as say maildrop had safe tmp file creation and return codes back to FM.
I admit not having looked into that. And I'd warn against mbox if any of
this is pursued.

Re: [fetchmail-devel] [fetchmail-users] master: TODO.txt

[grarpamp <gra...@gm...>]

> Up front, thanks a bunch for the feedback.  We should move to

BTW, 6.3.26 happens to work here. Now if I could just get --password
before I end up stealing the framework for it from some other option :)

> I am wondering - especially about switching SSL library, too, because
> OpenSSL requires you to jump quite through a few hoops for even standard
> stuff, like CRLs and OCSP.

Don't know much there, not really a programmer that way. Haven't
got around to trying the GNUTLS binary cert tools yet either.
https://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations

> to have someone willing to tell users in the fetchmail lobby how to make

I'm hoping to search out some overall cert security docs online for
this someday. They'd be far better and easier to point to.

> The missing link is that you hardly ever get the certificate
> fingerprints on the "how to configure Outlook, blahmail, whatever for
> fetching mail from us" on the ISP help pages, or even better, by snail
> mail when they send you account data.

I do see some that show GUI pics and so forth, though they're
usually related to accepting a self-signed or intermediate cert.
There are often some short blog style posts if you search out some
problematic FP you're dealing with. I'll be testing pinning with Firefox
then Thunderbird sometime this year. Maybe the world will come
up with a better cert scheme in a few years.

Re: [fetchmail-devel] [fetchmail-users] master: TODO.txt

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

Am 24.04.2013 10:37, schrieb grarpamp:
> Noted some things
> 
> - blacklist DigiNotar/Comodo/T<C3><BC>rktrust hacks/certs, possibly
> with Chrome's serial# list?
> 
> I would not hardcode this but instead place fingerprints in multiple
> global/per_host 'fpdeny' config options. In part because testing
> infrastructure with these certs is valuable. And at least that way,
> even if they're lazy and only use sslcertck, if some emergency
> arises they can add a negative print there affecting global/per_host.
> Additionally, point the user to where they can find and then build
> their own updated cert store free from all such junk. As well as
> point them to some doc about the importance of fingerprint checking.

Up front, thanks a bunch for the feedback.  We should move to
fetchmail-devel though...

I am wondering - especially about switching SSL library, too, because
OpenSSL requires you to jump quite through a few hoops for even standard
stuff, like CRLs and OCSP.

> https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1
>   ftp://ftp.mozilla.org/pub/security/nss/releases/
> https://github.com/agl/extract-nss-root-certs.git

> I'll try to remember to add this to the 'cert' ticket when I find
> it again.

<http://svnweb.freebsd.org/ports/head/security/ca_root_nss/files/MAca-bundle.pl.in?revision=312617&view=markup>

> - CRYPTO: remove sslfingerprint? too easily abused (see NEWS)
> 
> I trust this is by now just an old entry. If not, please don't :)

This line is to be dropped from TODO.txt -- I've seen too many
certification "authorities" that did not deserve this name, and I seem
to have someone willing to tell users in the fetchmail lobby how to make
_good_ use of this feature.

The missing link is that you hardly ever get the certificate
fingerprints on the "how to configure Outlook, blahmail, whatever for
fetching mail from us" on the ISP help pages, or even better, by snail
mail when they send you account data.

> #### config flexibility
> Consider making 'poll [thing]'s thing just a label string. And
> breaking apart the config into types:  'polls' with 'poll [label]',
> 'hosts' with 'host [label]', and 'accounts' with 'account [label]'.
> Put whatever you want in a label ... 'blah' 'jo...@sc...',
> 'foo.com', '1.2.3.4' ... but treat it as a label. 

Basically we're already quite close, we'd only have to make sure that
adding a poll argument on the command line permits specifying an
account. See <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705291>,
for instance.

Your notion of

poll thing   host foo.example.org   account blah

is spelt

poll thing   via foo.example.org    user blah

today :-)

We lack group selection capability, though, as detailed in the Debian
BTS report linked above.

> Collect all poll types
> into a set for daemon or oneshot runs. Account types are
> always singly available for commandline oneshot's. 'netaddr'
> may be fqdn, or ip (dns down/insecure scenario). Error out
> if a label dependency does not exist. Order of types in file
> does not matter, indented bits are type content. Includes
> work.

That would be missing.

> 
> ./fetch -p  # polls
> ./fetch -a play2
> ./fetch -a mywork -h work1_pop  # temporary swap :)
> ./fetch -a play1  # bombs on foo1
> 
> It's really really hard to get fetchmail to do anything like this
> today. Unless you forget it and frontend it with your own config
> and call engine. These sort of configs are powerful.

And require particular attention in tracing output (and possibly imply
"verbose" mode) so that we can give users a hint what they are doing and
what fetchmail is making of it, so that we can later properly dissect
bug reports.

Well, the other frequently asked feature is "poll multiple hosts at the
same time" (especially on high-speed-but-high-latency-links, such as
DSL, satellite), which needs to go hand in hand here.

The actual multithreading-the-input is not too hard to come by, the
question is how to limit the output side, and to assess if that is
necessary.

If you think ISP-grade "POP collector option" (disregarding it violates
most site's security policy to share credentials with another entity),
you may want to configure "poll 50 accounts at the same time but only
use 20 outbound SMTP threads".  This requires caching mail, either in
RAM, or on disk.

I have updated the master's TODO.txt a tiny bit (near the end).

[fetchmail-devel] [Bug #16000] fetchmail should support multiple sslfingerprints

[<ad...@be...>]

Bug #16000, was updated on 2009-Jul-15 20:40
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprints

Details: Some mail servers, such as pop3.live.com, have multiple hosts available at a single IP address (currently pop3.live.com appears to have two hosts behind that one IP address).

Other mail servers, such as imap.gmail.com, resolve to rotating IP addresses.

It should be possible to specify multiple 'sslfingerprint' entries so that any one of those fingerprints can match.


Follow-Ups:

Date: 2013-Mar-13 22:36
By: grarpamp

Comment:
There also needs to be a facility to list multiple acceptable
fingerprints per host, aka: account / poll.

This is needed because there are often cases where
there are multiple hosts behind a single hostname,
whether by DNS, anycast, load balancers, etc...
and those hosts do not all have the same certificate.
The certs are often valid but may be regionally managed,
in a state of local testing, being rolled out over time,
rolled out with overlap in expiry times, or any number
of other cases where this becomes necessary.

For example, right now, depending on where you are
in the world, fetchmail will choke at least half the time
on pop3.live.com for any user who has configured
a fingerprint.

I'm adding this here because it's in the same work area

It would be nice to see some work occur in this area.
Thanks.
-------------------------------------------------------

Date: 2010-Apr-09 03:49
By: m-a

Comment:
I have reconsidered the issue and raised the bug priority.

It would seem that such a security feature is warranted even in a stable release to counter MITM attacks that exchange certificates on the flight.
-------------------------------------------------------

Date: 2009-Aug-19 05:13
By: m-a

Comment:
reopening after grarpamp's comments.

On the suggestion, based on the rationale below, I might indeed rather correct the documentation and indeed support certificate fingerprint lists. I do however not subscribe to the assertion that the fingerprint were necessary to detect MITM attacks - the certificates should be sufficient as long as you're happy with the signing CA's verification policies (including the hash used).

I currently second the view that verifying both the MD5 and SHA1 of a certificate has been considered reasonably safe recently, i. e. I'm not aware of efficient attacks that collide both MD5 and SHA1 at the same time.

I wonder if the hash grouping can be configured in a simpler way, for instance --sslfingerprint {MD5}DE:AD:BE:...:EF&{SHA1}F0:0D:04:13:...:37 or similar. I'll need to think about this a bit more when it comes to the real implementation. It may be awkward to edit on your netbook screen or smartphone, but it's likely simpler to implement.

Given this is more a feature request than a real bug, it will probably not make a 6.3.X release though.
-------------------------------------------------------

Date: 2009-Aug-11 17:55
By: grarpamp

Comment:
Adding content for those who use this interface... 

Hi :) Folks appear to be misunderstanding things
about the underlying crypto and why fingerprints are a necessary
safety check.

If one simply relies on checking the cert chain and blindly trusts
that model, as most of the world is conditioned to believe it is
sound, you are open to attack. Namely, of the sort in the posted
url, it is a good read, as are the referenced prior art. Both MD5
and SHA1 are theory broken and MD5 demonstrably so, as noted in the
literatre. So the hash part is of concern, at least in this case.

A CA takes a MD5 over certain fields in the cert and signs that MD5
digest, not the entire cert contents. CA's previously used MD5 and
failed to change their cert practices to SHA1 until a real world
break, oops. Anyways... So I don't have to swipe their private key.
All I have to do to forge a server cert is copy the signature from
any candidate real cert into my cert and manufacture the rest of
my cert contents so that they: a) work, b) make the fields have the
same digest as the real one. Which, as we all know by now is possible,
given time or new art, due to the whole hash collision thing.

However... if I copy a known good cert via trusted channels, and
take both the MD5 and SHA1 fingerprints of the DER form of that
cert, it's much closer to cryptographically impossible to manufacture
a cert that would match evarything. I could just as easily make
formal contact with the cert holder and get the prints that way or
receive them as part of a high security programme. Banks do this.

So there are two different fingerprints covering different areas.

Checking fingerprints over the entire DER cert will foil this attack
because it detects the contents that I manipulated to match the
field digest that was later signed. That is why openssl, browsers,
ssh, etc provide fingerprint calculating and verification functions...
totally separate from signature calc/verif capabilities.

So two types of checks should always be performed for maximum
security:

 A) cert chain trust = sig(hash(contents)) -> pki
  This is done with openssl verify -verbose
  aka: sslcertck
 B) DER fingerprint = hash(sig(hash(contents))
  This is done with openssl x509 -in <PEMcert> -noout -fingerprint -<sha1|md5>
   or
  openssl x509 -in <PEMcert> -outform DER | <sha1|md5>
  aka: sslfingerprint... with the enhancements in the prior note

Enhancing fetchmail to doubly check B with both MD5 and SHa1 shouldn't
be much extra coding or user effort. As an aside, it's fairly common
to find places using/publishing both hashes for various purposes.

Removing the check in B places all the beans on the hash function
in A, which is not good. Private keys are not even involved in this.
Defense in depth will save your butt :)

Give the user tools, let them decide how many they wish to deploy
and manage. I would adapt the docs to say that one should use both
A and B, or neither, with some short reasons why. And continue to
provide example openssl usage as is there now, to allow them to
accomplish it.

Note1: Not checking the fingerprints on self-signed certs... such
as are commonly found in internal corporate nets, edu's, org's, and
the many end user, developer, hacker and other low budget/tier
sites... is asking for trouble. Not publishing your prints, signed
by OpenPGP, is bad too.

Note2: The random serial fix just helps eliminate easier forms of
the hash collision attack, see the paper. It doesn't necessarily
prevent other forms or completely new math attacks, and definitely
doesn't prevent brute force.

Note3: The lists.berlios.de cert is expired, and MD5, though that
doesn't matter :) The Berlios_CA cert may be self-signed.

I'm out of time at the moment to
help out with correcting what is already in here, perhaps later.

Thanks again for keeping up with all the maintenance to fetchmail :)
-------------------------------------------------------

Date: 2009-Aug-11 17:50
By: none

Comment:
Adding content for those who use this interface...

Hi all :)

Fetchmail needs the ability to specify multiple 'sslfingerprint'
options and digests per 'poll' stanza.
  
I noticed this when connecting to gmail. I think it's a load sharing
thing providers use. Google also has their own intermediate CA now
so more cert deployments could be expected.
  
At the moment, if you specify multiple sslfingerprint rc lines or
command line options, only the last one specified is checked. Any
prior sslfingerprint options are silently ignored. And the only
digest available is md5.
  
This is obviously frustrating users mail collection attempts :(
  
  
To reproduce the problem, run this and examine the certs and hashes.
The gmail certs happen to verify back to the root CA's. The
44a8...f1a9 cert occurs more frequently, the 9273...9f33 cert is
rarer. I've attached them both and the CA's involved.
  
If you are not seeing multiple certs, you may need to 'travel' and
debug with different source ip addresses... such as provided with
a worldwide proxy network like Tor.
  
i=10 ; while : ; do
 LD_PRELOAD=/tmp/tor/libtsocks.so.1 TSOCKS_CONF_FILE=/tmp/tor/tsocks.conf \
  openssl s_client -connect pop.gmail.com:pop3s < /dev/null > tcert$i 2>&1
 echo -n "$i: "
 openssl x509 -noout -fingerprint -md5 -in tcert$i
 i=`expr $i + 1`
done
  
  
Also related... from the BRANCH_6-3 NEWS file:
  
* --sslfingerprint may be removed from a future fetchmail version,
 because it's just too easily abused to create a false sense of
 security.
  
PLEASE don't remove this feature. I like it a lot and use it
everywhere possible, with --ssl and --sslcertck at the same time
as well, from trusted sources beforehand of course. Knowing when
the cert changes out from under you is very useful, even if only
for debugging or system verification. Especially if you connect
from untrusted locations or paths. Or you want to know about and
resolve them. It's also handy if the machine a user is connecting
from has a poor, untrusted or nonexistent collection of CA certs.
In that case, just the digest can be imported and used. Note that
openssl does not ship with a CA cert collection... admins usually
have to get it from mozilla... if they value PKI enough to think
of and bother with it.

There are blurbs in the man page that even talk about self-signed
certs being accepted with 'sslcertck'.


Overall, it would be good to see this feature enhanced to do both
md5 and sha1 to make cert collision attacks much more improbable
going forward... at least until the NIST 'SHA-3' hash competition
is done and that trickles down to the CA's and apps years from now.
Usage in the case of a single cert, where both must match, might
be like...

poll
 sslfingerprint-md5 <fp_md5>
 sslfingerprint-sha1 <fp_sha1>

In the case where multiple certs may be presented, group the hashes
as a set. Both hashes in the set must match. First check set cert1,
then set cert2, then set cert[n] until one set, or none, match the
presented cert...

poll
 sslfingerprint-cert1-md5 <fp_md5>
 sslfingerprint-cert1-sha1 <fp_sha1>
 sslfingerprint-cert2-md5 <fp_md5>
 sslfingerprint-cert2-sha1 <fp_sha1>
 sslfingerprint-cert[n]-md5 <fp_md5>
 sslfingerprint-cert[n]-sha1 <fp_sha1>

The '--' command line version of this should also do the right
thing.

Fetchmail should also print both the md5 and sha1 fingerprints from
the received certificate in the debug output.

Note that openssl supports mdc2, md2, md5, sha1. I understand that
some CA's also used, or may still use, the non-sha1 digests. Though
I guess sha1 is the only one used by sane CA's for new certs these
days. I don't know how many old ones are still in use on hosts. md5
and sha1 are enough until SHA-3.

And since the past always seems to apply to some future scenario
with new twists, this is surely not the last of the breed to be
proven out: http://www.win.tue.nl/hashclash/rogue-ca/

Extra checks are always good thing to have available.
Openssl probably has simple library routines to do this.

Thanks guys, and for fetchmail too, been using it for years :)
-------------------------------------------------------

Date: 2009-Jul-16 14:20
By: m-a

Comment:
Compatibility. Basically 6.3.X should be as compatible with 6.2.0 as reasonably possible - and it turned out that 6.3.X has lived for quite a while now... Compatibility was needed at the time to pave the upgrade path for 6.2.X users, as 6.3.0 had around one hundred bug fixes over 6.2.5 - and those were more important than cleanups.
-------------------------------------------------------

Date: 2009-Jul-16 11:44
By: jw9

Comment:
Good.

You should remove sslfingerprint asap.

Cannot understand why the feature was implemented in the first place.  And why such a broken "feature" has endured for so long.

Have a nice day.

-------------------------------------------------------

Date: 2009-Jul-16 09:19
By: m-a

Comment:
[Now the bug tracker is messing things up, my comment appeared twice in spite of being submitted once around 14:35, not again at 15:03. Sorry for that, but it has happened outside my control.]

I don't doubt your technical and intellectual skills to download the server's certificate or its fingerprint. BUT then your security hinges on the useless assumption that your connection is not under attack in the very moment that you're downloading the cert/fingerprint. You can't know if you're under attack unless you can verify the FP through a secure channel: You're using the same channel you'd later use for the actual mail-fetching connection; so you'd happily download the attacker's certificate or fingerprint.

Fetching the fingerprint through a DIFFERENT or at least a known-secure channel is crucial here.

I will not abolish the option for 6.3.X versions for compatibility reasons. If I'll drop it later is left for later decision, as the fingerprint is the easier alternative compared to downloading the *server* certificate and stuffing it into <prefix>/ssl/certs/. The canonical way is still to install the root-signing certificate though.

I don't see much use in listing hundreds of ssl fingerprints and keeping that list up to date when instead you can just save the certificate of the signing CA. It's less of a hassle. And if you can't trust, for instance, CyberTrust, then don't install their certificate, but Microsoft's certificate instead - providing you have a way of verifying that...

I'll see to marking the sslfingerprint feature candidate for removal for 6.4.X or newer fetchmail releases.
-------------------------------------------------------

Date: 2009-Jul-16 09:03
By: m-a

Comment:
Two things:

1a. sslfingerprint is unnecessary in "--sslcertck --sslproto tls1" and in "--sslcertck --sslproto ssl3 --ssl" configurations, and shouldn't be used. It doesn't add security unless your ISP provides you with the finger prints through a separate channel (such as your walking up to the site and fetching a sheet with finger prints).

The assumption is that the MITM (=attacker) cannot forge the signature of the certification authorities you trust. He may forge the server's certificate, but he'll hardly be able to forge the root signing certificate from Equifax, Verisign, or whoever. sslcertck is sufficient unless you follow stupid guides that suggest capturing and saving the server certificate (while that works to shut up complaints about certificates, it doesn't add protection against MITM attacks: you might already download the counterfeit certificate that you save as trusted, if you're already under attack at the time).

1b. sslfingerprint, as you observed, isn't useful with certain load balancing setups, when servers have individual certificates that are signed by a common CA.

2. for complaints about the newest-first ordering of the comments, please file a support request against BerliOS itself, not against individual projects.
-------------------------------------------------------

Date: 2009-Jul-16 09:02
By: jw9

Comment:
I can determine the proper fingerprint from any other server on any other network that I have access to.  I don't have to ask any "ISP" to provide fingerprints through another channel because I am quite able to do that myself.

So, as you state, it does add extra security.  Especially in today's world where most people have access to more than one "ISP" or network (eg your workplace if you have one, and most people do!).

In which case you should allow a set of sslfingerprints to be specified.

Otherwise, to be consistent with your argument (that sslfingerprint is unnecessary), you should completely remove the sslfingerprint option.

Fix it or lose it.

-------------------------------------------------------

Date: 2009-Jul-16 08:35
By: m-a

Comment:
Two things:

1a. sslfingerprint is unnecessary in "--sslcertck --sslproto tls1" and in "--sslcertck --sslproto ssl3 --ssl" configurations, and shouldn't be used. It doesn't add security unless your ISP provides you with the finger prints through a separate channel (such as your walking up to the site and fetching a sheet with finger prints).

The assumption is that the MITM (=attacker) cannot forge the signature of the certification authorities you trust. He may forge the server's certificate, but he'll hardly be able to forge the root signing certificate from Equifax, Verisign, or whoever. sslcertck is sufficient unless you follow stupid guides that suggest capturing and saving the server certificate (while that works to shut up complaints about certificates, it doesn't add protection against MITM attacks: you might already download the counterfeit certificate that you save as trusted, if you're already under attack at the time).

1b. sslfingerprint, as you observed, isn't useful with certain load balancing setups, when servers have individual certificates that are signed by a common CA.

2. for complaints about the newest-first ordering of the comments, please file a support request against BerliOS itself, not against individual projects.
-------------------------------------------------------

Date: 2009-Jul-16 07:09
By: jw9

Comment:
It would appear that additional comments appear in a push-down stack order.  This makes it very hard to follow the natural order of things.  This is very strange.

Here in the western world we are used to reading left-to-right and top-to-bottom.  We certainly don't expect to have to read from bottom-to-top.

I suppose I can turn my monitor upside down and then they might follow in a proper order.  But wait, that would make the characters appear upside-down!

In any case, if one is to be able to check the sslfingerprint of a server to protect against man-in-the-middle attacks, and if the fingerprint does actually change randomly (and not because of a man-in-the-middle attack), then we need to be able to specify a set of fingerprints and only require that at least one of them matches.

-------------------------------------------------------

Date: 2009-Jul-16 07:03
By: jw9

Comment:
Why do comments appear in such a strange place (after my original submission)?  Shouldn't additional comments follow in a logical order after other people's followup comments?  Very strange!

-------------------------------------------------------

Date: 2009-Jul-16 07:00
By: jw9

Comment:
II think you misunderstand.  The sslfingerprint is used to verify the identity of the server and to protect against man-in-the-middle attacks.  The configuration also has proper certificate and "ssslcertck" and "sslcertpath" settings.

To protect again man-in-the-middle attacks one needs to be able to ensure that the fingerprint of the server hasn't changed.

-------------------------------------------------------

Date: 2009-Jul-16 06:33
By: m-a

Comment:
I don't think fetchmail should do that.

sslfingerprints are just a convenience shortcut, and closely resemble stuffing the server's certificate into the directory of trusted certification authority certificates, usually /usr/ssl/certs, /etc/ssl/certs (and running c_rehash afterwards), or similar.

The canonical way is to install the GTE CyberTrust Global Root (for Microsoft/live.com) or the Equifax Secure Certificate Authority (for Google Mail) and use certificate-based authentication.

See also:
http://gagravarr.org/writing/openssl-certs/others.shtml
-------------------------------------------------------

For detailed info, follow this link:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=16000&group_id=1824

[fetchmail-devel] New Vietnamese PO file for 'fetchmail' (version 6.3.24.1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Vietnamese team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/vi.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Danish PO file for 'fetchmail' (version 6.3.24.1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Danish team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/da.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Brazilian Portuguese PO file for 'fetchmail' (version 6.3.24.1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Brazilian Portuguese team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/pt_BR.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Esperanto PO file for 'fetchmail' (version 6.3.24.1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Esperanto team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/eo.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Swedish PO file for 'fetchmail' (version 6.3.24.1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/sv.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Polish PO file for 'fetchmail' (version 6.3.24.1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Polish team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/pl.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Japanese PO file for 'fetchmail' (version 6.3.24.1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Japanese team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/ja.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Czech PO file for 'fetchmail' (version 6.3.24.1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Czech team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/cs.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New French PO file for 'fetchmail' (version 6.3.24.1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the French team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New template for 'fetchmail' made available

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to <coo...@tr...>.)

A new POT file for textual domain 'fetchmail' has been made available
to the language teams for translation.  It is archived as:

    http://translationproject.org/POT-files/fetchmail-6.3.24.1.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

    http://home.pages.de/~mandree/fetchmail/fetchmail-6.3.24.1.tar.xz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Chinese (simplified) PO file for 'fetchmail' (version 6.3.22.2)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Chinese (simplified) team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/zh_CN.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: [fetchmail-devel] [fetchmail-users] "retained" in fetchmail log

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

On Fri, Mar 1, 2013 at 4:44 PM, Matthias Andree <mat...@gm...> wrote:
> I see these alternatives:
>
> A1 - the obvious option would be to add a "noretain" keyword that would
> tell fetchmail to never retain messages.
>
> A2 - the less obvious option I have suggested, and that is to require
> that servers do not expose their internals to clients, and remove the
> kludge code in fetchmail for good (although it is tiny enough to not
> care about code size).
>
> A3 - I might also, instead of A1, default this code to off and add a
> "kludge-retain-folder-internal-data" option, which would be somewhat
> quieter than in fetchmail 6.3.X.
>
> Opinions?

A2 makes the most sense to me for 7.0. If you weren't already making a
number of significant changes I'd have supported A3, but you are so
it's probably time to abandon support for things superseded
(repeatedly) over a decade ago ;)

-- 
                 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-devel] [fetchmail-users] "retained" in fetchmail log

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

Am 01.03.2013 08:23, schrieb Pierre Frenkiel:
> On Thu, 28 Feb 2013, Matthias Andree wrote:
> 
>> Arguably, if fetchmail knows that _all other_ messages have been
>> deleted, it could delete this folder internal data message because there
>> is no sensible mailbox state left.
>>
>> Arguably, the server software could also hide this special message so
>> that clients do not need to bother with server's idiosyncrasies.
>>
>   Actually, when I went to the server (via webmail) I saw that
>   the X-IMAP message was the only one remaining. IMHO, fetchmail
>   should know that also.

Greetings,

I have revisited the UWIMAP FAQ, and found items 6.14, 6.15 and 7.44 of
interest:

<http://www.washington.edu/imap/IMAP-FAQs/index.html#6.14>

I am now considering what to do with the next somewhat-incompatible
fetchmail release.

It would appear that the whole story developed out of this qpopper <->
uwimapd incompatibility, where qpopper 2.53 and older exposed the folder
internal data, whereas UW's ipop3d would not.

qpopper 2.53 and older should have long since been phased out, qpopper
3.0 (released in 2000, 13 years ago) was changed to fix that
incompatibility, and the recommendation is that versions older than 3.0
not be used;  qpopper 4.0 would also improve server-side performance (or
so the release notes claim) by caching a mailbox/message index.


Now, what am I to do with a future fetchmail 7.0 release?

I see these alternatives:

A1 - the obvious option would be to add a "noretain" keyword that would
tell fetchmail to never retain messages.

A2 - the less obvious option I have suggested, and that is to require
that servers do not expose their internals to clients, and remove the
kludge code in fetchmail for good (although it is tiny enough to not
care about code size).

A3 - I might also, instead of A1, default this code to off and add a
"kludge-retain-folder-internal-data" option, which would be somewhat
quieter than in fetchmail 6.3.X.

Opinions?
(beware: reply-to: fet...@li... set,
you must be subscribed there if you want to reply).

Best regards
Matthias Andree

Re: [fetchmail-devel] Future of fetchmail

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

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

Am 06.02.2013 20:14, schrieb John N Rayner:
> I have been following the development of version 7.0 of fetchmail and
> was very sorry to see the latest message by Matthias.  I, for one, would
> use it.  Has anyone done a survey of potential users?  From recent
> surveys by Linux Journal there are still a large number of pine (Alpine)
> and mutt users.  Presumably their email servers are using IMAP and pop.
> I hope someone will pick up the maintainer's job.  How about rfunk?
> That's Robert, isn't it?   John

John,

I believe there is a misunderstanding, and due to a past vacation that
was quite enjoyable, I have seen your concernful message only today.

To clarify: I have no plans to discontinue maintaining fetchmail.

I am, however, inclined to drop the MAPI support that never made an
official release.  I have never been able to test it, the response from
the contributor and another interested developer was too low to count on
them, and because there was virtually zero user interest.  I have, in
spite of repeated calls for test accounts, never received an Exchange
account to test against, and for these reasons, I have never really
integrated MAPI.

Note that MAPI (a Microsoft specific) is not to be confused with IMAP 4
(the IETF standard protocol).

POP3 and IMAP4rev1 will continue to be supported by fetchmail.

I will at some point in the not so distant future also cease development
of the 6.3.X versions, and only see to 7.0 and newer versions that may
break some compatibility (especially by removing support for systems and
protocols that got obsoleted more than a decade ago) so that fetchmail
can be made easier to use, in particular with respect to SSL/TLS.

For the majority of users, these plans should not cause any disruptions.
My dropping a feature that has never been part of an official release
has no impact at all, and removing corner cases and making the default
configuration more transparent and secure should help, rather than
impair, use of fetchmail.

Hope that resolves concerns.

Best regards,
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEir0cACgkQvmGDOQUufZX3WACg0RiMZnHfEWUAv6AHD9Em7Cb1
yRgAnROjzpzjBdSLlnXjGNTZCIgZFp+I
=C0UP
-----END PGP SIGNATURE-----

Re: [fetchmail-devel] minor bug fixes for socket.c

[John B. <joh...@or...>]

Matthias> I have applied your patch as commit
Matthias> e4dd196b137223195739b9e0f50ec2a8a02b3534 in the Git repository, and
Matthias> it is to appear in a future 6.3.25 bug-fix release and in the next
Matthias> 7.0.0 alpha release. I added a changelog entry to NEWS...

Matthias> Thanks again for checking, fixing, and reporting these problems.

My pleasure; thank you for committing these changes.

-- John

http://blogs.oracle.com/jbeck/

Re: [fetchmail-devel] minor bug fixes for socket.c

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

John,

I have applied your patch as commit
e4dd196b137223195739b9e0f50ec2a8a02b3534 in the Git repository, and it
is to appear in a future 6.3.25 bug-fix release and in the next 7.0.0
alpha release. I added a changelog entry to NEWS:

> # BUG FIXES
> * Fix a memory leak in out-of-memory error condition while handling plugins.
>   Report and patch by John Beck (found with Parfait static code analyzer).
> * Fix a NULL pointer dereference in out-of-memory error condition while handlin
>   plugins.
>   Report and patch by John Beck (found with Parfait static code analyzer).

Thanks again for checking, fixing, and reporting these problems.

Best regards,
Matthias

Re: [fetchmail-devel] minor bug fixes for socket.c

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

John,

thank you for investing the time to run the analyser, and to come up
with a patch.  I will review the patch soonish and consider it for
application.

Best regards,
Matthias

[fetchmail-devel] minor bug fixes for socket.c

[John B. <joh...@or...>]

Greetings,

First, while running a static code analysis tool (Parfait) on fetchmail, it
found some bugs:

Error: Memory leak (CWE 401)
   Memory leak of pointer 'plugin_copy' allocated with malloc((plugin_copy_len + 1))
        at line 137 of components/fetchmail/fetchmail-6.3.22/socket.c in function 'parse_plugin'.
          'plugin_copy' allocated at line 107 with malloc((plugin_copy_len + 1)).
          plugin_copy leaks when plugin_copy_offset >= plugin_copy_len at line 114.

Error: Null pointer dereference (CWE 476)
   Read from null pointer 'argvec'
        at line 189 of components/fetchmail/fetchmail-6.3.22/socket.c in function 'handle_plugin'.
          Function 'parse_plugin' may return constant 'NULL' at line 137, called at line 188.
          Null pointer introduced at line 137 in function 'parse_plugin'.
        at line 190 of components/fetchmail/fetchmail-6.3.22/socket.c in function 'handle_plugin'.
          Function 'parse_plugin' may return constant 'NULL' at line 137, called at line 188.
          Null pointer introduced at line 137 in function 'parse_plugin'.

(I realize these are on 6.3.22; I checked and verified that this portion of
the code is the same in 6.3.24.)

The attached patch fixes each of these.

Second, I originally sent this to the -users list per FAQ #G3.  It seems that
entry should be updated to indicate the -devel list instead.

-- John

PS I am skipping the usual six items requested per FAQ #G3, as they seem
   superfluous here. If anyone really feels the need for them, let me know.

http://blogs.oracle.com/jbeck/

[fetchmail-devel] Future of fetchmail

[John N R. <jr...@co...>]

I have been following the development of version 7.0 of fetchmail and
was very sorry to see the latest message by Matthias.  I, for one, would
use it.  Has anyone done a survey of potential users?  From recent
surveys by Linux Journal there are still a large number of pine (Alpine)
and mutt users.  Presumably their email servers are using IMAP and pop.
I hope someone will pick up the maintainer's job.  How about rfunk?
That's Robert, isn't it?   John