Cable, Stamp, Lock offlineimap allows you to keep a local copy of your emails, and synchronize it with the IMAP folders on the server. Not only handy for offline use, but also for dealing with slow mail servers and unreliable network connections.

Unfortunately, offlineimap exits with an error from time to time and needs to be restarted. The restarts are easily done with a script, but each time you restart it, offlineimap requires the IMAP server's password. offlineimap allows you to store the unencrypted password in a file, but that should not be an option if you care about security.

On Fedora 9, there's a better way to hand the password to offlineimap: gnome-keyring


First, install the Python bindings for gnome-keyring:

yum install gnome-python2-gnomekeyring

Download the file ~/.offlineimap.py and add the following settings in ~/.offlineimaprc. This assumes that you use a local IMAP server.

[general]

pythonfile = ~/.offlineimap.py

[Repository localhost]

type = IMAP
remotehost = localhost
remoteusereval = get_username("localhost")
remotepasseval = get_password("localhost")

[Repository Zimbra]

type = IMAP
remotehost = mail.example.com
remoteusereval = get_username("mail.example.com")
remotepasseval = get_password("mail.example.com")

Download the script imap-passwords and run it to add the IMAP usernames and passwords to your keyring. It will prompt you for server, username and password - use the same host names as in .offlineimaprc.

Now you can run offlineimap in a loop to automatically restart it in the case of some unrecoverable error, like so:

#!/bin/bash

while true; do
  /usr/bin/offlineimap
  echo Restarting in 60 seconds ...
  sleep 60
done

During the first run, gnome-keyring will ask you to authorize offlineimap to access your IMAP authentication data in the default keyring.

Thanks to Sebastian Rittau for the Keyring Python module.

22:17, 22 Sep 2008 by Carsten Clasohm Permalink | Comments (1)

Why External Forwarding with Sendmail's virtusertable is A Bad Idea

If you run a mail server with sendmail, and a user wants to forward his mail to another server, one way is /etc/mail/virtusertable:

joe@example.com         joe@gmail.com

As you probably know, the sender address of most spam mails belongs to someone - not the spammer of course. If you refuse to accept a spam email, you must never send back an error email to the alleged sender address. Otherwise, you have become a source of unsolicited email yourself.

When in our example, gmail.com does not accept an email, your server will send an error mail to the alleged sender address.

If you watch your postmaster mailbox, you will notice this every time the alleged sender address is invalid. You might be tempted to suppress these postmaster notifications with

define(`confDOUBLE_BOUNCE_ADDRESS', `')dnl

But this only supresses the double bounces. If the sender address is valid, someone will get an error email about spam he didn't send.

The solution is to not use virtusertable for external forwarding, but instead do it in /home/joe/.procmailrc:

:0
* ^From: Mail Delivery Subsystem <MAILER-DAEMON@example.com>
* ^To: <joe@example.com>
bounced-mails

:0
! joe@gmail.com 

In this case, the sender address is set to joe@example.com before the mail is forwarded to gmail.com, and any error messages go back to joe.

21:28, 04 Jul 2008 by Carsten Clasohm Permalink | Comments (0)

RSS

Archive

January 2008
S M T W T F S
   
10  11  12 
13  14  15  16  17  18  19 
20  21  22  23  24  25  26 
27  28  29  30  31     
September 2008
July 2008
June 2007
May 2007
March 2007
January 2007
December 2006
September 2006
June 2006
April 2006
March 2006
February 2006
January 2006
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
January 2005
December 2004
November 2004
October 2004

Blog Categories

Hiking (5)
Desktop Linux (28)
Server Linux (5)
Palm (3)
Photography (5)
Politics (2)
Web Applications (15)

Notifications

Request notifications

Syndication Feed

RSS

Recent Comments

  1. Anonymous Visitor: Thanks
  2. Anonymous Visitor: AT&T U.S.
  3. Anonymous Visitor: All went well under CentOS 5.0 in Croatia (VIP network)
  4. Anonymous Visitor: tmp crypt not necessary
  5. Anonymous Visitor: Great article
  6. Anonymous Visitor: So it's not a Virus...
  7. Anonymous Visitor: Thanks! Helps also on Windows!
  8. Anonymous Visitor: Thank you
  9. Anonymous Visitor: Economic Incentives
  10. Anonymous Visitor: thank you