[Cscmail-devel] Contributions

[Ben B. <be...@oc...>]

CountZero,

I have made a few changes (kludges?) to my version of cscmail 1.6.1 to
fix a few issues listed below.	I was wondering if my changes would be
appreciated, and if so what would be the most ideal way (read easy on
maintainers to incorporate) for me to submit them?  I'm willing to learn
how to convert my code to your standards/format.

issues:

1. New mail sound is played before duplicate check occurs.
Visible symptoms:
-New mail sound is played previous to any duplicate checking any time a
pop3 account is checked that has any mail.
	for conditions and solution see issue 3 below.

2. New mail sound is played once for each account that has new mail.
	for conditions and solution see issue 3 below.

3. CSCget cannot finish checking mail when sound device is busy.

Visible symptoms:
-status dialog freezes when checking for new mail.
OR
-error dialog pops up saying "cscget already running" seemingly out of
nowhere.

Conditions:
	-cscmail is configured to check multiple email accounts.
	-The option to play a sound when new mail is recieved is enabled
to use a command that doesn't share resources gracefully.

Process:
The three issues above are all related to the fact that cscget attempts
to run the user defined PlaySound command once for each account being
checked immediately upon finding ANY mail in the account (lines: 173,
274).  If the device needed by the PlaySound command is busy cscget just
waits for it, and can't finish fetching mail.  I fixed this by adding a
master counter of new messages that only gets incremented each time a
message passes the duplicate checking done on the TOP of the message. 
This counter get's checked just before cscget exits and the sound command
is attempted only once.  At this point cscget still freezes if the sound
device is busy, so I am passing "&" as the last argument to the &system
call that issues the sound command.  this releases cscget from the sound
command which poses a serious memory leak as these commands will just
pile up until they all either time out if they're smart, or until the
sound device is free at which point they all go off in succession...  But
I'm working on that : )
(you may still hear the new mail sound at strange times unless you fix
the following issue.)

4. Large emails always saved under default account.

Visible symptoms:
-When replying to a large email the account used to send the email will
always be the default account, or account with id 1.
	Occurs when you:
	-Reply to the large email saved under the wrong account id.
	And cscmail is configured:
	-You have more than one account set up.

-New mail sound is played but no new mail is downloaded.
	Occurs when you:
	-check for new mail on an account from which a large email has
been previously downloaded and NOT deleted.
	And cscmail is configured:
	-Check for dupes is ON and delete files from server is OFF for
the account being checked.
	-Check dupes accross all accounts  is OFF under main options.
	-The pop3 server supports TOP file header checking.
(this is how I noticed this problem and it was only noticable when you
have applied my solution to the previous sound issues.	Otherwise you
ALWAYS hear the new mail sound when checking a pop3 under these
conditions with mail of ANY size still on the server.)

Process:
When downloading large files from a POP3 server cscget saves the email to
a mbox and enters &import_from_mbox (line 375) to retrieve it.	This is
done without passing the $account hashref.  &import_from_mbox then
initializes a new $account hashref based on the default account (lines
546-551).  This may not be the account that was originally checked.  This
$account hashref is then passed to &read_from_mbox (line 558) where it is
passed to &save_message (line 490).  The result is a message saved in the
database with an erroneous account id.	Interestingly this message does
not get saved again even though the dupe check done on the TOP of the
message says it isn't a duplicate (remember we're only looking for
duplicates in the same account).  This is because when it is downloaded
again cscmail attempts to save it in the same wrong account but checks to
see if it is a duplicate first. (csclib.pl line 358)

Solution:
I passed the $account hashref into &import_from_mbox in cscget line 375. 
This resulted in another argument being added to &import_from_mbox.  I
added some housekeeping lines to make it default to its previous
behaviour if this argument isn't passed.  I haven't noticed any ill
effects of this so far.


I apologize if any of these issues have been addressed in the 1.7.9
release.  I couldn't find a list of the known issues.  Or who's working
on what.

Thanks,

-Ben