Since 2.0 will be a major release, now is the perfect time to lay down what
versions of other software is required. I think any minimum requirements cited
for 2.0 should be supported until the next major release cycle, presumably 2.2.
If we go with supporting mysql 3.x in 2.0 now, then this prob
New Thread
I was thinking of an NNTP server that would be on the scale of Aaron's
example, and not Leif's.
I never really liked the archiving done by pipermail/mailman, its hard to
make threads cross archiving intervals.
I would like to see a mailbox exported to a nntp group. that way archives
c
On more fundamental open source grounds, requests like these are generally
just useless noise. Development happens when someone wants some software to do
x,y,z task, cannot find anything to their liking, and so the person then goes
and writes the software themselves. If they share it with others, t
Ed, For good reason,
I used to work for one of the worlds largest NNTP providers. And believe
me from experience we do not want to get into NNTP stuff. The reason none
of the currently available NNTP server code uses an RDBM is that the file
IO is so heavy and requires so much IO that it takes al
Let me know when the NNTP service starts development.
No other NNTP servers that I've found use a RDBMS backend.
ed
On Mon, 15 Mar 2004, Aaron Stone wrote:
> This is really, really good... I wonder if it can be combined with a macro or
> built into a macro so that the "if (ci_write) return -1" c
This is really, really good... I wonder if it can be combined with a macro or
built into a macro so that the "if (ci_write) return -1" could be "ci_write"
and since there's only ever one stream to write, "ci->tx" could be assumed.
The LMTP code doesn't use the ClientInfo structure, but in the proc
I've had to work on imap and friends extensively for my company and yes, the
indenting is different in different places and drives me batty. Definitely
would be nice to figure out a standard indentation and keep to it.
On Mon, Mar 15, 2004 at 07:21:19PM +0100, Paul J Stevens wrote:
> IMO imap4.c
Hi all,
Since there were no takers, I did a follow-up on my earlier conclusion
that the networking code could do with some improvements.
For those of you who haven't followed the list; dbmail2 won't work with
mozilla and derivatives.
I've wrapped the code talking to clients in simple wrappers
On Tue, Mar 16, 2004 at 07:09:06AM +1300, Mark Mackay - Orcon wrote:
> > Or add the following line to at the top of /etc/apt/sources.list
> > deb http://packages.dotdeb.org
>
> Way cool! Thanks for the info.
> Much easier than my way :)
backports.org also has mysql packages, in addition to a ton
> Or add the following line to at the top of /etc/apt/sources.list
> deb http://packages.dotdeb.org
Way cool! Thanks for the info.
Much easier than my way :)
/Mark
Ok, so DATE_FORMAT() is a weird one. Consistent and good, but I think I was
expecting usefulness in context, which is a MySQL kind of thing to do, rather
than just plain consistency :-P
It can be used in the VALUES section of an INSERT or in an UPDATE, but I'm not
sure why you would do that. The f
Strange indeed.. since I use postfix to inject the mail into dbmail-lmtp.
If you can look into it now, I'll get on it tomorrow.
Ilja
Aaron Stone wrote:
I found that when I type messages directly into LMTP they get the extra ':'
colons. The common theme is that I never type in a decent header
Oh, wow ok oops. Are you developing with PostgreSQL as your primary platform?
That would be really good, because I'm working with MySQL :-)
The corresponding DATE_FORMAT() function in MySQL does happily go into any
part of the query, so rather than just quoting the date for MySQL, I'll add in
the
On delivery, every line is checked to see if it ends in \n or \r\n for the
purposes of keeping an accurate rfcsize. The rfcsize is the size of the
message with all newlines converted to \r\n. When the message goes out via
IMAP, the newlines are supposed to be converted to \r\n. Nothing is modified
I found that when I type messages directly into LMTP they get the extra ':'
colons. The common theme is that I never type in a decent header by hand.
When I send mail through Postfix and using a mailer that puts on decent
headers, and Postfix send it through LMTP (finally got it working!) there ar
BTW,
Everything is well when using dbmail-smtp (using pipe from postfix).
When using dbmail-lmtp, things get screwed up because lmtp already adds
'\r\n' instead of '\n' to every line.
I'm getting a bit confused here.. :(
Are we trying to store messages using only '\n', or also using '\r\n',
I think something goes wrong on insertion of messages. I have the
feeling that an extra '\r' is included:
I've made a small script that uses IMAP, and I get the following output:
Received: by test01.office.fastxs.net (Postfix, from userid
1000)\r\r\n\tid A2BAA19F30C; Mon, 15 Mar 2004 14:05:48 +
I'm still working on the inclusion of the extra ':' in messages when
using IMAP.
What I've found so far is that somehow the parser doesn't find the end
of the headers, and sees the beginning of the body as part of the
headers, and then includes the line in the body as a header line, adding
an
Ilja Booij wrote:
Hi,
MySQL >= 4.0.14 does not seem like very bad thing to require.
Of course, we're using debian stable here, which still has 3.23.x as its
MySQL version.. But that shouldn't be too much of a problem :). We could
just install from source or the binary tarballs at mysql.com
I think we're ALMOST ready for rc4. Currently I'm working on the problem
of the insertion of ':' in message bodies, which was mentioned in an
earlier thread.
I have not been able to reproduce the error that is mentioned by Blake
Mitchell in this thread. Perhaps it has something to do with the
Hi,
MySQL >= 4.0.14 does not seem like very bad thing to require.
Of course, we're using debian stable here, which still has 3.23.x as its
MySQL version.. But that shouldn't be too much of a problem :). We could
just install from source or the binary tarballs at mysql.com
We should go for th
fixed by making the following change in dbmysql.c:
<< const char *TO_DATE = "%s";
>> const char *TO_DATE = "'%s'";
and of course, I removed the change in
db_insert_physmessage_with_internal_date()
Ilja
Ilja Booij wrote:
Hmm,
this presents a problem. The statement did not have the quotation
Hmm,
this presents a problem. The statement did not have the quotation marks,
because on PostgreSQL the query looked liked this:
INSERT INTO physmessage (messagesize, internal_date) VALUES ('0',
TO_TIMESTAMP('2004-03-15 08:00:01', '-MM-DD HH:MI:SS'))
So, no quotes around the TO_TIMESTAM
I say dump the older versions of mysql as well.
SB
Aaron Stone <[EMAIL PROTECTED]> wrote:
According to Blake Mitchell's post a few hours ago, we're already using MySQL
4.0 features in some of the JOIN syntax. Really by "features" I mean "support
for long standing, published SQL92 specifications
Leif,
>From the RFC it does not appear that SORT will be too hard to implement.
>THREAD appears to be much more hairy. I will be happy to help testing SORT if
>you can get it written. I am not familiar with the code at all
Thanks.
SB
Leif Jackson <[EMAIL PROTECTED]> wrote:
> This observ
I'm getting some empty messages in Thunderbird .5 (MySQL 4), all the
headers are there, but the message body is empty. The trace doesn't look
suspicious to me:
Mar 14 17:57:40 sls-cd7p8 dbmail/imap4d[30427]: IMAPClientHandler():
line read for PID 30427
Mar 14 17:57:40 sls-cd7p8 dbmail/imap4d[3
That's a really good point! So we should all add this url (newlines added for
clarity) to our collective memories:
http://packages.debian.org/cgi-bin/search_packages.pl?
keywords=mysql-server
&searchon=names
&subword=1
&version=all
&release=all
Aaron
""Mark Mackay - Orc
Fine by me. As long as we don't require anything ahead of the current Debian
'testing' MySQL version ;)
/Mark
According to Blake Mitchell's post a few hours ago, we're already using MySQL
4.0 features in some of the JOIN syntax. Really by "features" I mean "support
for long standing, published SQL92 specifications" -- most or all of which are
supported by PostgreSQL (and I know that PostgreSQL people hate
Sounds like it would be good to have in place as soon as possible, so those
of us using new versions can get the optimizations.
Maybe a compile-time option or something for 1-2 months?
Or perhaps a runtime check -- call the select version() function and make
sure is high enough, etc.
/Mark
>
Yay!!! You are a life saver Leif.
SB
Leif Jackson <[EMAIL PROTECTED]> wrote:
> This observation was made before :)
>
> SORT and THREAD will have to be implemented for version 2.1
Or as a patch to 2.0 if I can get it done shortly, I really need it for
our application which is a web based mail des
Looks like missing quotation marks. Check CVS again in a few minutes...
Aaron
Blake Mitchell <[EMAIL PROTECTED]> said:
> This breaks with MySQL 4.0.18
>
> /var/log/maillog.1-Mar 13 17:50:41 sls-cd7p8 dbmail/imap4d[23029]:
> COMMAND: [092G APPEND "Drafts" (\Draft) "13-Mar-2004 12:34:48 -0800"
32 matches
Mail list logo
