On Tue, 2005-04-05 at 16:40 -0600, Jesse Norell wrote: > > > > So it's more a question of what is the practical limit dbmail should use > > > for cached headers (and it simply doesn't cache values if above that > > > limit). > > > > Yes it does: > > > > dbmail/lmtpd[29839]: dbpgsql.c, db_query: Error executing query [INSERT > > INTO dbmail_headervalue (headername_id, physmessage_id, headervalue) > > VALUES (23,3612,'a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; > > > h=received:message-id:from:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; > b=NHvYPHzaPDu3ThkTc+qw5jYjbCcWnHojOqH8/HTNzMW+E7ZOHX1Itrn3LfiL3veTN4t/BlPG1KqoERtakpttrt5SOglQ/1plGcP6cF+Ud5ehhrYGtywP0LBG3toxCj/+LuapwPd8e/7TKsokyl3Vx3X8iEuQANROV/NQQMynfU0=')] > : [ERROR: value too long for type character varying(255) ] > > > Right, I was meaning the right thing to do would be to not cache values > above that size (although depending on how the header cache ends up being > used, the right thing may be to either add a flag for being oversized and/ > or just cache the first X bytes).
Sorry, I guess I misunderstood your answer.. :o Beeing an SQL addict I prefer to store as much as possible in a database. My preferred way would be the oversize-flag method. maybe dbmail could read the max size of the field on startup and clip the text to [max fieldsize] characters. (wishful thinking) Anyway, if the cached header values are not a critical part of the mail storage (not used by dbmail in any way), then they could be inserted in a separate transaction with only a warning if something goes wrong.. Another effect of this was that neither the original recepient or the mail sender received any clear notice of the error, just a "null-recipient" error that was hard to understand. I had to search the logs to find it, and with 20-30 spams rushing in each minute that's always an unpleasant thing to do. -- Robert
