Bug#389115: squirrelmail: Cannot login: reports cross-realm login [EMAIL PROTECTED] denied
Thijs Kinkhorst wrote: On Sun, 2006-09-24 at 13:48 -0400, Jeffrey B. Green wrote: The question is where is the screw up? Like I said, IMAP mail retrievals work just fine. The only other possibility that I can think of is Perdition, however Perdition is mainly just routing, though it does do the regular expression matching to identify which server to send to. Well, a first thing would be to configure SquirrelMail to access the IMAP server directly and not through perdition. This part seems to be the issue. Apparently Perdition does not grab the squirrelmail to imap traffic since when I set the squirrelmail port directly to what perdition is talking with, then all works well now within our local network. (May be a touchy point with regards to IP referrencing, i.e. perdition was only looking at traffic through an IP associated with outside traffic. The regular expression config file for perdition only specifies the mail domain name + port. I'm now assuming that the mail domain name gets tied to the dns, or assigned, IP for it.) I still need to test it outside the local net, i.e. from global IP space, but I assume it'll work okay. I should be able to let you know within a couple of days (it's the weekends mode versus the weekdays mode syndrome). So, the next question is where should there be a warning or at least more information available. I know that I was stymied a bit by my inability to see what was going on component to component. (I was also a bit pressed for time.) I'll look deeper into perition to see if it's logging capabilities do indeed provide a way to track down the traffic routing that it is doing. Thanks for your help and again I'll let you know in a couple of days whether this has fixed the issue also for a (global) internet user. You should be able to close it then (for sure). -jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389115: squirrelmail: Cannot login: reports cross-realm login [EMAIL PROTECTED] denied
Jeff Green wrote: Thijs Kinkhorst wrote: On Sun, 2006-09-24 at 13:48 -0400, Jeffrey B. Green wrote: The question is where is the screw up? Like I said, IMAP mail retrievals work just fine. The only other possibility that I can think of is Perdition, however Perdition is mainly just routing, though it does do the regular expression matching to identify which server to send to. Well, a first thing would be to configure SquirrelMail to access the IMAP server directly and not through perdition. [...snip...] I still need to test it outside the local net, i.e. from global IP space, but I assume it'll work okay. I should be able to let you know within a couple of days (it's the weekends mode versus the weekdays mode syndrome). I was able to get access. It works just fine. Also perdition does have a debug switch that probably would have given me copious information regarding the imap traffic if I'd invoked it. Go ahead and close it if you'd like. Thanks again. -jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389115: squirrelmail: Cannot login: reports cross-realm login [EMAIL PROTECTED] denied
Hello Jeff, The setup is with a Cyrus(IMAP), Postfix, and LDAP. Cyrus works just fine, clients can retrieve mail with no problems.. Squirrelmail did work fine at an earlier time. Obviously it is not used much since I'm not able to pinpoint when it broke. I have a similar setup on another machine (running Etch) serving another domain, squirrelmail works fine there.. Perdition is running on the machine that has the broken squirrelmail (believe though that I did check it after installing perdition several months ago though it might have been the time it broke...can't remember). I tried tracking it down by increasing the log levels at various points, but the only info that it seems to report is the cross-realm denied thing. The squirrelmail src/configtest.php reports no problems. Thanks for your report. However, I strongly doubt this to be a problem with SquirrelMail. The message: Cannot login: reports cross-realm login [EMAIL PROTECTED] denied is passed straight from your IMAP server; SquirrelMail does not do any authentication by itself. Checking out the logs of your IMAP server, or of the authentication backend it uses might yield more clues. I leave it up to you to reassign this report to any other package if you discover the problem to be there. Otherwise, I'll close it soon. Thijs signature.asc Description: This is a digitally signed message part
Bug#389115: squirrelmail: Cannot login: reports cross-realm login [EMAIL PROTECTED] denied
Hi Thijs, The question is where is the screw up? Like I said, IMAP mail retrievals work just fine. The only other possibility that I can think of is Perdition, however Perdition is mainly just routing, though it does do the regular expression matching to identify which server to send to. S, is there a debug setting for Squirrelmail to see exactly what is being sent to the IMAP processing? And at the least, if there is a touchy situation with virtual mailboxes and Squirrelmail, a heads up in the install process would be good. However, it stills needs to be determined what is happening. -jeff Thijs Kinkhorst wrote: Hello Jeff, The setup is with a Cyrus(IMAP), Postfix, and LDAP. Cyrus works just fine, clients can retrieve mail with no problems.. Squirrelmail did work fine at an earlier time. Obviously it is not used much since I'm not able to pinpoint when it broke. I have a similar setup on another machine (running Etch) serving another domain, squirrelmail works fine there.. Perdition is running on the machine that has the broken squirrelmail (believe though that I did check it after installing perdition several months ago though it might have been the time it broke...can't remember). I tried tracking it down by increasing the log levels at various points, but the only info that it seems to report is the cross-realm denied thing. The squirrelmail src/configtest.php reports no problems. Thanks for your report. However, I strongly doubt this to be a problem with SquirrelMail. The message: Cannot login: reports cross-realm login [EMAIL PROTECTED] denied is passed straight from your IMAP server; SquirrelMail does not do any authentication by itself. Checking out the logs of your IMAP server, or of the authentication backend it uses might yield more clues. I leave it up to you to reassign this report to any other package if you discover the problem to be there. Otherwise, I'll close it soon. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389115: squirrelmail: Cannot login: reports cross-realm login [EMAIL PROTECTED] denied
On Sun, 2006-09-24 at 13:48 -0400, Jeffrey B. Green wrote: The question is where is the screw up? Like I said, IMAP mail retrievals work just fine. The only other possibility that I can think of is Perdition, however Perdition is mainly just routing, though it does do the regular expression matching to identify which server to send to. Well, a first thing would be to configure SquirrelMail to access the IMAP server directly and not through perdition. Are you using any SquirrelMail plugins? If so, you might try to disable them all and see if that helps. Are you perhaps using the vlogin plugin? You can check the SquirrelMail authentication settings (like SSL/TLS) and whether you've set the IMAP Server Type correctly. Are you sure that you're using exactly the same login credentials as your other IMAP client uses? If it used to work and now doesn't anymore, something must have changed. What did you change? S, is there a debug setting for Squirrelmail to see exactly what is being sent to the IMAP processing? SquirrelMail is designed to be good at its own function and leave for other programs what they do best. Hence, the logging of IMAP calls is left to the IMAP server: you'd best check the log of Cyrus for the exact commands executed. However, it stills needs to be determined what is happening. As you can see - without access to your system it's mostly guessing for me. Thijs signature.asc Description: This is a digitally signed message part
Bug#389115: squirrelmail: Cannot login: reports cross-realm login [EMAIL PROTECTED] denied
note: I'm not at the affected machine at present (...have limited time these days for administration...in general, it is a very stable machine and so can typically live without me). Some key points: - affected machine is running under sarge while unaffected is etch. - the only new thing that I can think of that changed is the addition of perdition, however the only thing that I can think of then that would be a factor is the /etc/saslauthd.conf file for verifying passwords on the LDAP server. It may be that the combo of perdition and saslauthd.conf may work for IMAP mail lookups but not for Squirrelmail. It's a bit unclear to me that perdition does get involved in the squirrelmail/imap interactions; possibly, if perdition grabs *all* traffic on the imap port, which is what I assume Squirrelmail is using. Let's see if perdition can be cut out of the picture as you suggest. (However, I also believe perdition may do some address rewriting, but I'm not sure offhand. Something to check.) - however, to the last point above, I did try entering the account name in various forms but still no luck, i.e. as jeff and [EMAIL PROTECTED] and [EMAIL PROTECTED] - I did a diff for all of the config file pairs that I could think of between the two systems and nothing seemed to show. When there were differences that I thought could possibly cause the problem I made the affected system consistent with the unaffected but the problem still remained. - I do employ TLS in the mail setup. So, the consistency between the two components needs to be checked. Also need to compare the Squirrelmail settings between the two systems though I think the diff mentioned may have hit that already. - Don't believe that I'm using any Squirrelmail plugins, but I'll check. (Memory tells me I did a vanilla install of Squirrelmail, then configured the apache file.) I'll check all of your suggestions when I get to the machine(s), and thank you for helping out. In particular, I'll start cutting out separable components to simplify. -jeff Thijs Kinkhorst wrote: On Sun, 2006-09-24 at 13:48 -0400, Jeffrey B. Green wrote: The question is where is the screw up? Like I said, IMAP mail retrievals work just fine. The only other possibility that I can think of is Perdition, however Perdition is mainly just routing, though it does do the regular expression matching to identify which server to send to. Well, a first thing would be to configure SquirrelMail to access the IMAP server directly and not through perdition. Are you using any SquirrelMail plugins? If so, you might try to disable them all and see if that helps. Are you perhaps using the vlogin plugin? You can check the SquirrelMail authentication settings (like SSL/TLS) and whether you've set the IMAP Server Type correctly. Are you sure that you're using exactly the same login credentials as your other IMAP client uses? If it used to work and now doesn't anymore, something must have changed. What did you change? S, is there a debug setting for Squirrelmail to see exactly what is being sent to the IMAP processing? SquirrelMail is designed to be good at its own function and leave for other programs what they do best. Hence, the logging of IMAP calls is left to the IMAP server: you'd best check the log of Cyrus for the exact commands executed. However, it stills needs to be determined what is happening. As you can see - without access to your system it's mostly guessing for me. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389115: squirrelmail: Cannot login: reports cross-realm login [EMAIL PROTECTED] denied
Package: squirrelmail Version: 2:1.4.4-9 Severity: important The setup is with a Cyrus(IMAP), Postfix, and LDAP. Cyrus works just fine, clients can retrieve mail with no problems.. Squirrelmail did work fine at an earlier time. Obviously it is not used much since I'm not able to pinpoint when it broke. I have a similar setup on another machine (running Etch) serving another domain, squirrelmail works fine there.. Perdition is running on the machine that has the broken squirrelmail (believe though that I did check it after installing perdition several months ago though it might have been the time it broke...can't remember). I tried tracking it down by increasing the log levels at various points, but the only info that it seems to report is the cross-realm denied thing. The squirrelmail src/configtest.php reports no problems. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-386 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages squirrelmail depends on: ii apache2 2.0.54-5sarge1 next generation, scalable, extenda ii apache2-mpm-prefork [ht 2.0.54-5sarge1 traditional model for Apache2 ii libapache2-mod-php4 4:4.3.10-16 server-side, HTML-embedded scripti ii perl5.8.4-8sarge5Larry Wall's Practical Extraction ii php44:4.3.10-16 server-side, HTML-embedded scripti ii squirrelmail-locales1.4.4-20050308-1 Translations for the SquirrelMail -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
