On Thu, 27 May 2004 12:21:22 +0200 Ilja Booij <[EMAIL PROTECTED]> wrote:
> That was a completely unilateral decision on my part. I figured > that we're storing emails, not just some arbitrary data. I > don't think we have to take care of messages larger than, say, > 128MB. Most ISP don't accept messages larger than 4MB, IIRC. We > should put a configurable (using dbmail.conf) limit on the > message size, and load it with a sensible default. That's the right approach. We used to limit the message size to 2MB as users on dial-up connections typically couldn't retrieve anything larger than that. With greater broadband penetration some customers have wanted to sent much larger files, so we're running a second uncapped service, and we've pushed the cap on the other to 8M and increased the POP timeout. While I don't think I've seen anything larger than about 80M(damn printers), give it time. While you're all discussing the code structure, it struck me that it may be useful to move all the hardcoded text to a single header file. This would allow easy localisation and customisation of error messages and the like. -fr. -- Feargal Reilly, Codeshifter, Chrysalink Systems. ICQ: 109837009 | YIM: ectoraige PGP Key ID: 0xE721BBE6 (expires 06-Aug-2004) Visit http://ie.bsd.net/ - BSDs presence in Ireland
pgp70uB4UZ2Py.pgp
Description: PGP signature