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]
