On Sat, 2004-06-05 at 03:22, Micah wrote: > Don't know if you care, but FYI: > > I setup custom servers for special web projects, so I have a few developers > that use dbmail, they're sending 75-100+ megabyte mails all the time. I used > to limit at 1 Gb, but I noticed that dbmail would choke on anything more than > about 300mb, so that's my limit now. > > I took a look at the logs, and a 277 mb email went through fine on Tuesday. > > The issue I've noticed is not message acceptance, but final delivery. POP3 > does pretty good, but IMAP uses a lot of resources for mail more than 75mb or > so.. > > The Mailserver is linux/mysql/postfix with a 60 gig drive, and a gig of > memory.. Athlon 2400 processor. Works great.. Only about 100 domains and > about 700 users though. Not huge. That may play a part. This is currently > running dbmail 1.2.7b.. I think I was running 1.2.5 when I was dealing with > the large email problem. > > -Micah > > On Friday 04 June 2004 06:25 am, Feargal Reilly wrote: > > On Thu, 27 May 2004 12:26:36 +0100 > > > > Feargal Reilly <[EMAIL PROTECTED]> wrote: > > > 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.
Personally, I'd feel better if dbmail was capable of storing emails of any size. Should be possible using either bytea/blobs, tho messages larger than 1Gb needs to be split into several rows, as on pg the max field size is 1Gb. Dont know about mysql's blobs. > > > > > > 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. > > > > For the record, just noticed two 169M emails passing through our > > server. The contents? A cargo manifest. > > > > -fr. > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev John