A NOTE has been added to this issue.
==
http://www.dbmail.org/mantis/view.php?id=725
==
Reported By:bslagter
Assigned To:paul
Michael Monnerie wrote:
On Montag 16 Februar 2009 Mantis Bug Tracker wrote:
For instance, one of them, write_addrspec function (which is used for
From, To, and similar headers), parses header value, converts it to
UTF-8, and then converts it back to the charset gmime thinks is best
for this
Michael Monnerie wrote:
Why? What's the difference if you code a recursive delete in C or in
SQL? Can there be a problem with DELETE .. where x'=mail/box%' ? (Apart
from dbmail having a bug, which can be in C too.). Sounds like you do
not trust the database too much ;-)
You misunderstand.
Axel Steiner wrote:
Why does dbmail parse that text at all? It must store it as-is. Why is
there any decoding or stripping?
Because the subjectfield is for thread=orderedsubject, and
thread=orderedsubject so dictates.
--
On Dienstag 24 Februar 2009 Paul J Stevens wrote:
We need a good mimeparser, but gmime is proving to be an moving
target :-(
I hope your work with the devs of gmime is in a good shape :-)
mfg zmi
--
// Michael Monnerie, Ing.BSc- http://it-management.at
// Tel: 0660 / 415 65 31
However, when we start adding a From_ header
to it during delivery, some (recent) versions of gmime will decode
them internally (ok, fine), but then recode them as latin5 is
something like that before giving them back like when we need a
string representatation of a parsed message.
That
Using the debs from nfgd.net
has anybody else noticed that its *really* slow using thunderbird to
download a large email, like 9mb or so. It seems to come in at around
6KB/sec (iftop reports a burst of 12K then 200 bytes or so, alternating
every second)
using squirrelmail I get it at around
On Dienstag 24 Februar 2009 Paul J Stevens wrote:
Why? What's the difference if you code a recursive delete in C or
in SQL? Can there be a problem with DELETE .. where x'=mail/box%' ?
(Apart from dbmail having a bug, which can be in C too.). Sounds
like you do not trust the database too
A NOTE has been added to this issue.
==
http://www.dbmail.org/mantis/view.php?id=725
==
Reported By:bslagter
Assigned To:paul
Because the subjectfield is for thread=orderedsubject, and
thread=orderedsubject so dictates.
Damn, I queried the wrong table in my application. Shall
I fix the stripping problem?
Axel
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
Axel Steiner wrote:
Because the subjectfield is for thread=orderedsubject, and
thread=orderedsubject so dictates.
Damn, I queried the wrong table in my application. Shall
I fix the stripping problem?
Please do. Use the unit-tests in test/check_dbmail_imapd.c
There is a test-case for this
Jake,
This is a known issue. Downloading large messages is just plain broken
in 2.3.5. I've already fixed this.
Jake Anderson wrote:
Using the debs from nfgd.net
has anybody else noticed that its *really* slow using thunderbird to
download a large email, like 9mb or so. It seems to come in at
Jake Anderson wrote:
Paul J Stevens wrote:
Jake,
This is a known issue. Downloading large messages is just plain broken
in 2.3.5. I've already fixed this.
Cool thanks.
any idea of when a new lot of debs would be available?
Right after 2.3.6 is released. I'll be testing the current code
Paul J Stevens wrote:
Jake Anderson wrote:
Paul J Stevens wrote:
Jake,
This is a known issue. Downloading large messages is just plain broken
in 2.3.5. I've already fixed this.
Cool thanks.
any idea of when a new lot of debs would be available?
Right after 2.3.6 is
Jake Anderson wrote:
Paul J Stevens wrote:
Jake Anderson wrote:
Paul J Stevens wrote:
Jake,
This is a known issue. Downloading large messages is just plain broken
in 2.3.5. I've already fixed this.
Cool thanks.
any idea of when a new lot of debs would be available?
Paul J Stevens wrote:
Jake Anderson wrote:
Paul J Stevens wrote:
Jake Anderson wrote:
Paul J Stevens wrote:
Jake,
This is a known issue. Downloading large messages is just plain broken
in 2.3.5. I've already fixed this.
Cool thanks.
any
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project Paul's DBMail tree.
The branch, master has been updated
via ee104778cf6fedc5b77544120159ec28eeccd87c (commit)
via
Paul,
Help here on a thing, with the last git today on my testing server, I get
this after several errors on pop3d.
This seems to be a libglib problem, can you clarify me?
--
flecha:/var/run# telnet flecha 110
Trying 192.168.1.221...
Connected to flecha.
Escape character is '^]'.
+OK
About imapd, after this errors, it should terminated the connection right?
--
flecha:/var/run# telnet flecha 143
Trying 192.168.1.221...
Connected to flecha.
Escape character is '^]'.
* OK imap 4r1 server (dbmail 2.3.6)
aa
* BAD Invalid tag specified
s
* BAD Invalid tag specified
Paul J Stevens пишет:
Simple tests like you did should of course never fail, so I do
appreciate 'bt full' backtraces of crashes if you think I may have
missed something.
ee104778cf6fedc5b77544120159ec28eeccd87c commit
gdb /usr/local/opt/dbmail-git/sbin/dbmail-imapd 3458
GNU gdb 6.4-debian
Performance of lmtpd rocks now).
This part of strace looks odd too, I'm talking about increasing reads.
This is a receiving of one 10k message.
read(17, From: t...@test.ru\r\nTo: test@..., 4096) = 4096
read(17, XXX\r\n1XX..., 4096) = 4096
read(17,
21 matches
Mail list logo
