Oggi Vi mostreremo tutte le parole chiave che potrete utilizzare per fare le ricerche in Zimbra.
Possiamo dividere le parole chiave in queste categorie:
– Struttura della ricerca
– Chiavi di ricerca multiple
– Utilizzare l’asterisco (*) come jolly per la ricerca
– Parole chiave
– Ricerca nei campi dell’header
– Elenco dei parametri di ricerca
SUGGERIMENTO: È possibile impostare dalle opzioni generali “Mostra sempre stringa di ricerca” per vedere la query corrente nella barra di ricerca.
Ad esempio, quando questa opzione è impostata, cliccando sulla cartella “Posta in arrivo” mostrerà la query “in:inbox“
Struttura della ricerca
Le ricerche semplici possono essere eseguite semplicemente inserendo una parola nel campo di ricerca.
Questo tipo di ricerca è interpretata come ricerca del testo nell’intera mail, equivalente alla ricerca con questa parola chiave: “content:”
Le ricerche avanzate possono essere eseguite specificando un operatore di ricerca.
Un operatore di ricerca non è altro che una parola chiave speciale seguita da “due punti” (:), seguiti a sua volta da un parametro specifico di quell’operatore. Per esempio:
in:inbox = l’operatore è “in” e il parametro è “inbox” (questa ricerca restituisce tutte le mail che si trovano nella cartella “posta in arrivo“)
da:user@domain.com = l’operatore è “from” e il parametro è “user@domain.com” (questa ricerca restituisce tutte le mail che ricevuta da user@domain.com)
È possibile far precedere qualsiasi parola chiave con la parola “not” per specificare gli elementi che non hanno tale criterio, ad esempio, not in:inbox
Il segno “meno” (-) è sinonimo di not quindi: not in:inbox è equivalente a -in:inbox
La ricerca è case insensitive, quindi significa che “in:inbox” è equivalente a “in:Inbox“
Nella maggior parte dei casi non è necessario includere i caratteri di punteggiatura nella stringa di ricerca, in quanto questi sono ignorati dalla query di ricerca.
Ci sono certi casi in cui i caratteri di punteggiatura sono necessari e in quei casi si deve racchiudere il carattere di ricerca tra virgolette. Ad esempio subject”09:30″ restituirà tutte le mail che contengono la stringa “9:30” nell’oggetto.
I seguenti caratteri non possono essere usati nella ricerca a meno che non siano racchiusi tra virgolette: ~ ‘ ! # $ % ^ & * ( ) _ ? / { }[ ] ; :
I seguenti caratteri sono consentiti nella ricerca, purché non siano il primo carattere: – + < >
Chiavi di ricerca multiple
Se si immettono più termini di ricerca (separati da spazi) vengono collegati di default attraverso un “AND“.
in:inbox ilger = questa ricerca restituisce tutte le mail che si trovano nella cartella “posta in arrivo” e che contengono la parola “ilger” nel testo della mail.
Per le ricerche che utilizzano criteri multipli, è possibile trovare le mail che corrispondono a uno dei criteri specificati o tutti loro. È possibile eseguire entrambi i tipi di ricerca utilizzando rispettivamente “OR” o “AND“
Per tutti i riquadri di ricerca diversi dalla ricerca di base, le regole sono:
Ricerca di messaggi che soddisfano almeno uno dei qualsiasi criteri specificati si chiama ricerca di un “OR“, perché se la mail contiene X o Y allora è considerata una corrispondenza.
Ricerca di messaggi che soddisfano tutti i criteri specificati si chiama ricerca di un “AND“, perché deve contenere sia X sia Y per poter essere considerata una corrispondenza.
SUGGERIMENTO: Per facilitare la concatenazione di AND e di OR è possibile utilizzare le parentesi, dato i termini all’interno di esse sono considerate come unità. Per esempio:
content:(ilger zimbra) è equivalente a content:ilger AND content:zimbra.
content:(ilger or zimbra) è equivalente a content:ilger OR content:zimbra.
Utilizzare l’asterisco (*) come jolly per la ricerca
L’asterisco (*) può essere utilizzato come carattere jolly in una ricerca per trovare il contenuto delle parole che non ricordiamo o conosciamo in modo completo. Esso si deve utilizzare dopo il prefisso.
ilger* = cerca tutte le parole con “ilger” più una qualsiasi altra serie di caratteri ( ad esempio ilger.com , ilger.it , ilger.email, ecc )
Parole chiave
content: specifica il testo che la mail deve contenere. Ad esempio content:ilger trova tutte le mail che contengono la parola “ilger”
from: specifica il mittente, cioè l’indirizzo mail che si trova nell’intestazione “Da“. Questo può essere usato per nome visualizzato from”Supporto ilger.com”, per indirizzo email from:supporto@ilger.com o per dominio from:ilger.com
to: specifica il destinatario, cioè l’indirizzo mail che si trova nell’intestazione “A“. Può essere usato come il “from”
cc: specifica la mail che si trova in copia, cioè l’indirizzo mail che si trova nell’intestazione “Cc“. Può essere usato come il “from”
toccme: specifica il destinatario o la mail che si trova in copia, cioè gli indirizzi nell’intestazione “A” e “Cc“. Può essere usato come il “from”
subjet: specifica il testo che deve apparire nell’intestazione dell’oggetto del messaggio. Ad esempio subjet:ilger trova tutte le mail che hanno la parola “ilger” nell’oggeto
in: specifica una cartella. Ad esempio in:inbox trova tutte le mail che si trovano nella cartella “Posta in arrivo”
under: specifica una cartella con le relative sottocartelle. Ad esempio under:inbox trova tutte le mail che si trovano nella cartella “Posta in arrivo” e tutte le sue sottocartelle
has: specifica un attributo che il messaggio deve avere. I tipi di oggetto che è possibile specificare sono “allegato”, “telefono” o “URL”. Ad esempio has:attachment trova tuttle mail che contengono uno o più allegati di qualsiasi tipo
filename: specifica un nome di un file allegato. Ad esempio filename:query.txt trova tutte le mail con un file allegato chiamato “query.txt”
type: specifica un tipo specificato di allegati. I tipi di allegato che è possibile specificare sono “text”, “word”, “excel” e “pdf”. Ad esempio type:pdf trova tutte le mail con allegati che sono documenti in PDF
attachment: specifica un certo tipo di allegato. Ad esempio attachment:word trova tutte le mail con allegati Word
is: specifica un determinato stato. Ad esempio is:unread trova tutte le mail non lette. I valori consentiti sono: “unread”, “read”, “flagged”, “unflagged”, “sent”, “draft”, “received”, “replied”, “unreplied”, “forwarded”, unforwarded”, “anywhere”, “remote” (in una cartella condivisa), “local”, “sent”, “invite”, “solo” (senza altri messaggi in conversazione), “tome”, “fromme”, “ccme”, “tofromme”. “fromccme”, “tofromccme” (to, from, cc, me include gli alias)
date: specifica una data utilizzando il formato predefinito per le impostazioni internazionali del browser. Ad esempio date:12/08/2015 trova tutte le mail del 12 Agosto 2015. Il maggiore di (>) o minore di (<) possono essere utilizzati al posto di before o after. Sono anche permessi il maggiore/uguale (>=) e il minore/uguale (<=)
after: specifica le date successive ad una data specificata. Ad esempio after:12/08/2015 trova tutte le mail dopo il 12 Agosto 2015
before: specifica le date precedenti ad una data specificata. Ad esempio before:12/08/2015 trova tutte le mail prima il 12 Agosto 2015
size: specifica la dimensione totale di una mail ( inclusi gli allegati ) con un determinato numero di Byte, KiloByte o MegaByte. Ad esempio size:12kb trova tute le mail che sono esattamente 12K di dimensione. Il maggiore di (>) o minore di (<) possono essere utilizzati al posto di larger o smaller
larger: specifica la dimensione maggiore ad una dimensione specificata. Ad esempio larger:12kb trova tutte le mail che sono più grandi di 12 KiloByte ( inclusi gli allegati )
smaller: specifica la dimensione minore ad una dimensione specificata. Ad esempio smaller:12kb trova tutte le mail che sono più piccole di 12 KiloByte ( inclusi gli allegati )
tag: specifica un tag. Ad esempio tag:ilger trova tutte le mail che hanno applicate il tag chiamato “ilger”
Ricerca nei campi dell’header
Cercando nei campi dell’header delle mail può essere molto utile. Durante la ricerca nei campi dell’intestazione si possono utilizzare uno dei due formati:
#NOMECAMPO:stringa
field[NOMECAMPO]:stringa
Attraverso la funzione “Mostra originale” si può vedere il sorgente del messaggio in modo da vedere tutte le intestazioni ricercabili per il “NOMECAMPO“
#X-Mailer:Zimbra = cerca tutte le mail che hanno utilizzato un client di Zimbra come la Web Mail
Elenco dei parametri di ricerca
Query Syntax
------------------------------------------------------------------------------------------------------------------------
content:(TEXT)
subject:[>,<,>=,<=](TEXT)
msgid:(TEXT) // Message-Id: field from mime header
envto:(TEXT|EMAIL_ADDR|DOMAIN) // x-envelope-to mime header
envfrom:(TEXT|EMAIL|DOMAIN) // x-envelope-from mime-header
contact:(TEXT) // special-case searching for contact picker (matches type=contact documents only)
to:(TEXT|EMAIL_ADDR|DOMAIN)
from:[>,<,>=,<=]({TEXT}|{EMAIL_ADDR}|{DOMAIN})
cc:(TEXT|EMAIL|DOMAIN)
tofrom:(TEXT|EMAIL|DOMAIN) // TO or FROM
tocc:(TEXT|EMAIL|DOMAIN) // TO or CC
fromcc:(TEXT|EMAIL|DOMAIN) // TO or FROM or CC
tofromcc:(TEXT|EMAIL|DOMAIN) // TO or FROM or CC
in:(FOLDER_LABEL) // in the specified folder
under:(FOLDER_LABEL) // in the specified folder and all descendants
inid:(FOLDER_ID) // in the specified folder
underid:{FOLDER_ID} // in the specified folder and all descendants
has:(attachment|OBJECT_TYPE)
filename:(TEXT)
type:(RAW_MIME_TYPE|FRIENDLY_MIME_TYPE)
attachment:(RAW_MIME_TYPE|FRIENDLY_MIME_TYPE)
is:(anywhere|unread|read|flagged|unflagged|sent|received|replied|unreplied|
forwarded|unforwarded|invite|solo|tome|fromme|ccme|tofromme|fromccme|
tofromccme|local|remote)
date:[>,<,>=,<=](DATE) // created date
mdate:[>,<,>=,<=](DATE) // modified date
day:[>,<,>=,<=](DATE)
week:[>,<,>=,<=](DATE)
month:[>,<,>=,<=](DATE)
year:[>,<,>=,<=](DATE)
after:(DATE)
before:(DATE)
size:(SIZE)
bigger:(SIZE)
larger:(SIZE)
smaller:(SIZE)
tag:(TAG)
priority:(high|low)
message:(DB_MSG_ID)
my:(MY_SAVED_SEARCH_NAME) // not supported yet
modseq:[>,<,>=,<=](CHANGE_ID)
conv:(DB_CONV_ID)
conv-count:(NUM)
conv-minm:(NUM)
conv-maxm:(NUM)
conv-start:(DATE)
conv-end:(DATE)
appt-start:[>,<,>=,<=](DATE)
appt-end:[>,<,>=,<=](DATE)
author:(TEXT)
title:(TEXT)
keywords:(TEXT)
company:(TEXT)
metadata:(TEXT)
item:(all|none|[0-9]+|{[0-9]+(,[0-9]+)*})
field[FIELDNAME]:(TEXT)|[>,<,>=,<=](NUMBER)
#FIELDNAME:(TEXT)|[>,<,>=,<=](NUMBER)
sort: overrides the sort field specified in the <SearchRequest>
FRIENDLY_MIME_TYPE:"text"|"application"|"word"|"msword"|"excel"|"xls"|"ppt"|"pdf"|"ms-tnef"|"image"|"jpeg"|"gif"|"bmp"|"none"|"any"
TEXT: text string, must be in "'s if has spaces in it
EMAIL_ADDR: text string, no spaces, with @ sign
DOMAIN: such as *.com
FOLDER_LABEL: mail|trash|spam|anywhere
TAG: tag_name
OBJECT_TYPE: "phone" "url" "credit-card" etc...types of parsed objects
DATE: absolute-date = mm/dd/yyyy (locale sensitive) OR
relative-date = {+|-}nnnn{mi|minute[s]|h|hour[s]|d|day[s]|w|week[s]|m|month[s]|y|year[s]}
SIZE: ([<>])?n+{b,kb,mb} // default is b
DB_MSG_ID: ??
NUM: ([<>])?n+
------------------------------------------------------------------------------------------------------------------------
Test Cases
----------
ski
after:3/1/2004
subject:linux
subject:"code has"
linux or has:ssn
larger:1M
is:flagged
not is:flagged
not in:junk
-is:read
- is a synonym for "not" and may immediately precede a field
Fields
------------------------------------------------------------------------------------------------------------------------
CONTENT:
CONTENT field (e.g. email message body) is tokenized by word. We deem the following Unicode ranges are CJK characters.
* 2E80-2EFF CJK Radicals Supplement
* 2F00-2FDF Kangxi Radicals
* 2FF0-2FFF Ideographic Description Characters
*------------------------------------------------------------------------------
* 3000-303F [EXCLUDE] CJK Symbols and Punctuation
*------------------------------------------------------------------------------
* 3040-309F Hiragana
* 30A0-30FF Katakana
* 3100-312F Bopomofo
* 3130-318F Hangul Compatibility Jamo
* 3190-319F Kanbun
* 31A0-31BF Bopomofo Extended
* 31C0-31EF CJK Strokes
* 31F0-31FF Katakana Phonetic Extensions
* 3200-32FF Enclosed CJK Letters and Months
* 3300-33FF CJK Compatibility
* 3400-4DBF CJK Unified Ideographs Extension A
* 4DC0-4DFF Yijing Hexagram Symbols
* 4E00-9FFF CJK Unified Ideographs
*------------------------------------------------------------------------------
* AC00-D7AF Hangul Syllables
* D7B0-D7FF Hangul Jamo Extended-B
*------------------------------------------------------------------------------
* FF00-FFEF Halfwidth and Fullwidth Forms
To CJK character sequences, we apply the bigram tokenization where words are constructed by every subsequence of 2
characters (e.g. ABCD consists of AB, BC and CD) regardless of the grammatical structure. Therefore, CJK character
sequences are searchable by a subsequence of 2 characters or a combination of those. For example, suppose you have
a text content: "ABCDEFG". Searching by "AB", "BC", "BCD", "BCDE" are all hits even if "ABCDEFG" are grammatically
tokenized into "ABC" "DEF", and "G".
To non CJK character sequences, words are split by whitespace [\r|\n|\t|\f] or punctuation [_|-|/|.|,] with some
exceptions:
* We recognize email addresses by a pattern of "*@*.*[.*]".
* We recognize host names by a pattern of "*.*[.*]".
* We recognize numbers by a pattern of "*[0-9]([_|-|/|.|,][0-9])*".
After tokenization, all words become case-insensitive, and the following common English words are trimmed.
"a", "an", "and", "are", "as", "at", "be", "but", "by", "for", "if", "in", "into", "is", "it", "no", "not", "of", "on",
"or", "such", "that", "the", "their", "then", "there", "these", "they", "this", "to", "was", "will", "with"
Therefore, non CJK character sequences are only searchable by a word or a combination of words. For example, suppose
you have a text content: "3401 Hillview Ave, Palo Alto, CA 94304 USA". Searching by "3401", "ave" and "palo alto" are
all hits. But, substrings of each word such as "hill", "view", "94" or "US" are not hits.
Wildcards (*) are only supported at the end of word, and the search works as if it's a prefix search.
CONTACT:
CONTACT field works in the same manner as CONTENT field besides it's also seachable by stop words and always translated
to a prefix search.
header-related
from:
to:
cc:{name|domain}
subject:
saved-search-related: (UNIMPLEMENTED)
my:{name-of-saved-search}
i.e., could have a saved search of "domain:example.zimbra.com"
called "zimbra" and say:
my:zimbra
object-related fields:
has:attachment constrains search to messages with attachments
has:{phone|url|ssn|po...} messages with "objects"
mime-related
filename:{file-name} constrains search to messages with attachments of given name
type:{mime-type} constrains search to blobs of the given type
attachment:{mime-type} constrains search to messages with attachments of the given type
mime-type = raw-mime-type | mime-type-alias
raw-mime-type = type/sub-type (i.e., text/plain)
# aliases are "user-friendly" mime types
mime-type-alias = "word" | "excel" | "pdf", "image", "audio", etc...
EXAMPLES:
type:word "hello" searches within only words docs for "hello"
attachment:word "hello" searches within messages that have word docs for "hello"
attachment:image/* matches all messages that have image attachments
flags
is:anywhere --> in any folder (overrides spam-trash setting for that query part)
note that "is:anywhere" does NOT imply "across all mountpoints". Mountpoints must
be explicitly included with an "in:" term -- in:mountpointname.
is:unread
is:read
is:flagged
is:unflagged
is:sent
is:received
is:invite
is:solo --> true if the item has no conversation
The flag name can also be used in a search:
tag:\{FlagName} where {FlagName} is one of the following values:
Attached, Answered, Copied, Deleted, Draft, Flagged, Forwarded, Notified, Subscribed, Unread
date-related fields
after:{date}
before:{date}
date = {absolute-date} | {relative-date}
absolute-date = mm/dd/yyyy (locale sensitive)
relative-date = [+/-]nnnn{minute,hour,day,week,month,year}
NOTE: absolute-date is locale sensitive. Our implementation delegates it to
JDK's DateFormat class whose behavior is as follows:
* ar - dd/mm/yyyy
* be - dd.mm.yyyy
* bg - yyyy-mm-dd
* ca - dd/mm/yyyy
* cs - dd.mm.yyyy
* da - dd-mm-yyyy
* de - dd.mm.yyyy
* el - dd/mm/yyyy
* en - mm/dd/yyyy (default)
* en_AU - dd/mm/yyyy
* en_CA - dd/mm/yyyy
* en_GB - dd/mm/yyyy
* en_IE - dd/mm/yyyy
* en_IN - dd/mm/yyyy
* en_NZ - dd/mm/yyyy
* en_ZA - yyyy/mm/dd
* es - dd/mm/yyyy
* es_DO - mm/dd/yyyy
* es_HN - mm-dd-yyyy
* es_PR - mm-dd-yyyy
* es_SV - mm-dd-yyyy
* et - dd.mm.yyyy
* fi - dd.mm.yyyy
* fr - dd/mm/yyyy
* fr_CA - yyyy-mm-dd
* fr_CH - dd.mm.yyyy
* hr - yyyy.MM.dd
* hr_HR - dd.MM.yyyy.
* hu - yyyy.MM.dd.
* is - dd.mm.yyyy
* it - dd/mm/yyyy
* it_CH - dd.mm.yyyy
* iw - dd/mm/yyyy
* ja - yyyy/mm/dd
* ko - yyyy. mm. dd
* lt - yyyy.mm.dd
* lv - yyyy.dd.mm
* mk - dd.mm.yyyy
* nl - dd-mm-yyyy
* nl_BE - dd/mm/yyyy
* no - dd.mm.yyyy
* pl - yyyy-mm-dd
* pl_PL - dd.mm.yyyy
* pt - dd-mm-yyyy
* pt_BR - dd/mm/yyyy
* ro - dd.mm.yyyy
* ru - dd.mm.yyyy
* sk - dd.mm.yyyy
* sl - dd.mm.yyyy
* sq - yyyy-mm-dd
* sv - yyyy-mm-dd
* th - dd/mm/yyyy
* tr - dd.mm.yyyy
* uk - dd.mm.yyyy
* vi - dd/mm/yyyy
* zh - yyyy-mm-dd
* zh_TW - yyyy/mm/dd
In case of format error, it falls back to mm/dd/yyyy.
NOTE: need to figure out how to represent "this week", "last week", "this month", etc. probably
some special casing of relative dates and use with after/before. i.e., maybe "after:-2d AND before:0d" means
yesterday? i.e., for relative day/week/month/year, you zero out month/week/day/hour/minute?
last 4 hours: after:-4hour
today: after:0day
yesterday: (after:-2day AND before:0day)
this week: after:0week
last week: (after:-2week AND before:0week)
this month: after:0month
last month: (after:-2month AND before:0month)
this year: after:0year
last year: (after:-2year AND before:0year)
last year and older: before:0year
appointment search operators
------------------------------------------------------------------------------------------------------------------------
appt-start: appt-end:
Search based on the start and end times of the appointment.
For non-recurring appointments, this is basically what you
expect. For recurring appointments, the start and end times are
the *earliest possible* time (start of the first instance in the
recurrence) and *latest possible* time, or sometime in 2099 if
the recurrence has no end.
size-releted fields
larger:{size}
smaller:{size}
size:{size}
size is [<>]nnnn{b,kb,mb,gb} # default is kb?
tag-related fields
tag:{user-defined-tag}
domain-related fields
domain:{domain-list}
EXAMPLES: domain:stanford.edu OR: domain:*.org
db-related fields
message:{db-message-id} # constrain searches to a particular message
conversation-related-fields:
conv:{db-conv-id} # constrain searches to a paritcular conversation
* conv-min-count:{num} # constrain searches to conversations of a particular length
* conv-max-count:{num} # constrain searches to conversations of a particular length
conv-start:{date}
conv-end:{date}
metadata-related fields
author:
title:
keywords:
company:
metadata:
The metadata fields refer to the metadata of a non-textual attachment.
The fields author, title, keywords, company refer to the metadata fields
of the same name in the document.
The field metadata aggregates all the metadata fields including the above four.
E.g.,
author:acme finds all attachments whose author is acme
metadata:acme finds all attachments where acme appears in any metadata
fields, including author.
misc fields
* minm:nnnn # constrain to conversations with at least nnnn messages
* maxm:nnnn # constrain to conversations with at most nnnn messages
other-mime-specific fields
how do we want to handle doc properties from word, pdf, mp3, etc?
i.e.:
genre:rock OR artist:rush
title:"customer visit"
keywords:security
author:ross
* maybe {mime-type-alias}.field? i.e.:
audio.genre:rock OR audio.artist:rush (or mp3.*?)
word.title:hello
where the mime-type-alias can be left off if field is non-ambigious?
do we want to try and promote certain fields that we can share between mulitple types? (title, author, keywords)
Structured-Data Searching
------------------------------------------------------------------------------------------------------------------------
Search/Indexing now has the ability to analyze and store data in
Name-Value pairs in such a way that they can be searched for in a
structured way by the query language.
For example, Contact name-value pairs are indexed this way.
Structured data is stored in the "l.field" lucene field, and it should be added to the index document in a format like this:
"fieldOne:value1 value2 value3 value4\nFieldTwo:value2 value3 value4"
The search language has been extended to allow field searches to be expressed like this:
#FieldName:value
For example, to find a contact with the last name "Davis" you would use a search query like:
#lastname:davis
OR
FIELD[lastname]:davis