My interpretation of unsolicited responses was like the example Arnt gives. Meaning
that if the server has something extra info to report it will sent a seperate untagged
response with that info. I didn't understood that it will stuff it into the same
untagged response line containing the data a
On Fri, 16 Jan 2004, Christof Drescher wrote:
> Given a session where msn 8 has flags \Recent and \Deleted set, and a new
> mail arrives (msn 9), also having \Recent set. One client is connected, but
> waiting (non-IDLE), a second client issues EXPUNGE.
>
> Now when the first client sends its next
Hi,
I have a small q questions what behavior is more desireable to a server
response sequence, which may affect client handling:
Given a session where msn 8 has flags \Recent and \Deleted set, and a new
mail arrives (msn 9), also having \Recent set. One client is connected, but
waiting (non-IDLE),
At 2004-01-16 11:33:31 +0100, [EMAIL PROTECTED] wrote:
>
> But now I've got recursive Rules and I'm not shure if I can reproduce
> them using constants respectively in Regular Expressions.
Which "recursive rules" are you talking about?
> So those who had the same Problem parsing the incoming requ
It looks like the PAM includes are not installed on your system. Look for
a Suse package that would install a PAM development environment.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
per hygum writes:
I think this is a IMAP server bug ?
I think the same command must always give the same response.
It's not a bug, and in IMAP, you can often get extra data. For example,
one easy way to check for new mail is by doing nothing:
a noop
a ok
b noop
* 17 exists
b ok
Arnt
On Fri, 16 Jan 2004, Andreas Aardal Hanssen wrote:
> It's compliant with IMAP.
Indeed it is compliant, and it's necessary for the reasons that Andreas
and Timo gave. But there's another point.
Even if there was no reason for the server to have sent extra data, it is
*always* compliant for the se
On 15 Jan 2004 at 10:12, Mark Crispin wrote:
> On Thu, 15 Jan 2004, Benedict White wrote:
> > /bin/sh: line 1: tools/an: Permission denied
>
> The problem is that the imap-2002e/tools/an shell script needs to be
> executable and it is not. It is executable (protection 775) in the UW
> distributi
On Fri, 2004-01-16 at 13:18, per hygum wrote:
> Client->Server: 6 FETCH 19 (UID RFC822.SIZE BODY[]<0.4967>)
>
> Client<-Server: "I get the data back I request BUT also additional
> data. This is 'FLAGS (\Recent \Seen)' data". It is contained in the
> same untagged response and not in a seperat
On Fri, 16 Jan 2004, per hygum wrote:
>What I do in "pseudo" description:
> Client->Server: 6 FETCH 19 (UID RFC822.SIZE BODY[]<0.4967>)
> Client<-Server: "I get the data back I request BUT also additional
> data. This is 'FLAGS (\Recent \Seen)' data". It is contained in the
> same untagged response
Hi,
What I do in "pseudo" description:
Client->Server: 6 FETCH 19 (UID RFC822.SIZE BODY[]<0.4967>)
Client<-Server: "I get the data back I request BUT also additional
data. This is 'FLAGS (\Recent \Seen)' data". It is contained in the
same untagged response and not in a seperate untagged resp
Hello,
I'm trying to parse incoming Client Requests but I'm not shure if I'm running
into a one way.
That was the Idea:
I wanted to translate the Formal Syntax into Regular Expressions to parse
them.
I've built constants for every rule (not finished) and it seemed to work
for the easier ones
12 matches
Mail list logo
