The report is correct. The c-client library makes no attempt to use the
64bit system calls; and thus flat files are limited to 2GB.
The recommended solution for mailboxes with aggregate size greater than
2GB is to use mix format instead of a flat file format. Even if c-client
were updated
On Tue, 29 Apr 2008, Asheesh Laroia wrote:
Thanks for the confirmation.
You're welcome.
The recommended solution for mailboxes with aggregate size greater than 2GB
is to use mix format instead of a flat file format. Even if c-client were
updated to use the 64bit system calls, flat files
On Tue, 29 Apr 2008, Asheesh Laroia wrote:
But what if the spool is already 2GB?
Yes, in that case, you have to do some external recovery to break the file
into smaller chunks. The split program is useful for this purpose.
By the way, I recommend that mixcvt be used instead of mailutil or
I apologize for not responding earlier; I was on vacation until Tuesday.
The answer to your question is:
If I understand your question correctly, the answer is yes. It is OK for
mailbox files in /var/mail to be protected 0600 without any specific group
setting. In fact, this is the normal
I won't be able to give a thorough review/response to your message until
next week. Please do not interpret my silence as anything other than
response still pending.
The issues involved are complex and I don't want to give a misleading
answer.
On Mon, 17 Mar 2008, Asheesh Laroia wrote:
Thanks for letting us know about this issue.
Asheesh's analysis is correct. Without linguistic analysis (which is
probably more than we want to get into!) or user guidance, guessing the
correct character set is a matter of trial and error of which one of
these character sets can do a
I'm not the Pilot maintainer, but is 460,936 bytes really worth worrying
about in this day and age? Assuming US $1/GB (which is probably high
these days), we are talking about $0.0004 in disk cost. That doesn't seem
to be worth it.
I took a brief look and it looks like Pilot includes the
We certainly want to do something better than passfile for UNIX. The
passfile was a hack for the old 640K DOS-based PC Pine. It was never
intended for UNIX Pine.
Passfile is abolished in the latest Windows PC Alpine; we now use
Microsoft's Wincred. Similarly, Alpine uses the keyring on Mac
On Wed, 14 Feb 2007, Asheesh Laroia wrote:
But if PASSFILE is mode 0600 then it's not actually insecure, right (*)?
Isn't that like saying If I'm the only user on my Windows system, then
it's secure, right? ;-)
Or, perhaps, Since /etc/shadow is protected, we don't need to encrypt
them any
On Thu, 15 Feb 2007, Reuben Thomas wrote:
Yet this feature is turned on in PC-PINE (and presumably PC-ALPINE).
PC Alpine no longer uses a passfile. It uses the Windows mechanism to
store credentials. [And there was great rejoicing in the land...]
Maybe the best solution would
be for Pine
On Sat, 6 Jan 2007, Asheesh Laroia wrote:
I'd be curious to know what Dovecot does, since it seems to straddle this
line in some way.
I don't know.
Having said that, if we're talking about Alpine reading a local mail
spool, I don't see why compliance with IMAP's specifications is necessary.
On Sat, 6 Jan 2007, Asheesh Laroia wrote:
Joey Hess filed a bug in the Debian package (*) about Alpine lacking
support for the Maildir mail storage format. Apparently the pine source
package that Debian ships comes with a patch for Maildir support.
Apparently, it comes with an unsupported
12 matches
Mail list logo
