· Home
· Products
· Services
· On-Line Sales
· News
· Training
· Tech Support
 · Reference Library
· Software Library
· Company Info
· Employment
· Contact Us
· Site Map
· Email Us
Search Search
Valid HTML 4.01!
.
Information Technologies
Empowering Business Through Technologies
How to replace Fetchmail with Getmail
or
How to use Getmail with Sendmail.

For a long time I have been using Fetchmail to pull mail down from other POP3 servers onto my server. I also use the excellent program MailScanner which performs virus scanning and spam scanning. I love the whole thing. Except for Fetchmail.

In my opinion, Fetchmail is problematic. For basic stuff it is fairly easily to configure, and there is a Webmin module for it. But when it comes to working with certificates, it is a pain to configure and make work error free. It occasionally chokes on downloading messages for no apparent reason. These messages have to be deleted manually from the remote server to allow things to start flowing again. An attempt to upgrade to the latest release on my Fedora Core 3 box failed due to unresolvable dependencies. It just has the general feel of being a pain.

Fetchmail had to be replaced. Surfed around freshmeat.net and found Getmail. From the description it sounded perfect. Downloaded the latest release (sorry no RPM available for the current releases), and installed it. Read some of the documents and managed created an rc file:
	[options]
	# Turn off verbose when running as a CRON job
	verbose = true
	read_all = true
	delete = true
	message_log = /var/log/getmail.log

	[retriever]
	type = SimplePOP3Retriever
	server = yourpop3server.com
	username = remoteusername
	password = password
	
	[destination]
	type = Mboxrd
	path = /var/mail/username
	user = localusername
This successfully pulled down new mail and dropped it into the users mail folder. But there was a problem.

MailScanner was not processing any of this mail. No virus scanning, no spam scanning. The incoming email was being delivered to the proper users mailbox, and that mail could be access fine. But MailScanner was not being run.

Reading the docs again it became apparent a different destination type was in order. It was changed to MDA_external in hopes of getting sendmail to accept messages which would allow MailScanner to process them:
	[destination]
	type = MDA_external
	path = /usr/sbin/sendmail
	allow_root_commands = 1
Now new messages were being downloaded but not delivered to the mailbox. With the getmail option verbose = 1 set, getmail generated the following console error messages:
	SimplePOP3SSLRetriever:username@yourpop3server.com:995:
	Delivery error (command sendmail 2828 error (64, ))
	 msg 1/1 (3961 bytes), delivery error (command sendmail 2828 error (64, ))
	  1 messages retrieved, 0 skipped
The 2828 is the PID (it keeps changing) and the sendmail error code is 64. Searching the web for sendmail exit codes or error codes turned up nothing. The answers were on my server. The file which lists the sendmail error codes (at least on my Fedora Core 3 box) is /usr/include/sysexits.h

	#define EX_OK		0	/* successful termination */
	#define EX__BASE	64	/* base value for error messages */

	#define EX_USAGE	64	/* command line usage error */
	#define EX_DATAERR	65	/* data format error */
	#define EX_NOINPUT	66	/* cannot open input */
	#define EX_NOUSER	67	/* addressee unknown */
	#define EX_NOHOST	68	/* host name unknown */
	#define EX_UNAVAILABLE	69	/* service unavailable */
	#define EX_SOFTWARE	70	/* internal software error */
	#define EX_OSERR	71	/* system error (e.g., can't fork) */
	#define EX_OSFILE	72	/* critical OS file missing */
	#define EX_CANTCREAT	73	/* can't create (user) output file */
	#define EX_IOERR	74	/* input/output error */
	#define EX_TEMPFAIL	75	/* temp failure; user is invited to retry */
	#define EX_PROTOCOL	76	/* remote error in protocol */
	#define EX_NOPERM	77	/* permission denied */
	#define EX_CONFIG	78	/* configuration error */

	#define EX__MAX	78	/* maximum listed value */
Back to the web. Stumbled across a site which got me headed in the right direction.
	[destination]
	type = MDA_external
	path = /usr/sbin/sendmail
	arguments = ("-t","username@localhost")
	allow_root_commands = 1
This worked somewhat. Messages were being downloaded, processed by MailScanner and delivered to the proper users mailbox. Great! But there were still problems. After letting getmail run for a while it was found this destination configuration would totally yack on messages addressed to "undisclosed recipients" and once again start generating console error messages:
	Delivery error (command sendmail 12729 error (64, ))

or

	Delivery error (command sendmail 13089 error (67, ))
This caused getmail to act a little bizarre as well. It would deliver the message to sendmail which was then processed by MailScanner, but the error caused getmail to think it had not delivered me message successfully, so it would go and download and deliver the same message next CRON job. This made everybodys mailbox fill up with spam (messages addressed to "undisclosed recipients" are typically spam).

Surfing the web for answers once again, there are all kinds of "arguments = " statements out there, and none of them seemed to work. What I was not understanding was the "arguments = " section passes on command line switches to the "path = /usr/sbin/sendmail" statement. Once that was known, doing a man sendmail revealed what the "-t" switch was for:
	 -t     Read  message  for  recipients.
		To:, Cc:, and Bcc: lines will be scanned for recipient addresses.
		The Bcc: line will be deleted before transmission.
The "-t" switch was really not needed, and was causing the errors for undisclosed recipients. But simply removing the "-t" option caused getmail to complain:
	Configuration error: configuration file /root/.getmail/username incorrect
	(arguments: incorrect format (not a tuple))
The answer was to have a blank statement to satisfy the tuple rule:
	[destination]
	type = MDA_external
	path = /usr/sbin/sendmail
	arguments = (" ","username@localhost")
	allow_root_commands = 1
This allowed sendmail to understand who the message recipient was, and getmail would not generate any errors. This works. Since MailScanner sits behind sendmail, new messages are properly processed for virus and spam.
The next problem was getmail and my version of PYTHON. When getmail was invoked PYTHON it would generate the following error:
	/usr/lib/python2.3/optparse.py:668: 
	FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up
	return ("<%s at 0x%x: %r>"
Looking at the getmail FAQsaid this was a PYTHON problem, not a getmail problem. Great. Surf the web and there appears to be one thread out there that 60 people have changed the format of. Most of it says use the -W switch for PYTHON. The docs are no help at all for this, and after stumbling around trying different things, I just gave up on PYTHON -W ...

I installed the PYTHON 2.4 RPM and getmail complained about a logging file. There appears to be no way to upgrade python unless you do a distro upgrade. Great.

My answer was to modify the optparse.py file. On my system this file is located at:
	/usr/lib/python2.3/optparse.py
From the error message you can see the line of code causing the problem is 668:
	     def __repr__ (self):
	         return ("<%s at 0x%x: %r>"
	                 % (self.__class__.__name__, id(self), self.__dict__))
So I just commented out lines 668-670:
	#    def __repr__ (self):
	#        return ("<%s at 0x%x: %r>"
	#                % (self.__class__.__name__, id(self), self.__dict__))
and no more errors. It may not be an eloquent solution, but it has the virtue of working. Now CRON jobs don't complain.
I am willing to bet I am not the only one who has run into this problem. The Getmail docs are good, but at least for me this was a problem that was not easily resolved. Looking at their support area shed no light on this problem either. That's why I posted my grand adventure here. If you have found this info helpful please drop me an email.

scott@info-techs.com

Printer Friendly Version
Printer Friendly Version



Page last modified on: Wednesday June 14, 2006 at 12:10