On Fri, Apr 28, 2006 at 09:38:39PM +0200, Paul J Stevens wrote: > Matthew Sayler wrote: > > I thought I'd put this issue more clearly, since it's buried in my bug > > report for 335: > > > > Bug 335 (http://www.dbmail.org/mantis/view.php?id=335) gets triggered > > when headers in a message exceed 4095 bytes in length. The "fault" for > > this lies with GMIME, and in fact the newest 2.1 series GMIME fixes the > > problem (tested in 2.1.19). > > First off, thanks a lot for the drilldown.
No problem. It's a nice change of pace form debugging HTML/JavaScript or Internet connectivity -- which is most of what I do on an average day. Speaking of thanks, mayhaps I could get a mention in THANKS? > > Unfortunately, Debian stable only includes 2.1.14, and the version in > > testing depends on a bunch of other components that can't be pulled into > > stable: > > I don't see any solution right off. We could fix > dbmail_message_set_header to avoid hitting the critical limit > (butt-ugly, I know). We could try stuff like dropping identical headers, > or perhaps even moving a couple of headers to the body of the email. > All that only when detecting a gmime-version < 2.1.15. Where's the fun > in that. I think *fixing* the issue is a not going to be easy. I suggest some sort of warning on configure for dbmail < 2.1.19 and a menion in the release notes. > To be quite honest though, my initial reaction tends to be: sod sarge! > Hail etch! Not the best sales pitch, I guess :-) I'm actually not sure what I'm going to do long term. I'm not really ready to move my mail server to etch. I may just install the package from source (gasp!) and not use the Debian packaging. I may install dbmail on a vserver again instead of on my main mail server. Longterm I really need to retire my current mail server (2xP3 1.2GHz, 2G RAM, 10K SCSI software RAID with qmail as the MTA) for something a with more CPU, better I/O, and a sane MTA (postfix? exim? Haven't decided). Mail serving has gotten quite a bit more CPU intensive in these UCE-filled days, meh. Matt
