The folders probably are cached in the client.
Smart clients do that
and don't check very often, since checking can be painfully slow.
Arnt
What a glorious search. Does that client perhaps repeat the same search
every 30 seconds?
Arnt
Hi Marin,
I haven't tested the patch below yet... and I'm a bit uncertain about the
first if(). It will do the right thing in principle but does it produce
correct SQL syntax? I'll try to test tonight or tomorrow night, if you
can't do it sooner.
Arnt
diff --git a/server/selector.cpp b/serv
Hi Martin,
I know why I didn't like that first clause and felt unsure about the
syntax: My usual preference would be to put these two tests in simplify(),
not whereSet().
Arnt
The IMAP client sends 1:*, so the "true" test should match. Nothing is
going to beat the performance of true.
Not sure about unnest, I will
leave that to Abhijit. He is a pg committee, I am a fumbler.
Arnt
NSS Ltd writes:
I've also been looking at other uses of 'any' since I think they may
require changed too for performance (and to be consistent) but Arnt may
be better to say if this is the case. I'm making a patch set with those
changed too.
Postgres has two parsers, one for SQL and one for va
It should just work, and I believe the configuration is very similar to
that offered by dovecot.
What are your public folders called, and what
are their ACLs?
Arnt
I expect that is indeed the problem. Set '' rights on /users instead of
on /, then people can see /technical and the block on /users will make
other users invisible by default.
Arnt
I think so, yes. But right now my head is full of a bug and a call
stack, so I might be unreliable.
Arnt
Martin Rode writes:
Arnt,
the problem with the long "ANY" clauses (2.8MB worth of Array
values), is NOT the parsing time in the Postgresql server,
whether it is the value or SQL parser.
The problem is the execution time. If we use UNNEST or the
VALUES syntax, Postgres uses something like a
Well, I do not think so. Because I do not understand why unnest does
what it does, and I am not the kind of programmer who blindly
implements "this one weird trick that makes postgres 260 times faster"
from SO or a blog. I want to know what happens, and why, and often
enough that sort of extra
There was a bug... I think younger treated its argument as seconds
instead of days. Try that. -n first of course to see whether the result
matches your expectations.
Arnt
Great.
You sent mail to -request, not to the list.
I do not remember
precisely when the key is generated; it may happen dynamically when
first needed. Try to connect to port 993 with s_client?
Arnt
Can't tell where it went from what you write. But if you look at the
database it should be easy:
select name, uidnext from mailboxes order by uidnext desc;
The surprising mailbox near the top of the list is where.
Arnt
Hi,
I've changed my mind about the retention policies. They very flexible and
powerful and so on, but aren't really useful/usable. May also not work, but
that's a philosophical point (if "correct" isn't usable, what worth is
"correct"?). Instead I want to do the gmail thing instead, which for
Stephen R. van den Berg writes:
Meaning that all mailboxes can be tagged as being part of the "Trash"
group?
That's a question of implementation, which is simple either way, but...
What do you want to achieve?
Arnt
Stephen R. van den Berg writes:
Nothing convoluted, it's just that the folders that should be part of the
trash group can have various names (depending on mailclient and/or locale),
so there should be a flexible way to mark them as such.
Oh, right. Yes, RFC6154 says how to mark them.
Arnt
Klaus Thorn writes:
What can I do to stop the connections being closed?
...
__configuration:
memory-limit is at the default value of 64 (MB).
Increase that to 256 or so.
Arnt
Klaus Thorn writes:
Dear Arnt, thanks!
Is this trial and error or is it known to work?
A mixture. Mostly the latter in this case, but in other cases it could be
more trial and error.
I suggest to clarify on http://archiveopteryx.org/conf/memory-limit that
memory-limit does not only switch
Tino de Bruijn writes:
What is going and how can I prevent it from doing this?
11G is a clear bug. There's a variable, memory-limit, and you should see up
to a few times that at peak, returning down to memory-limit. What version,
and what value of memory-limit?
Bugs have a tendency to be re
OVi C writes:
I have a lot of messages in INBOX that doesn't show after
changing sort order (by date, by size, etc) and getting and
error on the horde interface .
Looks like a syntax error in Horde.
I've attached the imap log between horde aplication and the imap server.
C: 5 UID SORT (SUBJ
Stephen R. van den Berg writes:
Ever since I upgraded several systems here to the version of
aox from around June 24th: f98b6d3b95f5909f7cba898ae8b1836de69fee3c
I'm having the wierd effect that messages being marked as Seen, then
silently revert back to unseen (a lot, but not always).
Running tc
Axel Rau writes:
I observe this mostly after some network problem with long
running connections.
Has it to do with TCP error handling?
Could some kind of (TCP) keep alive improve the diagnosis of
'guilty connection‘?
My general plan is to kill a) the connection that was probably disturbed by
I know how to fix it properly then.
Arnt
It will be in IMAP/handlers/select.cpp, where Thunderbird asks for
'fetch flags' for some/all messages with modseq above the specified
limit. Will look at it.
Arnt
I have found and fixed this. Will reread the patch, commit and push
when I have slept.
Arnt
Harri Porten writes:
Fellow users,
the git.aox.org listed at
http://archiveopteryx.org/git-repository
is known to be down perhaps?
Well, no, it wasn't. It's been broken forever, in a theoretical sort of
way, and didn't come up after a nasty crash. Fixed a few weeks ago. Thanks
for the not
I have looked at this bug too and see nothing. But I added a patch
nonetheless. Hope it helps.
Arnt
Oh, that looks nasty.
Do you know the score of the problem? Merely
unsolicited untagged OK, or do other unsolicited responses also bother
nginx?
Aox sends them in quite a few circumstances. Each of them may
be rare, but they add up. For example, a server shutdown is announced
using an unsol
I wrote:
Do you know the score of the problem?
I meant the scope, of course, and blame the phone.
Arnt
I think the best way to fix this is to not send that OK. Will
commit.
Arnt
OVi C writes:
Here's is the answer from the horde developers regarding the issue:
There are two bugs, AFAICT.
1. Horde is sending a command the RFC forbids ("MUST NOT" means forbidden).
2. When aox receives this illegal command, it sends the wrong error
message.
Arnt
I wrote:
There are two bugs, AFAICT.
No. Horde is right. Will fix.
Arnt
Patch for testing attached.
OVi C writes:
Here's is the answer from the horde developers regarding the issue:
"From RFC 6855:
Once an IMAP client has enabled UTF-8 support with the "ENABLE
UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
contains a charset specification
OVi C writes:
Hi again.
I've applied the patch and it's working. Thank you very much.
I'll commit it then. Thanks.
Bit harsh to call this behavious broken; the code as it was complied with
all four relevant published RFCs. I'll raise the issue in the IETF. That
erratum has to be amended.
A
I am not familiar with it either... does aox use some system feature I
do not know?
Arnt
Mark Felder answers Chris Watson:
Any thoughts? Ideas? Ways to debug wtf is going on to invalidate the pgp
signature?
Exactly which version of aox are you running? PGP has been broken in aox
storage for a long time, but was fixed and has not yet been in a
"release".
https://github.com/aox/aox/
OVi C writes:
Here's is the answer from the horde developers regarding the issue:
...
Oh, and since we're using SORT and not SEARCH, from the RFC's errata:
This also
applies to any IMAP command or extension that includes a charset
label and associated strings in the command arguments.
Axel Rau writes:
Often aox stop leaves a child in SELECT wait around.
Does this still happen after my timeout-related changes in January?
Arnt
FWIW I did not write that code, Axel Rau and Herrmann Gundel did.
Arnt
Do you think you could get me a protocol recording spanning the time
when it goes wrong? It will be several IMAP connections.
I do not need
the responses, only the commands. At least so I think.
Arnt
Oh, aox can log that, I am fairly sure tb can, and wireshark can open
TLS if you give it the server cert and private key.
Arnt
I've just seen this issue, and I think I'll be able to reproduce and debug
it. Will try this weekend.
Arnt
I have looked at this several times now and cannot understand what it
may be. Please try to correlate the aox and exim looks next time it
happens.
Arnt
Hi,
why did you use the UUID type and a column instead of constructing a UUID
at read time based on mailboxes.id and mailboxes.uidvalidity?
Arnt
Stephen R. van den Berg writes:
The common way to solve this which does not cost extra database space
would be to store a unique but permanent identifier per aox instance,
and then use a one-way-hash (e.g. MD5) to make your UUIDs difficult
to guess (it only needs to fill in part of the UUID this
GP writes:
I could help if help is needed to bring the site up to date .
It would let people see that project is active and working .
Do you care? I don't.
What we have here is selfhosted mail software. That's not mainstream now.
We're in the age of hosted email. You personally use hosted em
GP writes:
I like your software and it's true that it's gotten into the hosted mail era
so it doesn't have the recognition it deserves, but never the
less it's still very useful to some folks myself included.
I apologise if my tone was bad.
So thank you for building it, even if it's not mai
Axel Rau writes:
Arnt did not honor the pull request until now, which may have to do with
architectural concerns.
Axel's second pull request seems intuitively too complex for the problem...
I believe that a solution should not be more complex than the problem, and
that PR makes me feel uncomf
NSS Ltd writes:
In short, AOX looks to me like the sort of IMAP server that people
should be considering, especially if they want an open source stack and
the advantage of database backed storage on a database which can scale
and supports things like online backup and replication.
I think peopl
NSS Ltd writes:
I took a look through the debug logs from my recently updated server and
I see there are also errors being generated for a legitimate UNSELECT
command. AOX is complaining a mailbox is not specified when this
command does not use a mailbox.
Uhm, no? Aox complains about unselect
NSS Ltd writes:
I'll look at this further - I'll admit I was not so sure of the patch
but worked on the basis Thunderbird was mature enough to be well behaved
and not issue bad commands and that looks to have been a wrong assumption.
Thunderbird's philosophy seems to be that the occasional erro
my...@mware.ca writes:
I just want the software to keep working and be maintained,
hopefully to the same standards it was developed under.
To some degree you may trust that. Not the same promptness, but the code
that goes in will not be rubbish. My concern for its qualiy is such that I
have j
Hi,
that should work when Postfix retries.
When aox sees that a transaction is taking unreasonably long, it runs a
query on another connection to spot any locking problems, and that query
looks at pg_stat_activity.current_query, which I suppose the postgres
maintainers may have renamed. What
Even simpler: increase memory-limit in arciveopteryx.conf and
restart.
Arnt
I forgot to mention the “why” question: We believe that software should take
its design seriously. Lots of software make a quick exception from its general
design, or its general UI, or ignore configuration variables sometimes. Each
such thing requires a good exception.
Accepting a very large m
The problem is somewhere inside EString::fromNumber(), not in qresync, and
changing the optmisation flags makes the problem go away. I'm not sure how
to attack that.
Arnt
Tom Ivar Helbekkmo writes:
Ouch! Those bugs are a pain. I just tried compiling estring.cpp (and,
for good measure, estringlist.cpp) with -O0, but that didn't make any
difference...?
I don't remember whether I changed from -O0 to -O3 or the other way (I've
been AFK for a month, and what I did
Tom Ivar Helbekkmo writes:
Actually, I guess that's pretty good -- it indicates that this isn't an
optimization problem after all, right?
I also have a debian box where it doesn't occur and one where it occurs
depending on compiler switches. Now I know it happens on netbsd always. So
it might
Yes, Dovecot is really fast so long as you do what it expects. You can
construct IMAP requests it handles slowly, but most (all?) of the common
requests are ones it's been optimized for and will handle really fast.
Arnt
NSS Ltd writes:
Next bit is to see why modseq is -1 at all, but if you can try with this
patch, I think you may end up with a more benign situation (but possible
big table updates with modseq>-1). It is possible -1 is valid but Arnt
is the one to confirm there. It's also possible something to d
NSS Ltd writes:
Arnt, any idea why the modseq value becomes -1 ? Hints will same me
time tracking it.
Fixed, I expect.
Aox generally uses a 'nextmodseq', ie. the next value of modseq to be
assigned, while IMAP uses 'highestmodseq', which is either the highest
modseq of any existing message
Axel Rau writes:
Could those bugs be related, which happen several per a day
with long running IMAP clients?
?Error while connecting to IMAP server and reading root folder,
because: EOF occurred in violation of protocol (_ssl.c:645)
Unlikely.
This change affects negotiation; the server refu
Abhijit will reread and then we can discuss it.
I remain unhappy about
the clarity of the code. But since I am clearly not going to write a
more lucid alternative myself, we will have to either accept the patch
or roll back the first patch. Abhijit?
Arnt
Carlos Hanson writes:
It's coming from GMail via routing through SMTP. It is not
using IMAP to check a mailbox. I don't think labels are
available during the SMTP process.
No, but an import/export process from gmail can/will result in multiple
"copies" of a message in aoxexport. You start wit
Axel, can you try this? Seems like a %#$%$ obvious bug.
Arnt
diff --git a/server/tlsthread.cpp b/server/tlsthread.cpp
index e25ed6b..8e05547 100644
--- a/server/tlsthread.cpp
+++ b/server/tlsthread.cpp
@@ -352,7 +352,7 @@ void TlsThread::start()
tv.tv_usec = 0;
}
-
EOF is not really a bug, more of a wilful RFC deviation. I cannot say
anything about the refused connections, except that if they are really
refused connections then that is definitely not an SSL issue.
Arnt
Tom Ivar Helbekkmo writes:
Still have the spool files held -- and available for fetching from
https://www.hamartun.priv.no/tih/sdiy.spool.tar.gz if anyone would like
to take a look. This is with aox built from git, with commits up to and
including September 19th, 2016.
Axel had fixed that alre
If you use num-servers larger than 1, then the loop involved is not
that much larger than a signal handler would be, so adding that would
be a considerable increase in complexity.
Arnt
Mark Felder writes:
What is causing this? imapsync, postgres, or aox?
If a client (IMAP in this case, but also SMTP) does something that
would/might cause aox to go over its configured memory-limit, then aox
pushes back using error messages like that.
Bump memory-limit and/or change the sci
On Thursday 31 May 2018 21:38:58 CEST, ja...@mansionfamily.plus.com wrote:
Is this trying to tell me:
- it doesn't work on 10.x, or
- the way it does the check is a bit broken
?
OK I could check the latter - but the former is a straight question.
It ought to work. I'm surprised the check br
I looked at it, briefly, and saw no signs that they really understand why
people use those silos. I don't understand much myself, but I understand a
little, I believe the developers at those silos understand a great deal
more, and anyone going up against them should match their understanding.
Merged around 2007. Git blame the lmtp/smtp server for details. Set
memory-limit to 7× the message size limit you want.
Arnt
Fixed that.
Message size and caching are the two major areas. The rest
is detail. I mean, it also limits password length and more, but it will
hardly be the limiting factor there.
Arnt
On Monday 5 August 2019 21:34:35 CEST, Gerd Flaig wrote:
Hi,
are there any plans to make a release including the fixed Postgres
version check?
No plans, but more for lack of interst than lack of will.
The NixOS definition is based on 3.2.0 which appears to be the most
recent release. I could
I expect we will speak.
My own opinion is that your flag fix goes in,
qresync is disabled by not advertising it, and we stop sending
References fields on DSNs. That's it.
(qresync may be the reason for
the occasional problems with Apple Mail.)
Arnt
On Thursday 12 December 2019 17:24:40 CET, Mark Felder wrote:
Ahh, good catch. I forgot it chroots. I'm already running it in
a FreeBSD jail, so this is kind of pointless but I can easily
work around this. I guess I'll have to ensure syslog's socket is
in there too. I wonder how many people are
On Tuesday 1 June 2021 17:11:28 CEST, Benjamin Yates wrote:
I finally captured one. The last column having length -1 is
rather curious, but maybe it has valid meaning in the protocol.
Abhijit, do you know or can you find out?
Arnt
Myke G writes:
maillog:Feb 21 16:07:14 Vice postfix/qmgr[81686]: 1528956445:
from=, size=3463, nrcpt=1 (queue active)
Is this a bug, and if so, Postfix, or AOX? Or an interaction?
Shall we say... Cyrus imapd?
Cyrus has a habit of mangling garbage fields like
To: Gérardpe...@mailaccount.ca
my...@mware.ca writes:
It looks to me like AOX isn't handling it properly.
Abhijit told me the logfile isn't accurate; the ? displayed is really
some other character.
What do you consider proper handling of an SMTP command such as this?
MAIL FROM:
... My softbounces are off, I don't see
Arnt Gulbrandsen writes:
What do you consider proper handling of an SMTP command such as this?
MAIL FROM:
I suppose we could say that if MAIL FROM is irretrievably bad, we accept
the message, but store it as though to came from <>.
I'm not sure that's at all proper, o
Stephen R. van den Berg writes:
Is there a good reason for not allowing aliases to be attached to
multiple mailboxes?
The aliases table is also used to locate the inbox for a given user, and
IMAP semantics demand that there be exactly one inbox for each user.
I expect that doesn't apply to t
Stephen R. van den Berg writes:
When looking at the current definition of the addresses table, the
following questions come up:
- I notice that the ald index uses lower() on both localpart and domain,
but that the addresses_nld_key unique index only lowers the domain
part, yet keeps case f
Stephen R. van den Berg writes:
Stephen R. van den Berg wrote:
When looking at the current definition of the addresses table, the
following questions come up:
Forgot one:
- Is there a particular reason why the columns in addresses_nld_key are
in this order?
Not really.
I ask, because r
Arnt Gulbrandsen writes:
Stephen R. van den Berg writes:
Is there a good reason for not allowing aliases to be attached to
multiple mailboxes?
The aliases table is also used to locate the inbox for a given user,
and IMAP semantics demand that there be exactly one inbox for each
user.
I
My answer from last night was incorrect. Sorry.
The users.alias column refers to ONE aliases row. You want to allow
several aliases rows to have the same address column: Fine. No bother.
Nothing wil break, since users.alias refers to one of them, not to all.
The schema is written in the textb
Stephen R. van den Berg writes:
> In deliver.cpp I find the following query:
>
> select al.mailbox, n.name as namespace, u.login
> from aliases al
> join addresses a on (al.address=a.id)
> left join users u on (al.id=u.alias)
> left join namespaces n on (u.parentspace=n.id)
> where (lower(a.localpa
Let me guess, your password contains ß or ä and the roundcube developers do not
use such passwords and never tested that case?
--
Viele Grüße
Arnt Gulbrandsen
Hm. Next try: is it conveivable that the password as sent by roundcube ends
with some extra whitespace? Such as a CR or LF?
--
Viele Grüße
Arnt Gulbrandsen
r. If there IS an
error, it often helps to site what it is.
The segfault must be something else. See if you can get a stack trace?
--
Viele Grüße
Arnt Gulbrandsen
I wrote:
So we write...
So we wrote
If there IS an error, it often helps to site what it is.
To show what it is. Swype may be a fine thing, but it could be improved.
The segfault must be something else. See if you can get a stack trace?
That still stands.
Arnt
On 04/13/2011 02:34 PM, Stephen R. van den Berg wrote:
But, as it seems, the problem still happens in the original version.
Stupid design choice on part of either Abhijit or myself, or both.
Here goes:
Program received signal SIGSEGV, Segmentation fault.
Mailbox::name (this=0x0) at server/ma
On 04/19/2011 03:12 PM, Stephen R. van den Berg wrote:
The workaround seems to be to create the mailboxes first, then wait
a certain amount of time, then try to fill them.
Yes, that's the workaround.
The problem is specific to inboxes, though.
I've looked, but still can't see any way in which
On 04/19/2011 01:33 AM, Stephen R. van den Berg wrote:
mailboxes:
495 | /users/x...@foo.bar/INBOX | 243 | 1 | 1 | 1 | 1 | f
So not deleted or anything... all straightforward.
That mailbox should have been created by an "insert into mailboxes"
within some transaction, and the transaction
On 04/20/2011 02:18 AM, Stephen R. van den Berg wrote:
In the order of milliseconds.
I run a:
aox add user "$user" "$password" "$alias"
Immediately followed by a:
mailsync -f $cf -M migrate
I've run more than a few commands like that. Can you look at the log?
The transaction
On 04/22/2011 12:34 AM, Stephen R. van den Berg wrote:
It would be helpful if the subsequent LOGIN wouldn't segfault, and would
simply return a temporary error, or would wait for a few moments, then retry.
This bug opens up a small window of opportunity to crash any aox
server right after a user
On 04/23/2011 03:21 PM, Stephen R. van den Berg wrote:
As far as I can tell, aox doesn't care if you have PostgreSQL 8.3, 8.4 or 9.0.
True, but some pg searches grew faster. I'd take 8.4 over 8.3. Never
looked at 9.0, but I imagine it's a fine reliable database.
I'd upgrade aox first, then s
On 04/24/2011 10:13 PM, James Mansion wrote:
Arnt Gulbrandsen wrote:
I'd upgrade aox first, then see whether there's any reason to upgrade
any of the other jigsaw puzzles.
Ah. That's a shame. I went with the PostgreSQL upgrade first, because I
want it for other things too.
Th
I think I found the bug. Please test this patch (which is a patch in the
true sense of the word).
When the mailboxes table is updated, the running server(s) receive a pg
LISTEN/NOTIFY signal. But aox has a rate limiter. It doesn't pick up
changes more often than every third seconds.
So if yo
1 - 100 of 324 matches
Mail list logo
