Seems like shared folders are the way to go here; having one person have
access to everyone elses' INBOX directly. What's the status on shared
folders in DBMail?
The IMAP Followup flag is almost universally supported, so it can be
used for to-be-replied.
For tracking if messages have been
On Thu, 2006-09-14 at 01:31 -0400, Morty wrote:
On Tue, Sep 12, 2006 at 08:39:12AM -0600, Jesse Norell wrote:
That's most likely the order in which the database returns the
message id's .. eg. see what something like select message_idnr
from dbmail_messages where mailbox_idnr =
On Thu, 2006-09-14 at 10:19 +0200, Lars Kneschke wrote:
Aaron Stone [EMAIL PROTECTED] schrieb:
Ok. I changed my code. But should not change that value at least on
delete?Â
Nope, I don't think so. When UIDVALIDITY changes, it means all UID's that
you have cached must be thrown away and
On Mon, 2006-09-18 at 11:34 -0700, Aaron Stone wrote:
On Mon, 2006-09-18 at 14:01 -0400, Geo Carncross wrote:
SELECT pm.messagesize, msg.message_idnr, msg.status, msg.unique_id
FROM dbmail_messages msg, dbmail_physmessage pm WHERE msg.mailbox_idnr =
'81'
AND msg.status '2
On Thu, 2006-08-17 at 10:48 -0700, Aaron Stone wrote:
On Thu, 2006-08-17 at 17:19 +, Michael Tabolsky wrote:
On Thu, 2006-08-17 at 17:29 +0200, Lars Kneschke wrote:
A webbased application has stored the database connection string in
cleartext somewhere on the webserver. If you hack
On Wed, 2006-06-21 at 16:53 -0500, Jim C. Nasby wrote:
One possibility would be to have the database handle all authentication
and requests via stored procs, and restricting the dbmail database
account to only having access to those stored procs. Or you could use
per-user authentication to the
On Wed, 2006-06-21 at 16:31 -0700, Aaron Stone wrote:
On Wed, 2006-06-21 at 16:53 -0500, Jim C. Nasby wrote:
Of course, it goes without saying that DBMail should be coded to reduce
the likelyhood of any possibility of an attack.
Totally. And not to rain on this parade, but as I don't
On Mon, 2006-06-19 at 22:04 +0200, Paul J Stevens wrote:
Aaron Stone wrote:
In any case, I fail to see how this is an issue: if you're using
dynamically generated code in performance critical areas of the server
you have bigger things to worry about than the overhead of prepared
On Tue, 2006-06-20 at 09:45 +0200, Paul J Stevens wrote:
Geo Carncross wrote:
Just FYI: VACUUM is no longer required in sqlite3- the database can
AutoVacuum as necessary.
Great.
This change is in the DIFF.
... and I thought we were stopping the REGEX stuff to take advantage
On Tue, 2006-06-20 at 16:36 +0200, Paul J Stevens wrote:
Geo Carncross wrote:
On Tue, 2006-06-20 at 09:45 +0200, Paul J Stevens wrote:
Geo Carncross wrote:
Just FYI: VACUUM is no longer required in sqlite3- the database can
AutoVacuum as necessary.
Great.
This change
On Sun, 2006-06-18 at 14:08 +0200, Marc Dirix wrote:
As every good administrator, don't change a working system unless you
have to, and
regularly check if things are still ok. Administrating is not a job
of only creating new applications, improving application or spending
your bosses
On Mon, 2006-06-19 at 16:22 +0200, Paul J Stevens wrote:
Geo Carncross wrote:
So what you're telling me is that you think only developers of dbmail
should be weighing in on the subject of dbmail's security?
That would be the death of dbmail.
I'm no security expert at all, and afaik
On Thu, 2006-06-15 at 13:45 -0400, M. J. [Mike] OBrien wrote:
With all due respect:
1) A rant with no specifics on known security exploits, may raise attention
and awareness but doesn't offer much.
Agreed.
2) Please *Do not cry wolf* unless you see and unequivocally identify a
wolf. I
On Thu, 2006-06-15 at 20:52 +0200, Marc Dirix wrote:
6) Always maintain a good back-up regimen for your database.
I think asking users to solve security issues by having good backups
is really ridiculous.
As most of us understood, he meant server-side backup of the
database, so
On Thu, 2006-06-15 at 15:01 -0500, Jim Nasby wrote:
On Jun 15, 2006, at 1:20 PM, Geo Carncross wrote:
This might actually be easier- All three supported databases (in a
way)
support a concept of access controls. With MySQL and Pg, each
mailbox
could be given a separate table (unless
On Wed, 2006-06-07 at 10:06 -0700, Aaron Stone wrote:
SQLite has lousy LIKE behavior: it's case insensitive for the US-ASCII
range, and case sensitive everywhere else. I noted a FIXME in
dbsqlite.c.
I think we can't very well replace LIKE (because it might be needed
elsewhere), but if we could
On Tue, 2006-06-06 at 13:37 -0700, Aaron Stone wrote:
On Tue, 2006-06-06 at 16:13 -0400, Geo Carncross wrote:
Not all databases support REGEXP as an operator.
Everybody's got some keyword that performs this type of match. I added
entries to the db_get_sql fragment function to grab the right
On Tue, 2006-06-06 at 22:08 +, Aaron Stone wrote:
You also don't need to include sqlite3.h -- it's only using the SQLite2
API, even if the database format itself can be SQLite3.
My understanding is that we need a whole new module, dbsqlite3.c, to make
the version 3 calls and to compile
Not all databases support REGEXP as an operator.
LIKE is either case-insensitive, or can be made so with a
(database-specific) operator on most databases.
Moreover, LIKE can often take advantage of indexes.
Consider for PostgreSQL:
x ILIKE 'SENT' OR x ILIKE 'SENT_ITEMS'
Consider LIKE
On Thu, 2006-05-11 at 08:25 -0700, Aaron Stone wrote:
This drives me bonkers. I would have liked to see new IMAP rfc's go in
the other direction by specifying MORE magic mailboxes.
I think allowing something like KEYWORDs or ANNOTATIONs on
folders/mailboxes is the way to go.
It'd certainly go
, then fine.
Geo Carncross wrote:
On Wed, 2006-03-15 at 09:19 +0100, Paul J Stevens wrote:
Aaron Stone wrote:
If we don't want to break existing scripts/installations:
default: fork, detach.
-n: no-fork, no-detach.
(new) -d, fork, no-detach.
Weirdness: -nd means what? same as -n
On Wed, 2006-03-15 at 16:33 -0800, Aaron Stone wrote:
On Wed, 2006-03-15 at 18:36 -0500, Geo Carncross wrote:
On Wed, 2006-03-15 at 14:30 -0800, Blake Mitchell wrote:
Geo, I think you are confusing your forks. You are thinking fork as in
run in the background by forking and then killing
On Wed, 2006-03-15 at 09:19 +0100, Paul J Stevens wrote:
Aaron Stone wrote:
If we don't want to break existing scripts/installations:
default: fork, detach.
-n: no-fork, no-detach.
(new) -d, fork, no-detach.
Weirdness: -nd means what? same as -n?
However I would rather break
On Tue, 2006-03-07 at 21:56 +0100, Marc Dirix wrote:
Using the and the sorts is just plain wrong.
Why?
You want a daemon if it daemonizes itself to daemonize by itself without
needing any shell implementation.
No I don't.
Daemons get started by the shell anyway. The shell is in a perfect
On Tue, 2006-03-07 at 21:33 +, Aaron Stone wrote:
On Tue, Mar 7, 2006, Geo Carncross said:
On Tue, 2006-03-07 at 20:11 +0100, Paul J Stevens wrote:
Since we already support 1 and 3, adding 2 would make this picture
complete. We could then also allow selection of the default through
On Wed, 2006-03-08 at 00:49 +0100, Marc Dirix wrote:
Like I said, a daemon should run indepedentally from the shell
implemantation.
But you haven't said _why_.
And secondly, starting from inittab is IMHO only usefull for daemons
which tend to get killed or die, and therefor is a quickfix for
On Wed, 2006-03-08 at 00:23 +, Aaron Stone wrote:
On Tue, Mar 7, 2006, Geo Carncross [EMAIL PROTECTED]
said:
I have no idea how to attack this for _all_programs_ i.e. the community
at large, when really, the problems that would affect dbmail DON'T
affect some other programs.
Write
On Wed, 2006-03-08 at 09:32 +0100, Thomas Mueller wrote:
Hi Geo,
But even working init.d scripts and working daemons can be killed or
stopped for lots of reasons, and unless you duplicate the work of init,
or manually intervene, they won't start back up.
I read that argument several
On Wed, 2006-03-08 at 11:47 -0500, Matthew T. O'Connor wrote:
Geo Carncross wrote:
Nonetheless, hung processes are another deal: hung processes are the
result of broken code, or a broken design.
No more so than a program that crashes or a kernel that randomly kills
off processes
On Wed, 2006-03-08 at 10:28 -0800, Aaron Stone wrote:
On Wed, 2006-03-08 at 12:38 -0500, Geo Carncross wrote:
I would like to see a process that can resist kill -9
I once had a process stuck in the D state, waiting on returns from a
filesystem located on a block device that was dying
On Wed, 2006-03-08 at 09:58 -0800, Christian G. Warden wrote:
Two benefits of init.d are that it makes it easier to stop services
Do we often want to stop services?
makes it easier to define dependencies between services.
init.d has NO support for declaring dependencies, only the ability to
Add - - 2- and stuff your startup script.
But you should have already known to do that. init.d scripts are
unreliable and no decent unix administrator should recommend them for
running services.
Something as critical as email should probably be run from inittab (or
daemontools) anyway- unless
.
...
/Marc
On Mon, Mar 06, 2006 at 10:33:32AM -0500, Geo Carncross wrote:
Add - - 2- and stuff your startup script.
But you should have already known to do that. init.d scripts are
unreliable and no decent unix administrator should recommend them for
running services.
Something
On Mon, 2006-03-06 at 13:26 -0500, Matthew T. O'Connor wrote:
Geo Carncross wrote:
Daemons also run as root. Root-owned processes shouldn't be killed so
quickly by the OOM killer, so getting them killed by other means (say,
reasonable resource limits) is even more important.
The OOM
On Mon, 2006-03-06 at 14:33 -0500, Matthew T. O'Connor wrote:
I disagree here, a program can intelligently deal with a malloc()
failure, PostgreSQL does this very well in fact. A program can not deal
intelligently with getting killed at random moments. So I disagree that
OOM is a way of
On Mon, 2006-03-06 at 23:06 +0100, Paul J Stevens wrote:
Marc Dirix wrote:
I think if you want to start the process in your special
way, you could make an option for dbmail to not daemonize, and
let the others use it like they are used to. There are a lott good
daemons who have an
On Sat, 2005-12-17 at 17:59 +0100, Thomas Mueller wrote:
With a mime message like this:
--b1
text
--b1
rfc822
--b2
text
--b2--
--b1--
Perhaps a parts layout similar to this:
part,pre_boundary, content, encoding, post_boundary
'1', 'b1', 'text', 'us-ascii', NULL,
On Thu, 2005-12-15 at 14:24 -0800, Kevin Brown wrote:
Geo Carncross wrote:
I know we talked about this earlier, but I think for 2.2 we need to make
it possible to have multiple queries- we talked about it per database
layer, but why not a global conformance level setting?
DB_CAN_VIEW
On Thu, 2005-12-15 at 14:16 -0800, Kevin Brown wrote:
Paul J Stevens wrote:
And I suspect 5.0 will be become a requirement for 2.3+ so we can
start working with views, triggers, etc...
Hmm...that would imply ditching SQLite, wouldn't it?
Not that I have a problem with that, mind you.
On Fri, 2005-12-16 at 11:11 -0800, Kevin Brown wrote:
Geo Carncross wrote:
On Thu, 2005-12-15 at 14:16 -0800, Kevin Brown wrote:
Paul J Stevens wrote:
And I suspect 5.0 will be become a requirement for 2.3+ so we can
start working with views, triggers, etc...
Hmm...that would
On Thu, 2005-12-15 at 09:46 +0100, Paul J Stevens wrote:
Kevin Brown wrote:
Aaron Stone wrote:
Something without a subquery is needed, as the 2.0 series must continue
to work with MySQL 4.0.x.
We can't just force people to upgrade to 4.1.x? It'd be good for
them. Forcing them
On Thu, 2005-12-15 at 17:35 +0100, Thomas Mueller wrote:
Geo Carncross wrote:
I completely agree with this. There's just the problem of databases
being a moving target. Remember we talked about COUNT(*) not being
optimally implemented in Pg, but one day it could be, and at that point
On Thu, 2005-12-15 at 09:50 -0800, Kevin Brown wrote:
I mean, does it apply specifically to COUNT(*)? I checked the release
notes and I couldn't find mention of it...
If you're looking to find the total size of a table, no. In
PostgreSQL, that's a Fundamentally Hard Problem because of
On Thu, 2005-12-15 at 10:05 -0800, Kevin Brown wrote:
Geo Carncross wrote:
I mean, dbmail knows what queries it uses, and I don't suggest for a
moment that dbmail should attempt to find optimal queries for suboptimal
(read: old) databases, but if dbmail 2.0 works with 4.0 then 2.2 should
I wrote this query back in [EMAIL PROTECTED]
I also suggested the alternative:
select count(*), count(case when seen_flag 0 Then 1 else null end),
count(case when recent_flag 0 then 1 else null end) FROM
dbmail_messages WHERE status '2' and mailbox_idnr='1';
in [EMAIL PROTECTED]
but I
On Sun, 2005-11-06 at 14:28 -0800, K C wrote:
I've replaced this kind of unique indexes with just normal
(physmessage_id) if there is no other index can index physmessage_id.
This is to make sure physmessage_id can use index. But unique index
on (physmessage_id, id) is unnecessary here.
structure of the database.
Why does anyone want to drop any index? Do we know of a system that will
benefit from having a single UNIQUE(a,b) - because AFAIK, no useful
system will benefit in this situation from having a single UNIQUE(b)
On 11/7/05, Geo Carncross [EMAIL PROTECTED]
wrote
Furthermore, it should be backend-specific:
SQLite never requires a vacuum- it never buys anything (when autovacuum
is turned on), but this has and may change again. It's certainly
version-specific, but because it has to lock the entire database, it
would seem that doing a vacuum on SQLite
it calls a 'VACUUM tablename'. For sqlite it calls a 'VACUUM' on
the entire db afaict.
Geo Carncross wrote:
Furthermore, it should be backend-specific:
SQLite never requires a vacuum- it never buys anything (when autovacuum
is turned on), but this has and may change
On Wed, 2005-09-28 at 19:12 +0200, Paul J Stevens wrote:
[EMAIL PROTECTED] wrote:
Reported By:ekristen
adding the user_idnr to the dbmail_messages table would improve selecting
messages from the database for someone who would be writing a webmail
interface for dbmail. So
On Mon, 2005-08-22 at 14:24 +0200, Paul J Stevens wrote:
I'm not sure why sprintf would call malloc... but looking at the glibc
code, it gets called quite a lot! Looks like they're fully preparing the
strings before any output happens, rather than output-on-the-fly.
The glibc people are big
Now that I'm awake (somewhat) I'll try and write this :)
I'm aware of two algorithms basic for making a tree/graph in SQL.
The first takes advantage of modular exponentation. I've seen varients
using log and COMPLEX and whathaveyou- but this works on most SQL
engines:
On Thu, 2005-08-11 at 17:52 -0700, Christian G. Warden wrote:
Can anyone tell me if the server is following the IMAP protocol in the
following dialog? The EXISTS and RECENT responses before the FETCH are
throwing off my IMAP client[1], and I'm trying to figure out if it's a problem
with
On Thu, 2005-08-11 at 16:47 -0700, [EMAIL PROTECTED] wrote:
Logo eh..Good idea.
Hard to visualize db. Almost every vendor and schema group represent
db graphically as a cyclinder. Why a cylinder I wonder. It's almost an
industry standard now.
It's supposed to be a magnetic drum which was
On Tue, 2005-07-26 at 22:46 -0400, Mordechai T. Abzug wrote:
On Tue, Jul 26, 2005 at 10:30:21AM -0400, Geo Carncross wrote:
If a flag changes on UID 9 on host A and host B at nearly the same
time (between replications) which flag change wins? What if they're
not incompatible (one marking
On Mon, 2005-07-25 at 19:47 -0400, Mordechai T. Abzug wrote:
On Mon, Jul 25, 2005 at 12:36:43PM -0400, Geo Carncross wrote:
It is. That's okay- the idea is that B will simulate a delete of
uid 6 as part of the replication, otherwise a client connecting to
B will see two copies of one
On Fri, 2005-07-22 at 15:43 -0400, Mordechai T. Abzug wrote:
Nevertheless the problem still exists:
Client is fresh
Client connects to A and gets UID 1,2,3,4,5,7
Client connects to B and sees EXISTS=6
because B sees UID 1,2,3,4,6,7
Client will NEVER download
On Mon, 2005-07-25 at 11:30 -0400, Mordechai T. Abzug wrote:
Note: B however cannot ignore that message. It _MUST_ rewrite
it. It's not acceptable for UID 6 to refer to a different message on
each host. After that replication, a request for UID 6 must fail.
No; my terminology (email vs.
On Wed, 2005-07-20 at 00:23 -0400, Mordechai T. Abzug wrote:
On Fri, Jul 15, 2005 at 02:02:27PM -0400, Geo Carncross wrote:
Won't work. As much as it seems like this would be a good idea (and
believe me: about half a dozen people on this list have had it, so
it certainly is a good idea
I realize there's a lot of people who can't see it, so I've isolated
an example program that demonstrates the problem.
The attached (short) C program attempts to run a counter. You can modify
two portions: the first is where you set an initial counter, and the
second is how the counter is
On Fri, 2005-07-22 at 14:18 -0400, Mordechai T. Abzug wrote:
On Fri, Jul 22, 2005 at 10:43:17AM -0700, Christian G. Warden wrote:
The design actually ensures, in this exact scenario, that the client
does see the mail. What happens is that when B creates email UID 3, B
sends A a
On Fri, 2005-07-15 at 18:52 +, Aaron Stone wrote:
On Fri, Jul 15, 2005, Geo Carncross [EMAIL PROTECTED]
said:
This is the grandfather of the thread:
[EMAIL PROTECTED]
Demonstrating unsolvability of IMAP problem by comparing to unsolvable
clock problem:
[EMAIL PROTECTED
On Thu, 2005-07-14 at 23:46 -0400, Mordechai T. Abzug wrote:
On Fri, Jul 15, 2005 at 02:16:02AM -, Aaron Stone wrote:
I can't find the thread at the moment, but the best plan we have so
far is a token passing system. There was a proposed API posted to
the list, which is a good
On Thu, 2005-07-14 at 19:02 -0400, Mordechai T. Abzug wrote:
So, I'm interested in setting up a mail server with multimaster
replication that supports POP, IMAP, and SMTP. It looks like dbmail
might fit the bill, except for this:
On Thu, 2005-06-09 at 18:32 -0700, gopalakrishnan kamalanathan wrote:
So, does it keep all the message information that it retrieves from the
database in memory?
I notice that the Memory usage increases as more messages are retrieved.
How do you notice this? The chart you provided doesn't
.
I think that covers all the important stuff... Am I missing anything?
On Tue, 2005-05-31 at 19:38 +, Aaron Stone wrote:
Yes, that fills it out. I'll start massaging the thread into an action
plan.
On Tue, May 31, 2005, Geo Carncross [EMAIL PROTECTED]
said:
On Tue, 2005-05-31
On Mon, 2005-05-30 at 20:11 +, Aaron Stone wrote:
DBMail 2.0.x currently inserts a message with ownership set to an internal
user, then performs the delivery resolution and uid generation, and copies
the message over to any user scheduled to receive it.
In a clustered setting, we add one
I want to clarify here:
1. write the message - state=0
at state==0, a message doesn't have a valid UID.
2. wait for token - generate uid, state - 1
at state==1, a message might have a valid UID, but it isn't proven to be
valid- that is, it's still not allowed to be seen by clients.
3. wait
On Tue, 2005-05-31 at 17:15 +, Aaron Stone wrote:
I've added a page to the wiki with your last three emails. I think we're
at the point where we should hammer out a plan for the implementation.
http://dbmail.org/dokuwiki/doku.php?id=unique_token
There's just one piece left to properly
Recapping the thread:
``One thing I was thinking of would be a hack to make one server always
use only odd UIDs, and the other always use only even UIDs, and to do
catchups while they are reachable with each other. But this is getting
into hacking code I know nothing about, yet. Maybe a later
, 2005, Geo Carncross [EMAIL PROTECTED]
said:
On Fri, 2005-05-27 at 10:51 -0700, Kevin Baker wrote:
Thanks for the explination I totally understand now.
That being said, what is the actual harm in one message id
being even a second off for the UID. They will both be
entered
(either
the database sets it with a trigger or second-agent, or _we_ do using
the token passing protocol), so it might as well be time to start adding
it.
dbmail TRUNK will simply APPEND with that bit set until we add the
requisite UID generation part.
On Mon, 2005-05-30 at 10:10 -0400, Geo Carncross
On Thu, 2005-05-26 at 22:53 +0200, Paul J Stevens wrote:
I was just under the impression that a certain amount of diversion doesn't
affect the usability of the system. It just affects it's level of correctness,
and it's cheaper.
Nope. IMAP clients are allowed to take advantage of the fact that
be bound not by time but by the number of messages, but it also
means that we'd lose significant clustering flexibility.
***
Why isn't the a spec for 64 bit IMAP ids yet?! Should we write one?
Aaron
On Thu, May 26, 2005, Kevin Baker [EMAIL PROTECTED] said:
Geo Carncross wrote:
On Thu
On Fri, 2005-05-27 at 09:24 +0200, Thomas Mueller wrote:
Geo Carncross wrote:
The clock idea would work if the clocks could be kept synchronized, but
that's just not possible. It's very hard work to get machines on a LAN
synchronized within 10msec, and clocks can NEVER go backwards
On Fri, 2005-05-27 at 10:13 +0200, Paul J Stevens wrote:
If you're not talking about auto_increment, what do you mean by mysql
supporting sequences. That's the only kind I know of in mysql.
See below.
Fortunately, if auto_increment were also UNIQUE I would consider it a
bug in MySQL if it
On Fri, 2005-05-27 at 09:25 -0700, Kevin Baker wrote:
snip: discussion about time zones
No, if the GUIDs are generated from a clock, then this
won't ensure that
GUIDs are always increasing.
To reiterate from previous emails:
What if one of the provider's clock runs fast? Runs slow?
On Fri, 2005-05-27 at 10:51 -0700, Kevin Baker wrote:
Thanks for the explination I totally understand now.
That being said, what is the actual harm in one message id
being even a second off for the UID. They will both be
entered in the mailstore, even if they are slightly out of
order.
It
On Thu, 2005-05-26 at 13:49 +0200, Paul J Stevens wrote:
Ok, let me recapitulate:
- we want to replace all auto-incremented fields with bigint fields to
hold uuids in order to accomodate N-clustered databases.
- we can't directly use those uuids as UID message attributes because
On Sun, 2005-05-15 at 09:49 +, Aaron Stone wrote:
Not to discount the value of this discussion, but in the present moment we
need to figure out a proper fix for the bug described above that does not
compromise the dates which have already been entered into people's
databases, or is at
On Wed, 2005-05-11 at 21:36 +, Aaron Stone wrote:
OK, sounds great, but please don't CC me directly in list discussions!
[[ Have your email client set a Reply-To: to the list, or a Mail-
Followup-To: to the list and I'll hit the right one. Until then, I'll
remove you manually when I see it.
On Thu, 2005-05-12 at 17:08 +, Aaron Stone wrote:
Geo, would you this up as a patch against current dbmail_2_0_branch SVN?
Attached. This means dbmail will mandate GMT/UTC in the SQL-side.
Does that change current behavior? I haven't been following the issue yet,
as to whether we
On Mon, 2005-05-09 at 21:49 +0200, Paul J Stevens wrote:
Ok, so we're talking about an analogue to server.c's CreateSocket that
does unix sockets instead. Paul, do you have any code up your sleeve for
this, or is it a new project to work on?
No code. Not a big project either.
Add
On Sun, 2005-05-08 at 02:48 +, Aaron Stone wrote:
if no mime headers are found in incomming lmtp message, lmtp hangs
instead of returning error.
May 7 10:06:55 sanatana dbmail/lmtpd[46815]: mime_readheader(): no valid
mime h
eaders found
May 7 10:06:55 sanatana kernel: May
On Mon, 2005-05-09 at 17:12 +, Aaron Stone wrote:
I wonder if the bug reporter's LMTP is sitting in a loop waiting for
feof() on the socket and not reading anything. That would certainly cause
LMTP to hang following the last error message he reported. I thought that
sockets do report EOF
()...
main(): fatal error from mime_readheader());
Aaron
On Mon, May 9, 2005, Geo Carncross [EMAIL PROTECTED]
said:
On Mon, 2005-05-09 at 17:12 +, Aaron Stone wrote:
I wonder if the bug reporter's LMTP is sitting in a loop waiting for
feof() on the socket and not reading anything
pages of text in X3H2-92-154/DBL section 5.2)
Is there any underlying reason for validchars that I'm missing here?
On Fri, 2005-05-06 at 00:54 +, Aaron Stone wrote:
On Thu, May 5, 2005, Geo Carncross [EMAIL PROTECTED]
said:
As long as the password is _ALWAYS_ quoted correctly, I have
As long as the password is _ALWAYS_ quoted correctly, I have no problem
with it.
Wanna check? :)
On Thu, 2005-05-05 at 05:14 +, Aaron Stone wrote:
These two bugs are easily resolved by adding '?' and ',' to the validchars
arrays in POP3 and IMAP. Does anyone feel strongly that these
On Wed, 2005-05-04 at 10:35 -0700, gopalakrishnan kamalanathan wrote:
Do DBMail support any kind of secured user authentication like MD5 or does
it support STARTTLS?
No.
For STARTTLS, you can use stunnel. In fact, you probably should.
One day, it'll probably get CRAM-MD5/SHA1 and
On Sun, 2005-05-01 at 22:27 +0200, Thomas Mueller wrote:
Hi Geo,
sorry for the long delay, I've been very busy and had some problems with
the new clustering feature of the Debian package (some are still left).
No problems at all :)
[[ looking ahead ]] I'm glad this is all getting resolved.
On Thu, 2005-04-28 at 09:07 +0200, Paul J Stevens wrote:
Currently the *only* place that uses (posix) regex is the namespace code in
imap. I just finished a working implementation of base-subject retrieval
using
pcre, but that's not in svn yet.
Why do we need regex for namespaces? The
On Thu, 2005-04-28 at 16:31 +, Aaron Stone wrote:
On Thu, Apr 28, 2005, Geo Carncross [EMAIL PROTECTED]
said:
Try the attached; I just whipped it up as a imap-style fnmatch()
It's not optimal: the *-sync shouldn't be recursive,
but I think it's pretty close to correct.
Awesome
On Wed, 2005-04-27 at 10:51 +0200, Paul J Stevens wrote:
Aaron Stone wrote:
On Wed, Apr 27, 2005, Paul J Stevens [EMAIL PROTECTED] said:
Hi guys,
I'm exploring the usage of regexp?|pcre calls in dbmail. I'm working on
the fast threading code, but it'll come in handy in many other
On Sat, 2005-04-23 at 09:09 +0200, Ilja Booij wrote:
On 4/22/05, Geo Carncross [EMAIL PROTECTED] wrote:
I'm thinking about allowing database drivers to abstract away any
function in db.c (or anything else that generates SQL).
It was brought up before for some postgresql-specific
I'm thinking about allowing database drivers to abstract away any
function in db.c (or anything else that generates SQL).
It was brought up before for some postgresql-specific things or mysql-
specific things, but it seems to me that it could be used for a SQL-free
database interface like
socklen_t is POSIX brain-damaged nonsense. There is absolutely no reason
whatsoever to use it. The BSD sockets api says it should be int, and
socklen_t can't be anything else because of promotion rules.
That said,
http://cvs.sourceforge.net/viewcvs.py/rdesktop/rdesktop/configure.ac?
On Sun, 2005-04-03 at 22:19 +0200, Paul J Stevens wrote:
Geo Carncross wrote:
On Thu, 2005-03-31 at 09:25 +0200, Paul J Stevens wrote:
I'm not sure I understand what you mean by 'unsolicited updates'. Would
that be
like EXAMINE/SELECT or more like STATUS?
[..]
7.2.6. FLAGS
On Fri, 2005-04-01 at 20:19 +0200, Paul J Stevens wrote:
Geo Carncross wrote:
On Thu, 2005-03-31 at 18:45 +0200, Paul J Stevens wrote:
Geo Carncross wrote:
Be careful doing non-atomic things during signals. Since the signal will
likely have to write to a fifo anyway, it may be better
On Thu, 2005-03-31 at 09:19 +0200, Paul J Stevens wrote:
Wolfram A. Kraushaar wrote:
Is it handled through database triggers.
If not, what is the meachnism used to inform the clients
about a new
message, deleted message or message state chage.
DBMail doesn't support IDLE [yet?]
On Thu, 2005-03-31 at 18:45 +0200, Paul J Stevens wrote:
Geo Carncross wrote:
Be careful doing non-atomic things during signals. Since the signal will
likely have to write to a fifo anyway, it may be better to simply select
() on that fifo in the first-place...
SELECT mtime FROM
1 - 100 of 145 matches
Mail list logo
