[imp] Login (horde auth = 'imp') always returns "Login failed for some reason..."

James Nikolich jnikolic@compeuphoria.com
Thu, 1 Nov 2001 18:14:57 -0500 (EST)


OK, I switched over to file-based session storage, and confirmed that 
various "sess_*" files are being created.  I'm not familiar with PHP 
session-management, but I'll describe what I observed:

Immediately after pointing my browser at
"http://www.example.com/horde/imp", I got the login screen.  Three
"sess_*"  files were created, two of which were 0-length and the third
38-bytes long.  It's contents were:

prefs_cache|a:1:{s:7:"_filled";a:0:{}}

After attempting (and failing) to log in, I noticed that 3 more "sess_*" 
files were created, one of which was 0-length, one 38 bytes long, and one 
536 bytes long.  This last one appeared to have meaningful information in 
it, such as values for "userID", "password", "timestamp", "user", "pass", 
etc.

The log below shows the value of $GLOBALS[HTTP_SESSION_VARS]['imp'] before 
and after it is assigned &$imp.  Before, it's value is [0].  Afterwards, 
its value is [1].  However, in IMP::setupSession, it still fails the 
isset() test.

Based on what's happening here, I'm wondering whether I've screwed up some 
fundamental PHP or Apache configuration setting somewhere.  How is 
$GLOBALS[HTTP_SESSION_VARS]['imp'] set and preserved across the individual 
file-level scope?...

(BTW, sorry to be cluttering up the mailing list this way.  I DO 
appreciate the advice and help folks have been supplying...)

Jim




