At 1:32 PM +0200 2/3/03, Spiros Ioannou wrote:
Yes, I read the code and you are correct, temp file remains and the spool is re-truncated if user quota is exceeded
The important issue is that the spool is not corrupted.
, but:
1. If the user checks mail with another protocol his mail is invisible because
it resides at the temp (we also have webmail through imap).
Very true.
2. When new mail arrives, it is appended to the truncated spool, while user
mail resides at the temp because of the "overquota copying temp to spool"
error of the previous session. When the user tries to check mail again,
the same error applies and his new spool mail is appended to the previous
temp, so all new mail is accumulated in the temp file rendering all
quota mechanism useless.
Imagine now deleting by hand (and by user request) the large mail from
a system with thousands of users.
Yes, this can be a problem.
This should not occur. Each message should have the same unique ID (UID), so the client should only download each message once. If this is not the case, please let me know the details.
3. When the user starts his mail client and his spool was left at the
temp file due to the above overquota problem, his client re-gets all the
mail in the temp file along with the new in the spool. But the mail in
the temp file was already downloaded to the client and old mail appears
now duplicate and new mail once normal. The next time he checks, mail is
duplicated again , old-old messages exist now 3 times, old 2 times and new
just appended from spool 1 time. And so on. We assume he has "leave messages
on server"
This isn't universally true. An option to hold the lock may make sense for some circumstances (for example, if Qpopper and IMAP are both in use), but this should not be default behavior.
4. As for mail.local returning the mail in case of a locked spool this is
wrong, the mail should stay in the queue. If some systems have
problem with this then they should get a better sendmail/mail.local or avoid
using quotas, because the spool gets locked one way or another-and for a long
time, especially when mailboxes are large (>100MB) and disk activity is high,
so these systems will loose mail anyway.
There have been a lot of discussions on quotas and spool sizes in the past, including recommendations on how to do what you want, from sites that run that way. You may find this helpful. A Google search of the archives of this list may be useful.For the above reasons I hold to my previous assumption that the locking logic is erroneous. At least it creates a lot of problems for us, and an option for an alternative locking logic would be much appreciated since tampering with the source is time-consuming. I await your replys/advices
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
If you think dogs can't count, try putting three dog biscuits in
your pocket then giving Fido only two of them. --Phil Pastoret
