I'm copying over some content from MailInContribDev per the suggestion of Peter Thoeny.

There's an issue with MailInContrib under Ubuntu that many people, myself included, have run into. This is preventing our using MailInContrib (and this is a big issue for my boss, who is tempted by Sharepoint which, as a Linux user, is anathema to me). The problem arises in these lines captured from the Perl debugger:

TWiki::Func::getWorkArea(/usr/share/perl5/TWiki/Func.pm:1950):
1950:       return $TWiki::Plugins::SESSION->{store}->getWorkArea( $plugin );

When this line is reached, $TWiki::Plugins::SESSION->{store} is undefined, so the script dies.

I hope to have an opportunity to examine the code enough myself this week that perhaps I can fix it, but I'm not a TWiki developer and it appears to be a pretty complex bit of macrame.

-- DavidHoughton - 03 Dec 2007

Macrame? How dare you, sir! That is finest Belgian lace, I'll have you know! Delicate, and full of holes

Upgrading to Urgent.

I need to know where the call to getWorkArea is coming from. There should be a stack trace in your apache error log.

CC

I'd like to oblige, but all I see in /var/log/apache2/error.log is

Can't call method "getWorkArea" on an undefined value at /usr/share/perl5/TWiki/Func.pm line 1950.

I'll attach the transcript of a debugging session. It appears that my description above is wrong. It isn't $TWiki::Plugins::SESSION->{store} that is undefined by $TWiki::Plugins::SESSION itself. I've been grepping around trying to figure out how $TWiki::Plugins::SESSION is initialized and it appears only ever to receive a value locally. It looks like it only has a value during the handling of some TWiki event. Since the mailincron process occurs outside of any such event... I'm not sure what the TWiki-approved solution to this problem would be. Could this be a problem which only arose after the most recent release?

Well, I'm going to attempt a local hack that side-steps the TWiki::Func safeguards.

-- DavidHoughton - 04 Dec 2007

• debugging.txt: recreating undefined session problem in debugger

Well, my hack moved the ball a bit. Here's what I did (I'm using SVK to help roll back hacks like this):

root@twiki:/usr/lib/cgi-bin/twiki# svk diff /usr/lib/cgi-bin/tools/mailincron
=== /usr/lib/cgi-bin/tools/mailincron
==================================================================
--- /usr/lib/cgi-bin/tools/mailincron   (revision 69)
+++ /usr/lib/cgi-bin/tools/mailincron   (local)
@@ -50,6 +50,7 @@
     eval "use LocalSite.cfg";
 } else {
     $twiki = new TWiki();
+    $TWiki::Plugins::SESSION = $twiki;
 }
 $folders = $TWiki::cfg{MailInContrib};
 my $processor = new TWiki::Contrib::MailInContrib($twiki, $debug);

After this I got past the sticking point and hit a new error: I was lacking Email::Folder::POP3. I installed this. Again things were moving forward for a bit, but after I traversed a bit more of the rabbit hole I hit this:

IO::Socket::INET::configure(/usr/local/lib/perl/5.8.8/IO/Socket/INET.pm:174):
174:            return _error($sock, $EINVAL, "Bad hostname '",$arg->{PeerAddr},"'")
175:                unless @raddr;

  DB<45> p scalar @raddr
0

I gather from this that all I'm missing at this point is enough POP3 savvy to configure my mailbox correctly. For the sake of completeness, here's the relevant botched configuration with the private bits fuzzed out:

$TWiki::cfg{MailInContrib} = [
 {
   folder => 'pop://*****:*****@streamsage.com/Inbox',
   onError => 'log',
   onNoTopic => 'error',
   onSuccess => 'log delete',
   topicPath => 'to subject',
 },
];

-- DavidHoughton - 04 Dec 2007

Okay, this is the last I'll say about this. I changed the server name from streamsage.com to mail.streamsage.com and now it works!

-- DavidHoughton - 04 Dec 2007

Excellent. I merged your proposed fix under Item5095. The Email::Folder module is really not terribly good; I have also found that you have to fiddle with the server name and folder name to get it to work

CC