Truthfully, I can't see anything obvious on this. So here are some
general ideas of what might have led to this situation that I didn't
hear mentioned in your email:
1. Is this squirelmail something you installed or a standard package
on the system (by the way, what kind of system is this? *BSD/Linux,
what distro of Linux?).
2. I've seen things similar to this when the auto update of the
system installed a security patch/update which broke a config file
somehow (though rare). Go back and double check your imapd server
config (which I assume squiremail is connecting to) and your entire
squirelmail config file. Make sure that they are listening and
connecting to the same host (127.0.0.1 I assume). Make sure they are
going for the same ports. Make sure of every config option.
3. Are you getting even the login screen for squirrel mail?
4. Have you double checked to make sure your filesystem hasn't been
corrupted? Maybe there was a hd failure or partial failure which as
screwed some inodes/sectors on your HD. Make sure you aren't
trashing your disk further.
That's about all I can say.
-David
On Feb 17, 2007, at 10:07 AM, Brian McCullough wrote:
Apparently I didn't give enough detail. I suppose I didn't want to
bore
those who are not interested, but I guess that was a mistake on my
part.
Here is a little more detail in case jonc has any more to offer......
Jan 13. Get a call from my son that squirrel ail is not working
properly. Checked the symptoms. The whole page is not coming up.
refreshing the page seems to bring up all the pieces but this is a
change in behaviour from Jan 11 which was the last time he checked
his mail.
Shut down BOINC as it is chewing up alot of processor time and may be
slowing down the system causing the page not to complete properly. No
change.
Checked the logs on the system hosting squirrel mail. Nothing of note
in the apache logs that look unusual when comparing the 10th to the
13th although one or two systems have been requesting files that don't
exist on my system. Made a note for later.
Check the maillog logs on the mail server. On the 11th each
session of
squirrel mail when connecting would stay connected till the user
logged
off. Noted the text for the logon method changed from "plain" to
PLAIN"
Most interesting since I did not make any changes to the system.
Obviously something has changed. Checked the config file to find the
logon method. it is entered as PLAIN. I have made no changes to
this.
On the 13th, starting at the session would disconnect generally within
the same second that the logon happened. No changes were made over
the
weekend. Matter of fact the system has not been changed since mid
december when I installed v 1.4.8. The only other change that happens
is the system builds a new set of root hints for the DNS server
automatically. This has been going on for years and never created an
issue, so chances are good it will not cause it now.
ran root kit checks and looked for files in /bin /sbin /usr/bin
/usr/sbin usr/local/bin and /usr/local/sbin with recent dates. found
none. ran rootkit found nothing. rkhunter runs nightly and found
nothing either over the weekend.
Connections from thunderbird stay logged on till the session is closed
or times out. It is not seeing the same issue as squirrel mail
seems to be.
Cannot determine if it is dovecot or squirrel mail but it is looking
like it is squirrel mail related. So I installed the latest squirrel
mail with a standard install. the issue is still happening. the logon
method is still PLAIN.
Updated dovecot. didn't need to but I figured why not. something is
broken and the install of squirrel mail did not fix it. if Dovecot is
compromised then this should resolve it. No change.
Not squirrel mail nor dovecott. Looked at PHP next ran tests on
the php
install on the squirrel mail server with other php based software I
have
setup on the server. they all work fine. It is not looking like PHP.
did a bit more checking on the files that were being requested from
the
internet to see if the system may have been compromised. none of the
requested files existed on my system so I don't think there was
anything
exploited in this fashion. No strange requests in the ssl loggs or the
non ssl logs that would indicate a web based exploit. Logs appear
intact with no gapping holes. confidence is good that the system is
still intact.
check the physical connection between the squirrel server and the hub.
Looks good. I am fairly confident that it is not apache, php, or
squirrel mail. Also confident it is not dovecot as it works as
expected
with thunderbird. Hairpulling begins. I need to step back and get
advice on where to look. Fresh eyes so to speak.
Checked with Brian to see if he has ever heard of this issue as it has
me stumped and I could use some advice where to look for problems. He
hasn't either so he submitted my note to the TriLUG mailing list to
see
if anyone had any useful suggestions.
Please let me know if anyone has any ideas of what I should be
looking at.
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/
trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
