[Dovecot] doveadm fetch

[Nikita Koshikov]

On Tue, 20 Apr 2010 18:49:10 +0300
Timo Sirainen wrote:

> 
> The above syntax would probably have to use IMAP parser.
> 
> > doveadm fetch subject "(foo)"
> 
> This works nowadays though. It's possible to use:
> 
> doveadm fetch INBOX \( subject "(foo)" seen \) or unseen
> 
> This works because there are now "IMAP parser" and "command line
> parser". The command line parser knows that after subject there must
> come a string, so it's not confused by the () characters. Then it also
> knows that when "(" or ")" comes in a separate parameter, it means a
> list. Actually it would have been possible to support \(subject without
> space after \(, but this won't work with the ending \):
> 
> \(subject "(foo)"\)
> 
> vs.
> 
> \(subject "(foo))"
> 
> would look identical to doveadm. So I thought it's better to always
> require the space.
> 
> > but that makes it more difficult to add variables, because if you do:
> > 
> > doveadm fetch 'subject "$foo"'
> 
> $variables also work nicely now without having to escape them.
> 
> Now, the next problem is how to select what to fetch and what the output
> format should look like. I'm thinking about:
> 
> doveadm fetch INBOX "flags uid hdr.received hdr.from body" all
> 
> would look like:
> 
> ===sep
> flags: \seen \draft $Label1
> uid: 1234
> hdr:
> Received: stuff
> Received: more stuff
> From: tss at iki.fi
> 
> body:
> message body
> ..
> ===sep
> flags: ..next message..
> ===sep
> 
> The ===sep is a randomly generated separator string that begins always
> with "===", optionally it could be given as parameter. I was wondering
> about how to return hdr.* fields, if they should be returned separately
> or all in one "hdr". Otherwise separate fields would be nice, but if the
> header exists multiple times, it's not so clear anymore how it should be
> written. So if there's a single hdr then it's at least easy to
> understand that it ends with an empty line.
> 
> Besides the example parameters above there could be "hdr" = full header
> and "text" = alias for "hdr body".
> 
> It would be nice also to support something like:
> 
> doveadm search INBOX from tss at iki.fi
> 
> doveadm next|less
> doveadm next|less
> ..etc..
> 
> So the "next" would return the next matching message based on the
> previous search. I'm not really sure where the state could be kept
> though. Would be nice if it was terminal-specific, and would be nice if
> it didn't write any temporary files.

Maybe you should take exim's queue style for such operations. Here few examples:

#exim -bp //return queue in format:

 4d   99K 1O36Eu-0001Py-Ts <mykolenko.s at domain.com>
          is_uzh at domain.ltd

#doveadm search INBOX from tss at iki.fi
<...id-1>
<...id-2>
........
<...id-n>
Will return just unique ids for current mailbox. Maybe also few headers/flags etc.

#doveadm fetch <...id-2> all
Print full message for id, gotten from doveadm searc.

#doveadm fetch <...id-2> hrd.from hdr.subject
Print corresponding header values.

Exim also have -Mvl option - which print log lines for current id. It will be nice if:

#doveadm log <id> 
Found all service records for message and print them to terminal.

With above scheme you don't need to construct separator - <id...> will be enough and doveadm next wont be necessary.