1mbsync(1) General Commands Manual mbsync(1)
2
6 mbsync - synchronize IMAP4 and Maildir mailboxes
7
9 mbsync [options ...] {{channel[:box[{,|\n}...]]|group} ...|-a}
10
12 mbsync is a command line application which synchronizes mailboxes; cur‐
13 rently Maildir and IMAP4 mailboxes are supported. New messages, mes‐
14 sage deletions and flag changes can be propagated both ways; the opera‐
15 tion set can be selected in a fine-grained manner.
16 Synchronization is based on unique message identifiers (UIDs), so no
17 identification conflicts can occur (unlike with some other mail syn‐
18 chronizers). OTOH, mbsync is susceptible to UID validity changes (but
19 will recover just fine if the change is unfounded). Synchronization
20 state is kept in one local text file per mailbox pair; these files are
21 protected against concurrent mbsync processes. Mailboxes can be safely
22 modified while mbsync operates (see INHERENT PROBLEMS below for a minor
23 exception). Multiple replicas of each mailbox can be maintained.
24
26 -c, --config file
27 Read configuration from file. By default, the configuration is
28 read from ~/.mbsyncrc.
29 -a, --all
31 Select all configured channels. Any channel/group specifications
32 on the command line are ignored.
33 -l, --list
35 Don't synchronize anything, but list all mailboxes in the
36 selected channels and exit.
37 -C[f][n], --create[-far|-near]
39 Override any Create options from the config file. See below.
40 -R[f][n], --remove[-far|-near]
42 Override any Remove options from the config file. See below.
43 -X[f][n], --expunge[-far|-near]
45 Override any Expunge options from the config file. See below.
46 {-n|-N|-d|-f|-0|-F}, {--new|--renew|--delete|--flags|--noop|--full}
48 {-L|-H}[n][N][d][f], {--pull|--push}[-new|-renew|-delete|-flags]
49 Override any Sync options from the config file. See below.
51 -h, --help
53 Display a summary of command line options.
54 -v, --version
56 Display version information.
57 -V, --verbose
59 Enable verbose mode, which displays what is currently happening.
60 -D[C][d|D][m][M][n|N][s]], --debug[-crash|-driver|-driver-
62 all|-maildir|-main|-net|-net-all|-sync]
63 Enable debugging categories:
64 C, crash - use built-in crash handler
65 d, driver - print driver calls (metadata only)
66 D, driver-all - print driver calls (including messages)
67 m, maildir - print maildir debug info
68 M, main - print main debug info
69 n, net - print network traffic (protocol only)
70 N, net-all - print network traffic (including payloads)
71 s, sync - print synchronization debug info
72 All categories except crash implictly enable verbose mode.
73 Without category specification, all categories except net-all
74 are enabled.
75 -q, --quiet
77 Suppress progress counters (this is implicit if stdout is no
78 TTY, or any debugging categories are enabled) and notices. If
79 specified twice, suppress warning messages as well.
80
82 The configuration file is mandatory; mbsync will not run without it.
83 Lines starting with a hash mark (#) are comments and are ignored
84 entirely. Configuration items are keywords followed by one or more
85 arguments; arguments containing spaces must be enclosed in double
86 quotes ("), and literal double quotes and backslashes (\) must be back‐
87 slash-escaped. All keywords (including those used as arguments) are
88 case-insensitive. Bash-like home directory expansion using the tilde
89 (~) is supported in all options which represent local paths. There are
90 a few global options, the others apply to particular sections. Sec‐
91 tions begin with a section-starting keyword and are terminated by an
92 empty line or end of file. Every section defines an object with an
93 identifier unique within that object class.
94 There are two basic object classes: Stores and Channels. A Store
96 defines a collection of mailboxes; basically a folder, either local or
97 remote. A Channel connects two Stores, describing the way the two are
98 synchronized.
99 There are two auxiliary object classes: Accounts and Groups. An Account
100 describes the connection part of network Stores, so server configura‐
101 tions can be shared between multiple Stores. A Group aggregates multi‐
102 ple Channels to save typing on the command line.
103 File system locations (in particular, Path and Inbox) use the Store's
105 internal path separators, which may be slashes, periods, etc., or even
106 combinations thereof.
107 Mailbox names, OTOH, always use canonical path separators, which are
108 Unix-like forward slashes.
109 All Stores
111 These options can be used in all supported Store types.
112 In this context, the term "remote" describes the second Store within a
113 Channel, and not necessarily a remote server.
114 The special mailbox INBOX exists in every Store; its physical location
115 in the file system is Store type specific.
116 Path path
118 The location of the Store in the (server's) file system. If
119 this is no absolute path, the reference point is Store type spe‐
120 cific. This string is prepended to the mailbox names addressed
121 in this Store, but is not considered part of them; this is
122 important for Patterns and Create in the Channels section. Note
123 that you must append a slash if you want to specify an entire
124 directory. (Default: none)
125 MaxSize size[k|m][b]
127 Messages larger than size will have only a small placeholder
128 message propagated into this Store. To propagate the full mes‐
129 sage, it must be flagged in either Store; that can be done
130 retroactively, in which case the ReNew operation needs to be
131 executed instead of New. This is useful for avoiding download‐
132 ing messages with large attachments unless they are actually
133 needed. Caveat: Setting a size limit on a Store you never read
134 directly (which is typically the case for servers) is not recom‐
135 mended, as you may never notice that affected messages were not
136 propagated to it.
137 K and M can be appended to the size to specify KiBytes resp.
138 MeBytes instead of bytes. B is accepted but superfluous. If
139 size is 0, the maximum message size is unlimited. (Default: 0)
140 MapInbox mailbox
142 Create a virtual mailbox (relative to Path) which aliases the
143 INBOX. Makes sense in conjunction with Patterns in the Channels
144 section, though with a Maildir near side, you probably want to
145 place Inbox under Path instead. This virtual mailbox does not
146 support subfolders.
147 Flatten delim
149 Flatten the hierarchy within this Store by substituting the
150 canonical hierarchy delimiter / with delim. This can be useful
151 when the MUA used to access the Store provides suboptimal han‐
152 dling of hierarchical mailboxes, as is the case with Mutt. A
153 common choice for the delimiter is ..
154 Note that flattened sub-folders of the INBOX always end up under
155 Path, including the "INBOXdelim" prefix.
156 Trash mailbox
158 Specifies a mailbox (relative to Path) to copy deleted messages
159 to prior to expunging. See RECOMMENDATIONS and INHERENT PROB‐
160 LEMS below. (Default: none)
161 TrashNewOnly yes|no
163 When trashing, copy only not yet propagated messages. This makes
164 sense if the remote Store has a Trash as well (with TrashNewOnly
165 no). (Default: no)
166 TrashRemoteNew yes|no
168 When expunging the remote Store, copy not yet propagated mes‐
169 sages to this Store's Trash. When using this, the remote Store
170 does not need an own Trash at all, yet all messages are
171 archived. (Default: no)
172 Maildir Stores
174 The reference point for relative Paths is the current working direc‐
175 tory.
176 As mbsync needs UIDs, but no standardized UID storage scheme exists for
178 Maildir, mbsync supports two schemes, each with its pros and cons.
179 The native scheme is stolen from the latest Maildir patches to c-client
180 and is therefore compatible with pine. The UID validity is stored in a
181 file named .uidvalidity; the UIDs are encoded in the file names of the
182 messages.
183 The alternative scheme is based on the UID mapping used by isync ver‐
184 sions 0.8 and 0.9.x. The invariant parts of the file names of the mes‐
185 sages are used as keys into a Berkeley database named .isyncuidmap.db,
186 which holds the UID validity as well.
187 The native scheme is faster, more space efficient, endianness indepen‐
188 dent and "human readable", but will be disrupted if a message is copied
189 from another mailbox without getting a new file name; this would result
190 in duplicated UIDs sooner or later, which in turn results in a UID
191 validity change, making synchronization fail. The alternative scheme
192 would fail if a MUA changed a message's file name in a part mbsync con‐
193 siders invariant; this would be interpreted as a message deletion and a
194 new message, resulting in unnecessary traffic.
195 Mutt is known to work fine with both schemes.
196 Use mdconvert to convert mailboxes from one scheme to the other.
197 MaildirStore name
199 Define the Maildir Store name, opening a section for its parame‐
200 ters.
201 AltMap yes|no
203 Use the alternative UID storage scheme for mailboxes in this
204 Store. This does not affect mailboxes that do already have a
205 UID storage scheme; use mdconvert to change it. See RECOMMENDA‐
206 TIONS below. (Default: no)
207 Inbox path
209 The location of the INBOX. This is not relative to Path, but it
210 is allowed to place the INBOX inside the Path. (Default:
211 ~/Maildir)
212 InfoDelimiter delim
214 The character used to delimit the info field from a message's
215 basename. The Maildir standard defines this to be the colon,
216 but this is incompatible with DOS/Windows file systems.
217 (Default: the value of FieldDelimiter)
218 SubFolders Verbatim|Maildir++|Legacy
220 The on-disk folder naming style used for hierarchical mailboxes.
221 This option has no effect when Flatten is used.
222 Suppose mailboxes with the canonical paths top/sub/subsub and
223 INBOX/sub/subsub, the styles will yield the following on-disk
224 paths:
225 Verbatim - Path/top/sub/subsub and Inbox/sub/subsub (this is the
226 style you probably want to use)
227 Maildir++ - Inbox/.top.sub.subsub and Inbox/..sub.subsub (this
228 style is compatible with Courier and Dovecot - but note that the
229 mailbox metadata format is not compatible). Note that attempts
230 to set Path are rejected in this mode.
231 Legacy - Path/top/.sub/.subsub and Inbox/.sub/.subsub (this is
232 mbsync's historical style)
233 (Default: unset; will error out when sub-folders are encoun‐
234 tered)
235 IMAP4 Accounts
237 IMAPAccount name
238 Define the IMAP4 Account name, opening a section for its parame‐
239 ters.
240 Host host
242 Specify the DNS name or IP address of the IMAP server.
243 If Tunnel is used, this setting is needed only if SSLType is not
244 None and CertificateFile is not used, in which case the host
245 name is used for certificate subject verification.
246 Port port
248 Specify the TCP port number of the IMAP server. (Default: 143
249 for IMAP, 993 for IMAPS)
250 If Tunnel is used, this setting is ignored.
251 Timeout timeout
253 Specify the connect and data timeout for the IMAP server in sec‐
254 onds. Zero means unlimited. (Default: 20)
255 User username
257 Specify the login name on the IMAP server.
258 UserCmd [+]command
260 Specify a shell command to obtain a user rather than specifying
261 a user directly. This allows you to script retrieving user
262 names.
263 The command must produce exactly one line on stdout; the trail‐
264 ing newline is optional. Prepend + to the command to indicate
265 that it produces TTY output (e.g., a prompt); failure to do so
266 will merely produce messier output. Remember to backslash-
267 escape double quotes and backslashes embedded into the command.
268 Pass password
270 Specify the password for username on the IMAP server. Note that
271 this option is not required. If neither a password nor a pass‐
272 word command is specified in the configuration file, mbsync will
273 prompt you for a password.
274 PassCmd [+]command
276 Specify a shell command to obtain a password rather than speci‐
277 fying a password directly. This allows you to use password files
278 and agents.
279 See UserCmd above for details.
280 UseKeychain yes|no
282 Whether to use the macOS Keychain to obtain the password.
283 (Default: no)
284 The neccessary keychain item can be created this way:
286 security add-internet-password -r imap -s Host -a User -w
288 password [ -T /path/to/mbsync ]
289 Tunnel command
291 Specify a command to run to establish a connection rather than
292 opening a TCP socket. This allows you to run an IMAP session
293 over an SSH tunnel, for example.
294 AuthMechs type ...
296 The list of acceptable authentication mechanisms. In addition
297 to the mechanisms listed in the SASL registry (link below), the
298 legacy IMAP LOGIN mechanism is known. The wildcard * represents
299 all mechanisms that are deemed secure enough for the current
300 SSLType setting. The actually used mechanism is the most secure
301 choice from the intersection of this list, the list supplied by
302 the server, and the installed SASL modules. (Default: *)
303 SSLType {None|STARTTLS|IMAPS}
305 Select the connection security/encryption method:
306 None - no security. This is the default when Tunnel is set, as
307 tunnels are usually secure.
308 STARTTLS - security is established via the STARTTLS extension
309 after connecting the regular IMAP port 143. Most servers support
310 this, so it is the default (unless a tunnel is used).
311 IMAPS - security is established by starting SSL/TLS negotiation
312 right after connecting the secure IMAP port 993.
313 SSLVersions [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3]
315 Select the acceptable SSL/TLS versions. Use old versions only
316 when the server has problems with newer ones. (Default: [TLSv1]
317 [TLSv1.1] [TLSv1.2] [TLSv1.3]).
318 SystemCertificates yes|no
320 Whether the system's default CA (certificate authority) certifi‐
321 cate store should be used to verify certificate trust chains.
322 Disable this if you want to trust only hand-picked certificates.
323 (Default: yes)
324 CertificateFile path
326 File containing additional X.509 certificates used to verify
327 server identities. It may contain two types of certificates:
328 Host These certificates are matched only against the received
330 server certificate itself. They are always trusted, re‐
331 gardless of validity. A typical use case would be forc‐
332 ing acceptance of an expired certificate.
333 These certificates may be obtained using the mbsync-get-
334 cert tool; make sure to verify their fingerprints before
335 trusting them, or transfer them securely from the serv‐
336 er's network (if it can be trusted beyond the server it‐
337 self).
338 CA These certificates are used as trust anchors when build‐
340 ing the certificate chain for the received server cer‐
341 tificate. They are used to supplant or supersede the
342 system's trust store, depending on the SystemCertificates
343 setting; it is not necessary and not recommended to spec‐
344 ify the system's trust store itself here. The trust
345 chains are fully validated.
346 ClientCertificate path
348 File containing a client certificate to send to the server.
349 ClientKey should also be specified.
350 Note that client certificate verification is usually not re‐
351 quired, so it is unlikely that you need this option.
352 ClientKey path
354 File containing the private key corresponding to ClientCertifi‐
355 cate.
356 CipherString string
358 Specify OpenSSL cipher string for connections secured with TLS
359 up to version 1.2 (but not 1.3 and above). The format is de‐
360 scribed in ciphers(1). (Default: empty, which implies system
361 wide policy).
362 PipelineDepth depth
364 Maximum number of IMAP commands which can be simultaneously in
365 flight. Setting this to 1 disables pipelining. This is mostly
366 a debugging option, but may also be used to limit average band‐
367 width consumption (GMail may require this if you have a very
368 fast connection), or to spare flaky servers like M$ Exchange.
369 (Default: unlimited)
370 DisableExtension[s] extension ...
372 Disable the use of specific IMAP extensions. This can be used
373 to work around bugs in servers (and possibly mbsync itself).
374 (Default: empty)
375 IMAP Stores
377 The reference point for relative Paths is whatever the server likes it
378 to be; probably the user's $HOME or $HOME/Mail on that server. The lo‐
379 cation of INBOX is up to the server as well and is usually irrelevant.
380 IMAPStore name
382 Define the IMAP4 Store name, opening a section for its parame‐
383 ters.
384 Account account
386 Specify which IMAP4 Account to use. Instead of defining an Ac‐
387 count and referencing it here, it is also possible to specify
388 all the Account options directly in the Store's section - this
389 makes sense if an Account is used for one Store only anyway.
390 UseNamespace yes|no
392 Selects whether the server's first "personal" NAMESPACE should
393 be prefixed to mailbox names. Disabling this makes sense for
394 some broken IMAP servers. This option is meaningless if a Path
395 was specified. (Default: yes)
396 PathDelimiter delim
398 Specify the server's hierarchy delimiter. (Default: taken from
399 the server's first "personal" NAMESPACE)
400 Do not abuse this to re-interpret the hierarchy. Use Flatten
401 instead.
402 SubscribedOnly yes|no
404 Selects whether to synchronize only mailboxes that are sub‐
405 scribed to on the IMAP server. In technical terms, if this op‐
406 tion is set, mbsync will use the IMAP command LSUB instead of
407 LIST to look for mailboxes in this Store. This option make
408 sense only in conjunction with Patterns. (Default: no)
409 Channels
411 Channel name
412 Define the Channel name, opening a section for its parameters.
413 {Far|Near} :store:[mailbox]
415 Specify the far resp. near side Store to be connected by this
416 Channel. If Patterns are specified, mailbox is interpreted as a
417 prefix which is not matched against the patterns, and which is
418 not affected by mailbox list overrides. Otherwise, if mailbox
419 is omitted, INBOX is assumed.
420 Pattern[s] [!]pattern ...
422 Instead of synchronizing only one mailbox pair, synchronize all
423 mailboxes that match the pattern(s). The mailbox names are the
424 same on the far and near side. Patterns are IMAP4 patterns,
425 i.e., * matches anything and % matches anything up to the next
426 hierarchy delimiter. Prepending ! to a pattern makes it an ex‐
427 clusion. Multiple patterns can be specified (either by supplying
428 multiple arguments or by using Pattern multiple times); later
429 matches take precedence.
430 Note that INBOX is not matched by wildcards, unless it lives un‐
431 der Path.
432 The mailbox list selected by Patterns can be overridden by a
433 mailbox list in a channel reference (a Group specification or
434 the command line).
435 Example: "Patterns % !Trash"
436 MaxSize size[k|m][b]
438 Analogous to the homonymous option in the Stores section, but
439 applies equally to Far and Near. Note that this actually modi‐
440 fies the Stores, so take care not to provide conflicting set‐
441 tings if you use the Stores in multiple Channels.
442 MaxMessages count
444 Sets the maximum number of messages to keep in each near side
445 mailbox. This is useful for mailboxes where you keep a complete
446 archive on the server, but want to mirror only the last messages
447 (for instance, for mailing lists). The messages that were the
448 first to arrive in the mailbox (independently of the actual date
449 of the message) will be deleted first. Messages that are
450 flagged (marked as important) and (by default) unread messages
451 will not be automatically deleted. If count is 0, the maximum
452 number of messages is unlimited (Default: 0).
453 ExpireUnread yes|no
455 Selects whether unread messages should be affected by MaxMes‐
456 sages. Normally, unread messages are considered important and
457 thus never expired. This ensures that you never miss new mes‐
458 sages even after an extended absence. However, if your archive
459 contains large amounts of unread messages by design, treating
460 them as important would practically defeat MaxMessages. In this
461 case you need to enable this option. (Default: no).
462 Sync {None|[Pull] [Push] [New] [ReNew] [Delete] [Flags]|All}
464 Select the synchronization operation(s) to perform:
465 Pull - propagate changes from far to near side.
466 Push - propagate changes from near to far side.
467 New - propagate newly appeared messages.
468 ReNew - upgrade placeholders to full messages. Useful only with
469 a configured MaxSize.
470 Delete - propagate message deletions. This applies only to mes‐
471 sages that are actually gone, i.e., were expunged. The affected
472 messages in the remote Store are marked as deleted only, i.e.,
473 they won't be really deleted until that Store is expunged.
474 Flags - propagate flag changes. Note that Deleted/Trashed is a
475 flag as well; this is particularly interesting if you use mutt
476 with the maildir_trash option.
477 All (--full on the command line) - all of the above. This is
478 the global default.
479 None (--noop on the command line) - don't propagate anything.
480 Useful if you want to expunge only.
481 Pull and Push are direction flags, while New, ReNew, Delete and
483 Flags are type flags. The two flag classes make up a two-dimen‐
484 sional matrix (a table). Its cells are the individual actions to
485 perform. There are two styles of asserting the cells:
486 In the first style, the flags select entire rows/colums in the
487 matrix. Only the cells which are selected both horizontally and
488 vertically are asserted. Specifying no flags from a class is
489 like specifying all flags from this class. For example,
490 "Sync Pull New Flags" will propagate new messages and flag
491 changes from the far side to the near side, "Sync New Delete"
492 will propagate message arrivals and deletions both ways, and
493 "Sync Push" will propagate all changes from the near side to the
494 far side.
495 In the second style, direction flags are concatenated with type
496 flags; every compound flag immediately asserts a cell in the ma‐
497 trix. In addition to at least one compound flag, the individual
498 flags can be used as well, but as opposed to the first style,
499 they immediately assert all cells in their respective row/col‐
500 umn. For example, "Sync PullNew PullDelete Push" will propagate
501 message arrivals and deletions from the far side to the near
502 side and any changes from the near side to the far side. Note
503 that it is not allowed to assert a cell in two ways, e.g.
504 "Sync PullNew Pull" and "Sync PullNew Delete Push" induce error
505 messages.
506 Create {None|Far|Near|Both}
508 Automatically create missing mailboxes [on the far/near side].
509 Otherwise print an error message and skip that mailbox pair if a
510 mailbox and the corresponding sync state does not exist. (Glob‐
511 al default: None)
512 Remove {None|Far|Near|Both}
514 Propagate mailbox deletions [to the far/near side]. Otherwise
515 print an error message and skip that mailbox pair if a mailbox
516 does not exist but the corresponding sync state does.
517 For MailDir mailboxes it is sufficient to delete the cur/ subdi‐
518 rectory to mark them as deleted. This ensures compatibility with
519 SyncState *.
520 Note that for safety, non-empty mailboxes are never deleted.
521 (Global default: None)
522 Expunge {None|Far|Near|Both}
524 Permanently remove all messages [on the far/near side] marked
525 for deletion. See RECOMMENDATIONS below. (Global default:
526 None)
527 CopyArrivalDate {yes|no}
529 Selects whether their arrival time should be propagated together
530 with the messages. Enabling this makes sense in order to keep
531 the time stamp based message sorting intact. Note that IMAP
532 does not guarantee that the time stamp (termed internal date) is
533 actually the arrival time, but it is usually close enough. (De‐
534 fault: no)
535 Sync, Create, Remove, Expunge, MaxMessages, and CopyArrivalDate can be
537 used before any section for a global effect. The global settings are
538 overridden by Channel-specific options, which in turn are overridden by
539 command line switches.
540 SyncState {*|path}
542 Set the location of this Channel's synchronization state files.
543 * means that the state should be saved in a file named .mbsync‐
544 state in the near side mailbox itself; this has the advantage
545 that you do not need to handle the state file separately if you
546 delete the mailbox, but it works only with Maildir mailboxes,
547 obviously. Otherwise this is interpreted as a string to prepend
548 to the near side mailbox name to make up a complete path.
549 This option can be used outside any section for a global effect.
550 In this case the appended string is made up according to the
551 pattern :far-store:far-box_:near-store:near-box (see also Field‐
552 Delimiter below).
553 (Global default: ~/.mbsync/).
554 Groups
556 Group name [channel[:box[,...]]] ...
557 Define the Group name, opening a section for its parameters.
558 Note that even though Groups have an own namespace, they will
559 "hide" Channels with the same name on the command line.
560 One or more Channels can be specified on the same line.
561 If you supply one or more boxes to a channel, they will be used
562 instead of what is specified in the Channel's Patterns. The
563 same can be done on the command line, except that there newlines
564 can be used as mailbox name separators as well.
565 Channel[s] channel[:box[,...]] ...
567 Add the specified channels to the group. This option can be
568 specified multiple times within a Group.
569 Global Options
571 FSync yes|no
572 Selects whether mbsync performs forced flushing, which deter‐
573 mines the level of data safety after system crashes and power
574 outages. Disabling it is reasonably safe for file systems which
575 are mounted with data=ordered mode. Enabling it is a wise
576 choice for file systems mounted with data=writeback, in particu‐
577 lar modern systems like ext4, btrfs and xfs. The performance im‐
578 pact on older file systems may be disproportionate. (Default:
579 yes)
580 FieldDelimiter delim
582 The character to use to delimit fields in the string appended to
583 a global SyncState. mbsync prefers to use the colon, but this
584 is incompatible with DOS/Windows file systems. This option is
585 meaningless for SyncState if the latter is *, obviously. Howev‐
586 er, it also determines the default of InfoDelimiter. (Global
587 default: ; on Windows, : everywhere else)
588 BufferLimit size[k|m][b]
590 The per-Channel, per-direction instantaneous memory usage above
591 which mbsync will refrain from using more memory. Note that this
592 is no absolute limit, as even a single message can consume more
593 memory than this. (Default: 10M)
594
596 If mbsync's output is connected to a console, it will print progress
597 counters by default. The output will look like this:
598 C: 1/2 B: 3/4 F: +13/13 *23/42 #0/0 N: +0/7 *0/0 #0/0
600 This represents the cumulative progress over channels, boxes, and mes‐
602 sages affected on the far and near side, respectively. The message
603 counts represent added messages, messages with updated flags, and
604 trashed messages, respectively. No attempt is made to calculate the
605 totals in advance, so they grow over time as more information is gath‐
606 ered.
607
609 Make sure your IMAP server does not auto-expunge deleted messages - it
610 is slow, and semantically somewhat questionable. Specifically, Gmail
611 needs to be configured not to do it.
612 By default, mbsync will not delete any messages - deletions are propa‐
614 gated by marking the messages as deleted on the remote store. Once you
615 have verified that your setup works, you will typically want to set Ex‐
616 punge to Both, so that deletions become effective.
617 mbsync's built-in trash functionality relies on mbsync doing the ex‐
619 punging of deleted messages. This is the case when it propagates dele‐
620 tions of previously propagated messages, and the trash is on the target
621 store (typically your IMAP server).
622 However, when you intend mbsync to trash messages which were not propa‐
623 gated yet, the MUA must mark the messages as deleted without expunging
624 them (e.g., Mutt's maildir_trash option). Note that most messages are
625 propagated a long time before they are deleted, so this is a corner
626 case you probably do not want to optimize for. This also implies that
627 the TrashNewOnly and TrashRemoteNew options are typically not very use‐
628 ful.
629 If your server supports auto-trashing (as Gmail does), it is probably a
631 good idea to rely on that instead of mbsync's trash functionality. If
632 you do that, and intend to synchronize the trash like other mailboxes,
633 you should not use mbsync's Trash option at all.
634 Use of the Trash option with M$ Exchange 2013 requires the use of Dis‐
636 ableExtension MOVE due to a server bug.
637 When using the more efficient default UID mapping scheme, it is impor‐
639 tant that the MUA renames files when moving them between Maildir fold‐
640 ers. Mutt always does that, while mu4e needs to be configured to do
641 it:
642 (setq mu4e-change-filenames-when-moving t)
643
645 Changes done after mbsync has retrieved the message list will not be
646 synchronised until the next time mbsync is invoked.
647 Using Trash on IMAP Stores without the UIDPLUS extension (notably, M$
649 Exchange up to at least 2010) bears a race condition: messages will be
650 lost if they are marked as deleted after the message list was retrieved
651 but before the mailbox is expunged. There is no risk as long as the
652 IMAP mailbox is accessed by only one client (including mbsync) at a
653 time.
654
656 ~/.mbsyncrc
657 Default configuration file
658 ~/.mbsync/
660 Directory containing synchronization state files
661
663 mdconvert(1), mutt(1), maildir(5)
664 Up to date information on mbsync can be found at http://isync.sf.net/
666 SASL mechanisms are listed at http://www.iana.org/assignments/sasl-
668 mechanisms/sasl-mechanisms.xhtml
669
671 Originally written by Michael R. Elkins, rewritten and currently main‐
672 tained by Oswald Buddenhagen, contributions by Theodore Y. Ts'o.
673 2015 Mar 22 mbsync(1)