/var/www/html/horde/imp/lib/IMP.php   Entering IMP::createSession
/var/www/html/horde/imp/lib/IMP.php   isset($HTTP_POST_VARS['imapuser']) == [1]
/var/www/html/horde/imp/lib/IMP.php   isset($HTTP_POST_VARS['pass']) == [1]
/var/www/html/horde/imp/lib/IMP.php   isset($HTTP_POST_VARS['server']) == [1]
/var/www/html/horde/imp/lib/IMP.php   IMP::authenticate(OP_HALFOPEN) returned OK...
/var/www/html/horde/imp/lib/IMP.php   $GLOBALS['HTTP_SESSION_VARS']['imp'] == [0] before assignment
/var/www/html/horde/imp/lib/IMP.php   $GLOBALS['HTTP_SESSION_VARS']['imp'] == [1] after assignment
/var/www/html/horde/imp/lib/IMP.php   exiting IMP::createSession (returning true)
/var/www/html/horde/imp/redirect.php  $entry = [199.212.40.118 login success for jnikolic {localhost:143}]
/var/www/html/horde/imp/redirect.php  Horde::getFormData('redirect_url') returned []
/var/www/html/horde/imp/mailbox.php   Entering "imp/mailbox.php"
/var/www/html/horde/imp/mailbox.php   $actionID == [105]
/var/www/html/horde/imp/lib/IMP.php   Entering IMP::setupSession
/var/www/html/horde/imp/lib/IMP.php   isset($GLOBALS['HTTP_SESSION_VARS]['imp']) == [0]
/var/www/html/horde/imp/lib/IMP.php   is_array($GLOBALS['HTTP_SESSION_VARS]['imp']) == [0]
/var/www/html/horde/imp/lib/IMP.php   isset($GLOBALS['HTTP_SESSION_VARS]['imp']['user']) == [0]
/var/www/html/horde/imp/lib/IMP.php   Nothing seems set - THIS CAN'T BE GOOD...
/var/www/html/horde/imp/lib/IMP.php   Exiting IMP::setupSession
/var/www/html/horde/imp/mailbox.php   Failed either IMP::setupSession or IMP::authenticate




On Thu, 1 Nov 2001, David Peoples wrote:

> > As near as I can tell, the three isset() and is_array() checks in
> > IMP::setupSession() fail.  Somehow, HTTP_SESSION_VARS is not getting
> > correctly populated.  I'm not quite sure how/where it is supposed to be
> > populated.  David Peoples offered the suggestion that I switch to
> > file-based session storage, but I haven't yet strapped on my
> > belt-and-suspenders.  Is it still advisable to do so, or does the
> > diagnostic output below give anyone a clue as to what's going wrong for
> > me?
> 
> That's exactly the sequence of events I was seeing, where createSession() 
> appeared to succeed but the setupSession() call in mailbox.php failed. 
> Changing the PHP session storage fixed it for me, and I'm still convinced 
> that is what is going on for you too, even if the test.php page didn't show 
> it.
> 
> Since I had the test IMP installation set up as a "VirtualHost" in Apache, 
> it was trivial to set PHP back to file-based session storage just for this 
> section, without affecting the rest of the server. Write me back off-list if 
> you need more details about my setup. (I don't mind posting it here, but 
> just might be noise for the rest of the list readers.)
> 
> David
> 
> 



>From liamr@umich.edu Date: Thu,  1 Nov 2001 18:16:59 -0500
Return-Path: <liamr@umich.edu>
Mailing-List: contact imp-help@lists.horde.org; run by ezmlm
Delivered-To: mailing list imp@lists.horde.org
Received: (qmail 70495 invoked from network); 1 Nov 2001 23:17:02 -0000
Received: from berzerk.gpcc.itd.umich.edu (smtp@141.211.2.162)
  by clark.horde.org with SMTP; 1 Nov 2001 23:17:02 -0000
Received: from esperanto.web.itd.umich.edu (smtp@esperanto.web.itd.umich.edu [141.213.231.69])
        by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id SAA04411
        for <imp@lists.horde.org>; Thu, 1 Nov 2001 18:17:00 -0500 (EST)
Received: (from nobody@localhost)
	by esperanto.web.itd.umich.edu (8.8.8/4.9.1-cyrus) id SAA10353
	for imp@lists.horde.org; Thu, 1 Nov 2001 18:16:59 -0500 (EST)
X-Authentication-Warning: esperanto.web.itd.umich.edu: nobody set sender to liamr@umich.edu using -f
Received: from manx.web.itd.umich.edu ( [manx.web.itd.umich.edu])
	as user liamr@l.imap.itd.umich.edu by mail-test.www.umich.edu with HTTP;
	Thu,  1 Nov 2001 18:16:59 -0500
Message-ID: <1004656619.3be1d7ebc468e@mail-test.www.umich.edu>
Date: Thu,  1 Nov 2001 18:16:59 -0500
From: Liam Hoekenga <liamr@umich.edu>
To: imp@lists.horde.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Subject: FIXED:  unqualified address problem

I feel like I've been crying wolf all day about this.  I have actually fixed
this problem in my installation.

SUMMARY:  IMP correctly appends the default domain to the message headers in the
DATA portion of the email addresses, but the RCPT-TO recipients remain
unqualified if they are entered unqualified.

Here's the deal..

At some point MIME::encodeAddress is called by horde/lib/MIME/Message.php's
encode function (around line 80).  This block of code seems to generate the
message headers that appear in the DATA block of the message.

        foreach ($headers as $key => $val) {
            if ($key == 'To' || $key == 'Cc' || $key == 'Bcc' || $key == 'From')
 {
                $headers[$key] = MIME::encodeAddress($val, $charset, $this->defa
ultServer);
            } else {
                $headers[$key] = MIME::encode($val, $charset);
            }
        }
        return $headers;

This works fine.  Unqualified addresses get the maildomain pegged on their
butts, and all goes on their merry way.  Try as I might to understand, I'm not
sure how, where, when this happens in the whole mail composition process.

But... the piece of code the processes the recipients that are going to end up
in the RCPT-TO portion of the message (the information sendmail actually uses to
try and deliever the mail) doesn't contain any domain information.  

horde/imp/compose.php (the SEND_MESSAGE case, ~ line 740)
         $status = $mailer->send(MIME::encodeAddress($recipients), $headers,
$msg);

$recipients doesn't necessarily contain any domain information and if there are
recipients without domain information, MIME::encodeAddress is going to assume
localhost unless it is told otherwise.

So.... I made the following change..

         $status = $mailer->send(MIME::encodeAddress($recipients, '', $imp['mail
domain']), $headers, $msg);

and things seem to be swell.  Can one of the real developer types take a look at
this, and commit it if my logic is sound?  sorry to have been such a bother.

Liam


>From nlin@newton.berkeley.edu Date: Thu,  1 Nov 2001 15:44:12 -0800
Return-Path: <nlin@newton.berkeley.edu>
Mailing-List: contact imp-help@lists.horde.org; run by ezmlm
Delivered-To: mailing list imp@lists.horde.org
Received: (qmail 71606 invoked from network); 1 Nov 2001 23:44:14 -0000
Received: from webmail.decf.berkeley.edu (128.32.142.69)
  by clark.horde.org with SMTP; 1 Nov 2001 23:44:14 -0000
Received: (from apache@localhost)
	by webmail.decf.berkeley.edu (8.11.6/8.11.6) id fA1NiCu18547
	for imp@lists.horde.org; Thu, 1 Nov 2001 15:44:12 -0800
Received: from okepler.me.berkeley.edu ( [okepler.me.berkeley.edu])
	as user nlin@maxwell.berkeley.edu by webmail.decf.berkeley.edu with HTTP;
	Thu,  1 Nov 2001 15:44:12 -0800
Message-ID: <1004658252.3be1de4c80301@webmail.decf.berkeley.edu>
Date: Thu,  1 Nov 2001 15:44:12 -0800
From: nlin@newton.berkeley.edu
To: imp@lists.horde.org
References: <1004643165.3be1a35da255e@webmail.decf.berkeley.edu> <1004650004.3be1be14ecce2@linux.wg.de>
In-Reply-To: <1004650004.3be1be14ecce2@linux.wg.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
X-Originating-IP: 128.32.142.3
Subject: Re: [imp] monthly renameing shows duplicate folders.


Oh! is that why?  yes.  I do have three identities.

Quoting Jan Schneider <jan@horde.org>:

> Zitat von nlin@newton.berkeley.edu:
> 
> > 
> > Hi
> > 
> > I have the latest imp cvs.
> > 
> > I have my prefs set up to rename my sent folder monthly.  Today, when
> I
> > log 
> > in, the maintenance page says:
> > 
> > The current folder(s) "sent, sent, sent" will be renamed to
> > "sent-oct-2001, 
> > sent-oct-2001, sent-oct-2001". 
> > 
> > Is it buggy because I use the sent folder instead of sent-mail?
> 
> No, it seems to be a bug. I assume you have at least three identities
> that 
> all use the same sent-mail folder?
> 
> Jan.
> 
> :::::::::::::::::::::::::::::::::::::::: 
> AMMMa AG - discover your knowledge
> :::::::::::::::::::::::::::
> Detmolder Str. 25-33 :: D-33604 Bielefeld
> fon +49.521.96878-0 :: fax  +49.521.96878-20
> http://www.ammma.de
> ::::::::::::::::::::::::::::::::::::::::::::::
> 
> -- 
> IMP mailing list: http://horde.org/imp/
> Archive: http://marc.theaimsgroup.com/?l=imp&r=1&w=2
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: imp-unsubscribe@lists.horde.org
>