getmail and SSL IMAP

1's picture

Forums: 

I have problems with getmail receiving mail from one IMAP/SSL account.
This particular one sends some SSL certificate (forgive the perhaps inadequate terminology, I am new to this) and I suspect this may be the problem (i can fetch mail from this server without any problem using one of the all-in-one GUI email clients such as Thunderbird which asks me to accept the certificate).

The error returned by getmail is:
socket error ([Errno 110] Connection timed out)

My configuration file:

[retriever]
type = SimpleIMAPSSLRetriever
server = mail.somewhere.net
port = someport
mailboxes = ("INBOX","Sent")
username = someusername
password = somepass

[destination]
type = MDA_external
path = /usr/bin/procmail
unixfrom = True
user = someuser

[options]
read_all = false
message_log = logfile

Re: getmail and SSL IMAP

IntnsRed's picture

Disclaimer: I've never used GetMail.

But you're probably right about the certificate (double check the docs/manpage on that). With the upgrade to Squeeze, the newer fetchmail is more picky about self-signed certificates and warns that in the future you'll have to specifically include a switch to tell it to accept self-signed certs.

Just curious, what are the advantages/differences of GetMail over fetchmail?

Re: getmail and SSL IMAP

1's picture

In words of the author (excerpt from faq):

Why did you write getmail? Why not just use fetchmail?

Short answer: ... well, the short answer is mostly unprintable. The long answer is ... well, long:

I do not like some of the design choices which were made with fetchmail.
getmail does things a little differently, and for my purposes, better. In
addition, most people find getmail easier to configure and use than
fetchmail. Perhaps most importantly, getmail goes to great lengths to
ensure that mail is never lost, while fetchmail (in its default
configuration) frequently loses mail, causes mail loops, bounces
legitimate messages, and causes many other problems.

When people have pointed out problems in fetchmail's design and
implementation, it's maintainer has frequently ignored them, or (worse
yet) gone in the completely wrong direction in the name of "fixing" the
problems. For instance, fetchmail's configuration file syntax has been
criticized as being needlessly difficult to write; instead of cleaning up
the syntax, the maintainer instead included a GUI
configuration-file-writing program, leading to comments like:

The punchline is that fetchmail sucks, even if it does have
giddily-engineered whizbang configurator apps.

As an example, Dan Bernstein, author of qmail and other software packages,
once noted to the qmail list:

Last night, root@xxxxxxxxxxxxxxxxx reinjected thirty old messages from
various authors to qmail@xxxxxxxxxxxxxx

This sort of idiocy happens much more often than most subscribers know,
thanks to a broken piece of software by Eric Raymond called fetchmail.
Fortunately, qmail and ezmlm have loop-prevention mechanisms that stop
these messages before they are distributed to subscribers. The messages
end up bouncing to the wrong place, thanks to another fetchmail bug, but
at least the mailing list is protected.

--D. J. Bernstein

The maintainer also ignored dozens of complaints about fetchmail's
behaviour, stating (by fiat) that fetchmail was bug-free and had entered
"maintenance mode", allowing him to ignore further bug reports.

fetchmail's default configuration values frequently cause lost or
misdirected mail, and seem to be chosen to cause maximum pain and
inconvenience. From fetchmail's to-do file (emphasis mine):

Maybe refuse multidrop configuration unless "envelope" is _explicitly_
configured ... This would prevent a significant class of
shoot-self-in-foot problems.

perhaps treat a delivery as "temporarily failed" ... This is so you
don't lose mail if you configure the wrong envelope header.

fetchmail is famous for mangling messages it retrieves, rather than
leaving them alone as a mail-handling program should. getmail will add
trace information to messages (so you can see what happened, and when),
but will otherwise leave message content alone.

In addition, fetchmail has a long history of security problems:

* versions released before 20 June 2001 contain a buffer overflow, which
can be remotely exploited (see www.securityfocus.com/bid/2877 for
details). getmail is not vulnerable to buffer overflows, because
buffers in Python are dynamically sized.
* Another remotely-exploitable security hole discovered in fetchmail in
June 2002; versions prior to 5.9.10 (released in June 2002) are
exploitable .
* Reading fetchmail's UPDATES file, it appears that another security
problem was fixed in 5.9.12, where a server could crash fetchmail on
64-bit platforms. Also worrying is a mention that it includes a fix
for "password shrouding".
* Another remotely-exploitable security hole in fetchmail discovered in
September 2002; this hole lets an attacker run arbitrary code on the
victim's computer.
* Another remotely-exploitable security hole in fetchmail discovered in
December 2002; once again, a remote attacker can run arbitrary code on
the machine running fetchmail in its default configuration. See this
advisory for details.
* January 2003: More buffer overflows in fetchmail let attackers run
arbitrary code .
* October 2003: Anyone can cause fetchmail to crash by sending you a
message . Other problems are here , and I might have missed some .
* Just in case you thought fetchmail was all better now, there's still
new security problems being discovered in it. In December, 2005, it
was revealed that anyone can send a fetchmail multidrop user a message
that causes fetchmail to crash.

In July, 2004, it was noted that there may be at least 2 unfixed
denial-of-service attacks, 2 unfixed remote-code-execution, 2 unfixed
remote-user-access, and 3 unfixed remote-shell attacks against fetchmail.
See http://www.mail-archive.com/euglug@euglug.org/msg00971.html for
details

I've given up even trying to stay abreast of the various security holes in
fetchmail, but others have noted continuing problems, including:

* another arbitrary code execution vulnerability announced on 21 July
2005.

The fetchmail authors' boneheaded decision to create a configuration-file
GUI editor (rather than actually giving fetchmail a sane configuration
syntax) also came back to bite them in the ass: in October 2005, it became
known that fetchmailconf created its files in such a way that users'
passwords could be read during file creation.

Addendum, January 2007: since I wrote the above, the following new
security problems have been discovered in fetchmail:

* CVE-2005-4348 - anyone can crash fetchmail by sending messages without
headers
* CVE-2006-0321 - anyone can crash fetchmail by sending a message that
fetchmail tries to bounce
* CVE-2006-5867 - fetchmail can transmit passwords in plaintext even if
the user has configured it not to
* CVE-2006-5974 - anyone can cause fetchmail to crash by triggering
certain error code paths

But don't just take my word for it; see
http://docs.freebsd.org/cgi/mid.cgi?200102172349.QAA11724 and
http://esr.1accesshost.com/ (note: went offline sometime in 2009 or 2010;
the content is still available at
http://web.archive.org/web/20080621090439/http://esr.1accesshost.com/ ).

getmail users have not had to worry about any of these security holes or
design and implementation errors.

Re: getmail and SSL IMAP

1's picture

I think I solved the problem. I ripped off the certificate from the email server using openssl command.
If I ever manage to make exim deliver my emails through the smarthost, I'll write another book page about setting exim4, get(fetch)mail, procmail and mutt for a desktop user.

If you ask me why do I bother, I can only say that I am too stubborn to let it go. The original idea was to use 'mail' from the command line.

Re: getmail and SSL IMAP

1's picture

In fact, this was only a configuration issue. I was using an outdated configuration file. With corrected setup everything works out of the box.