Updated manpage: note that IMAP server internal message dates may differ from

user-visible date headers, and that there exist servers not supporting searches.
This commit is contained in:
Nikolaus Schulz 2007-11-02 20:42:16 +00:00
parent c97b10f253
commit c5002cdefb
2 changed files with 15 additions and 0 deletions

View File

@ -267,6 +267,13 @@ probably not show up as 'new' in your user agent later on.
There is no way around this, it's just how \fBIMAP\fR works.
This does not apply, however, if you run \fBarchivemail\fR with the options
\fB--dry-run\fR or \fB--copy\fR\&.
.PP
\fBarchivemail\fR relies on server-side searches to determine the messages
that should be archived.
When matching dates, \fBIMAP\fR servers refer to server internal message
dates, and these may differ from both delivery time and the message's
\fBDate\fR header.
Also, there exist broken servers which do not implement server side searches.
.SS "IMAP URLS"
.PP
\fBarchivemail\fR\&'s \fBIMAP\fR URL parser was written

View File

@ -415,6 +415,14 @@ There is no way around this, it's just how <application/IMAP/ works.
This does not apply, however, if you run <command/archivemail/ with the options
<option/--dry-run/ or <option/--copy/.
</Para>
<Para>
<command/archivemail/ relies on server-side searches to determine the messages
that should be archived.
When matching dates, <application/IMAP/ servers refer to server internal message
dates, and these may differ from both delivery time and the message's
<application/Date/ header.
Also, there exist broken servers which do not implement server side searches.
</Para>
<RefSect3><Title><acronym/IMAP/ <acronym/URLs/</Title>
<Para>
<command/archivemail/'s <application/IMAP/ <acronym/URL/ parser was written