Imap strange behavior when fetch UIDS greater than - imap

I try to get uids from imap server which are greater than specific uid in Inbox folder.
The query looks like:
UID SEARCH UID 13780:*
Response:
* SEARCH 13779
aaaj OK UID SEARCH Completed.
Why does it return UID 13779 ? It less than 13780!
Then I send email and the response is the following:
* SEARCH 13779
* 5 EXISTS
* 4 RECENT
aaak OK UID SEARCH Completed.
And after next request the response is the following:
* SEARCH 13780
aaal OK UID SEARCH Completed.
Why does it happens so ?
During all requests I keep session opened.
Why it returned lower uid I have understood, because max uid was lower than requested uid. But why does it returns first time this one:
* 5 EXISTS
* 4 RECENT
And then:
* SEARCH 13780
aaal OK UID SEARCH Completed.
So 13780 is needed information in my case, can I get it at once ? Without EXISTS and RECENT in first query ?

UID SEARCH UID 13780:* does not mean "all UIDs greater than or equal to 13780". It means "all UIDs between 13780 and the largest UID in the mailbox". That is, the * is internally replaced with the current largest UID.
If the current largest UID is 13779, then the command is parsed to UID SEARCH UID 13780:13779, which is equivalent to UID SEARCH UID 13779:13780, as by specification ranges m:n and n:m are equivalent.
Therefore, you always get the largest UID in the mailbox.

Related

grafana-influxdb get multiple rows for last timestamp

I am using telegraf-influxdb-grafana together. But I could not get rows for only last timestamp.
Here is what I am doing;
Collecting DB statistics(Running queries at that time) with Telegraf(exec plugin).
Storing output to influxdb
Trying to monitor running queries over grafana
But I need to get all rows at last timestamp.
Here is what I've tried;
> select * from postgresql_running_queries where time=(select max(time) from postgresql_running_queries)
ERR: error parsing query: found SELECT, expected identifier, string, number, bool at line 1, char 54
Here is what I want to see;
Time DB USER STATE QUERY
2017-06-06 14:25.00 mydb myuser active my_query
2017-06-06 14:25.00 mydb myuser idle in transaction my_query2
2017-06-06 14:25.00 mydb2 myuser2 active my_query3
Can any one help me to achive this?
I am open to any solution.
select last(fieldname) from measurment_name;
Query in this format will return last timestamp data from the InfluxDB.
But I am surprised with the fact that you are expecting 3 values for a single timestamp (unless you have different TAG values, refer this documentation how to store duplicate points). You will a ONLY ONE record for a given timestamp. InfluxDB overwrites previous content if there is another entry for same timestamp, here is why.
Your results will be something like (if you don't have different TAG value):
Time DB USER STATE QUERY
2017-06-06 14:25.00 mydb2 myuser2 active my_query3
EDIT:
Based on comment, my guess is you are using TAGs to differentiate, still above query should work, if not, you may try by adding WHERE clause.

May I shuffle the order of the e-mails in a response for a FETCH command?

If the client does a FETCH with a range of sequence numbers, must the server response give each e-mail in ascending sequence number order?
The RFC3501 contains the following example of a FETCH command.
C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A654 OK FETCH completed
Would the following example represent a compliant server?
C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 3 FETCH ....
S: * 4 FETCH ....
S: * 2 FETCH ....
S: A654 OK FETCH completed
I could not find nothing in the sections for FETCH request and FETCH response regarding the order of the response.
You can reorder as much as you want. The paragraph Paurian quotes applies to UID assignment, not to reporting.
It's also safe in practice: Symantec's IMAP proxy (I forget its name, but its job is to scan for naughty attachments and present a santised view of the world to IMAP clients) sends fetch responses in an unpredictable order, and the main developer knows about no problems resulting from that.
From what I understand, No. The sequence must be in order. [See comments, below - as the specs mention storage, not retrieval of order.]
2.3.1.1. Unique Identifier (UID) Message Attribute
A 32-bit value assigned to each message, which when used with the
unique identifier validity value (see below) forms a 64-bit value
that MUST NOT refer to any other message in the mailbox or any
subsequent mailbox with the same name forever. Unique identifiers
are assigned in a strictly ascending fashion in the mailbox; as each
message is added to the mailbox it is assigned a higher UID than the
message(s) which were added previously. Unlike message sequence
numbers, unique identifiers are not necessarily contiguous.
Since these are sequence numbers, the result must be contiguous.
Articld 6.4.8. implies that FETCH without the UID prefix indicates a sequence search rather than a unique identifier within your range expression:
... the UID command (variant) takes a SEARCH command with
SEARCH command arguments. The interpretation of the arguments is
the same as with SEARCH; however, the numbers returned in a SEARCH
response for a UID SEARCH command are unique identifiers instead
Source: https://www.rfc-editor.org/rfc/rfc3501

Is the IMAP UID always numeric?

Is the IMAP UID guaranteed numeric? I've read the part in RFC3501 and it says:
Unique identifiers
are assigned in a strictly ascending fashion in the mailbox; as each
message is added to the mailbox it is assigned a higher UID than the
message(s) which were added previously.
But could it be that the UID has a pre- or postfix? For example, could it be that the UID is mail_14 and the next msg mail_15?
Answer: IMAP UID is a unique nonzero integer.
You might want to read the part in RFC3501 that defines the UID:
uniqueid = nz-number
; Strictly ascending
Page 91.

YQL sample query returns max 260 results

I am following YQL sample query
select * from local.search(500) where query="sushi" and location="san francisco, ca"
but I get 260 max count instead of 500. I tried also to use limit 500 after 'where' and different keywords, always get maximum 260 results. How do you increase it?
The underlying API that the local.search table uses (Yahoo! Local Search Web Service) has restrictions on the number of results returned.
The results parameter (the number of results "per page") has a maximum value of 20.
The start parameter (the offset at which to start) has a maximum value of 250.
Since you ask for the first 500 results, YQL makes multiple queries against the Local Search API returning 20 results at a time. Therefore the start values are 1, 21, 41, ... 241. This brings back 260 results, as you have seen.
Since the YQL query asks for more results, the next start value is tried (261) which is beyond the allowed range so the underlying service returns an error (with the message "invalid value: start (261) must be between 1 and 250"). If you turn on "diagnostics" in the YQL console, you will see the "Bad Request" being returned.
Nothing you do to the query will bring back more results than the underlying service allows.
I figured out, I was missing paging number, so 0++ will work
select * from local.search(0,500) where query="sushi" and location="san francisco, ca"

IMAP batch fetch text part of messages

I'd like to download the text (that is mime type text/plain, text/html text/richtext) from UID x to UID y.
I have the UID's (and not mailbox IDs).
How can I do something like
FETCH 412444:412500 (BODY.PEEK[TEXT/PLAIN OR TEXT/HTML OR TEXT/RICHTEXT])
Thanks!
After checking RFC3501, the UID command (section 6.4.8) seems to be able to do part of this:
The UID command has two forms. In the first form, it takes as its
arguments a COPY, FETCH, or STORE command with arguments
appropriate for the associated command. However, the numbers in
the sequence set argument are unique identifiers instead of
message sequence numbers. Sequence set ranges are permitted, but
there is no guarantee that unique identifiers will be contiguous.
Thus, you should be able to call:
UID FETCH 412444:412500 (BODY.PEEK[TEXT/PLAIN OR TEXT/HTML OR TEXT/RICHTEXT])

Resources