Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.
+39 0521 618591

zimbra    logo zimbra suite plus

12 Ago

Tips & Tricks : Parole chiave nelle ricerche

Creato: 12 Agosto 2015

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:Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo. = l'operatore è "from" e il parametro è "Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo." (questa ricerca restituisce tutte le mail che ricevuta da Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.)

È 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:Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo. 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