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[m][s], --create[-master|-slave]
39 Override any Create options from the config file. See below.
40 -R[m][s], --remove[-master|-slave]
42 Override any Remove options from the config file. See below.
43 -X[m][s], --expunge[-master|-slave]
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 rest applies to particular sections. Sec‐
91 tions are started by a section keyword and are terminated by an empty
92 line or end of file. Every section defines an object with an identi‐
93 fier 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 remote Stores, so a server connection
101 can be shared between multiple Stores. A Group aggregates multiple
102 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 in the Channels section. Note that you
123 must append a slash if you want to specify an entire directory.
124 (Default: none)
125 MaxSize size[k|m][b]
127 Messages larger than that will not be propagated into this
128 Store. This is useful for weeding out messages with large
129 attachments. K and M can be appended to the size to specify
130 KiBytes resp. MeBytes instead of bytes. B is accepted but
131 superfluous. If size is 0, the maximum message size is unlim‐
132 ited. (Default: 0)
133 MapInbox mailbox
135 Create a virtual mailbox (relative to Path) which aliases the
136 INBOX. Makes sense in conjunction with Patterns in the Channels
137 section, though with a Maildir slave, you probably want to place
138 Inbox under Path instead. This virtual mailbox does not support
139 subfolders.
140 Flatten delim
142 Flatten the hierarchy within this Store by substituting the
143 canonical hierarchy delimiter / with delim. This can be useful
144 when the MUA used to access the Store provides suboptimal han‐
145 dling of hierarchical mailboxes, as is the case with Mutt. A
146 common choice for the delimiter is ..
147 Note that flattened sub-folders of the INBOX always end up under
148 Path, including the "INBOXdelim" prefix.
149 Trash mailbox
151 Specifies a mailbox (relative to Path) to copy deleted messages
152 to prior to expunging. See RECOMMENDATIONS and INHERENT PROB‐
153 LEMS below. (Default: none)
154 TrashNewOnly yes|no
156 When trashing, copy only not yet propagated messages. This makes
157 sense if the remote Store has a Trash as well (with TrashNewOnly
158 no). (Default: no)
159 TrashRemoteNew yes|no
161 When expunging the remote Store, copy not yet propagated mes‐
162 sages to this Store's Trash. When using this, the remote Store
163 does not need an own Trash at all, yet all messages are
164 archived. (Default: no)
165 Maildir Stores
167 The reference point for relative Paths is the current working direc‐
168 tory.
169 As mbsync needs UIDs, but no standardized UID storage scheme exists for
171 Maildir, mbsync supports two schemes, each with its pros and cons.
172 The native scheme is stolen from the latest Maildir patches to c-client
173 and is therefore compatible with pine. The UID validity is stored in a
174 file named .uidvalidity; the UIDs are encoded in the file names of the
175 messages.
176 The alternative scheme is based on the UID mapping used by isync ver‐
177 sions 0.8 and 0.9.x. The invariant parts of the file names of the mes‐
178 sages are used as keys into a Berkeley database named .isyncuidmap.db,
179 which holds the UID validity as well.
180 The native scheme is faster, more space efficient, endianness indepen‐
181 dent and "human readable", but will be disrupted if a message is copied
182 from another mailbox without getting a new file name; this would result
183 in duplicated UIDs sooner or later, which in turn results in a UID
184 validity change, making synchronization fail. The alternative scheme
185 would fail if a MUA changed a message's file name in a part mbsync con‐
186 siders invariant; this would be interpreted as a message deletion and a
187 new message, resulting in unnecessary traffic.
188 Mutt is known to work fine with both schemes.
189 Use mdconvert to convert mailboxes from one scheme to the other.
190 MaildirStore name
192 Define the Maildir Store name, opening a section for its parame‐
193 ters.
194 AltMap yes|no
196 Use the alternative UID storage scheme for mailboxes in this
197 Store. This does not affect mailboxes that do already have a
198 UID storage scheme; use mdconvert to change it. See RECOMMENDA‐
199 TIONS below. (Default: no)
200 Inbox path
202 The location of the INBOX. This is not relative to Path, but it
203 is allowed to place the INBOX inside the Path. (Default:
204 ~/Maildir)
205 InfoDelimiter delim
207 The character used to delimit the info field from a message's
208 basename. The Maildir standard defines this to be the colon,
209 but this is incompatible with DOS/Windows file systems.
210 (Default: the value of FieldDelimiter)
211 SubFolders Verbatim|Maildir++|Legacy
213 The on-disk folder naming style used for hierarchical mailboxes.
214 This has option has no effect when Flatten is used.
215 Suppose mailboxes with the canonical paths top/sub/subsub and
216 INBOX/sub/subsub, the styles will yield the following on-disk
217 paths:
218 Verbatim - Path/top/sub/subsub and Inbox/sub/subsub (this is the
219 style you probably want to use)
220 Maildir++ - Inbox/.top.sub.subsub and Inbox/..sub.subsub (this
221 style is compatible with Courier and Dovecot - but note that the
222 mailbox metadata format is not compatible). Note that attempts
223 to set Path are rejected in this mode.
224 Legacy - Path/top/.sub/.subsub and Inbox/.sub/.subsub (this is
225 mbsync's historical style)
226 (Default: unset; will error out when sub-folders are encoun‐
227 tered)
228 IMAP4 Accounts
230 IMAPAccount name
231 Define the IMAP4 Account name, opening a section for its parame‐
232 ters.
233 Host host
235 Specify the DNS name or IP address of the IMAP server.
236 If Tunnel is used, this setting is needed only if SSLType is not
237 None and CertificateFile is not used, in which case the host
238 name is used for certificate subject verification.
239 Port port
241 Specify the TCP port number of the IMAP server. (Default: 143
242 for IMAP, 993 for IMAPS)
243 If Tunnel is used, this setting is ignored.
244 Timeout timeout
246 Specify the connect and data timeout for the IMAP server in sec‐
247 onds. Zero means unlimited. (Default: 20)
248 User username
250 Specify the login name on the IMAP server.
251 Pass password
253 Specify the password for username on the IMAP server. Note that
254 this option is not required. If neither a password nor a pass‐
255 word command is specified in the configuration file, mbsync will
256 prompt you for a password.
257 PassCmd [+]command
259 Specify a shell command to obtain a password rather than speci‐
260 fying a password directly. This allows you to use password files
261 and agents. The command must produce exactly one line on std‐
262 out; the trailing newline is optional. Prepend + to the command
263 to indicate that it produces TTY output (e.g., a decryption
264 password prompt); failure to do so will merely produce messier
265 output.
266 Tunnel command
268 Specify a command to run to establish a connection rather than
269 opening a TCP socket. This allows you to run an IMAP session
270 over an SSH tunnel, for example.
271 AuthMechs type ...
273 The list of acceptable authentication mechanisms. In addition
274 to the mechanisms listed in the SASL registry (link below), the
275 legacy IMAP LOGIN mechanism is known. The wildcard * represents
276 all mechanisms that are deemed secure enough for the current
277 SSLType setting. The actually used mechanism is the most secure
278 choice from the intersection of this list, the list supplied by
279 the server, and the installed SASL modules. (Default: *)
280 SSLType {None|STARTTLS|IMAPS}
282 Select the connection security/encryption method:
283 None - no security. This is the default when Tunnel is set, as
284 tunnels are usually secure.
285 STARTTLS - security is established via the STARTTLS extension
286 after connecting the regular IMAP port 143. Most servers support
287 this, so it is the default (unless a tunnel is used).
288 IMAPS - security is established by starting SSL/TLS negotiation
289 right after connecting the secure IMAP port 993.
290 SSLVersions [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2]
292 Select the acceptable SSL/TLS versions. Use old versions only
293 when the server has problems with newer ones. (Default: [TLSv1]
294 [TLSv1.1] [TLSv1.2]).
295 SystemCertificates yes|no
297 Whether the system's default root cerificate store should be
298 loaded. (Default: yes)
299 CertificateFile path
301 File containing additional X.509 certificates used to verify
302 server identities. Directly matched peer certificates are always
303 trusted, regardless of validity.
304 Note that the system's default certificate store is always used
305 (unless SystemCertificates is disabled) and should not be speci‐
306 fied here.
307 ClientCertificate path
309 File containing a client certificate to send to the server.
310 ClientKey should also be specified.
311 Note that client certificate verification is usually not
312 required, so it is unlikely that you need this option.
313 ClientKey path
315 File containing the private key corresponding to ClientCertifi‐
316 cate.
317 PipelineDepth depth
319 Maximum number of IMAP commands which can be simultaneously in
320 flight. Setting this to 1 disables pipelining. This is mostly
321 a debugging option, but may also be used to limit average band‐
322 width consumption (GMail may require this if you have a very
323 fast connection), or to spare flaky servers like M$ Exchange.
324 (Default: unlimited)
325 DisableExtension[s] extension ...
327 Disable the use of specific IMAP extensions. This can be used
328 to work around bugs in servers (and possibly mbsync itself).
329 (Default: empty)
330 IMAP Stores
332 The reference point for relative Paths is whatever the server likes it
333 to be; probably the user's $HOME or $HOME/Mail on that server. The
334 location of INBOX is up to the server as well and is usually irrele‐
335 vant.
336 IMAPStore name
338 Define the IMAP4 Store name, opening a section for its parame‐
339 ters.
340 Account account
342 Specify which IMAP4 Account to use. Instead of defining an
343 Account and referencing it here, it is also possible to specify
344 all the Account options directly in the Store's section - this
345 makes sense if an Account is used for one Store only anyway.
346 UseNamespace yes|no
348 Selects whether the server's first "personal" NAMESPACE should
349 be prefixed to mailbox names. Disabling this makes sense for
350 some broken IMAP servers. This option is meaningless if a Path
351 was specified. (Default: yes)
352 PathDelimiter delim
354 Specify the server's hierarchy delimiter. (Default: taken from
355 the server's first "personal" NAMESPACE)
356 Do not abuse this to re-interpret the hierarchy. Use Flatten
357 instead.
358 Channels
360 Channel name
361 Define the Channel name, opening a section for its parameters.
362 {Master|Slave} :store:[mailbox]
364 Specify the Master resp. Slave Store to be connected by this
365 Channel. If Patterns are specified, mailbox is interpreted as a
366 prefix which is not matched against the patterns, and which is
367 not affected by mailbox list overrides. Otherwise, if mailbox
368 is omitted, INBOX is assumed.
369 Pattern[s] [!]pattern ...
371 Instead of synchronizing only one mailbox pair, synchronize all
372 mailboxes that match the pattern(s). The mailbox names are the
373 same on both Master and Slave. Patterns are IMAP4 patterns,
374 i.e., * matches anything and % matches anything up to the next
375 hierarchy delimiter. Prepending ! to a pattern makes it an
376 exclusion. Multiple patterns can be specified (either by supply‐
377 ing multiple arguments or by using Pattern multiple times);
378 later matches take precedence.
379 Note that INBOX is not matched by wildcards, unless it lives
380 under Path.
381 The mailbox list selected by Patterns can be overridden by a
382 mailbox list in a channel reference (a Group specification or
383 the command line).
384 Example: "Patterns % !Trash"
385 MaxSize size[k|m][b]
387 Analogous to the homonymous option in the Stores section, but
388 applies equally to Master and Slave. Note that this actually
389 modifies the Stores, so take care not to provide conflicting
390 settings if you use the Stores in multiple Channels.
391 MaxMessages count
393 Sets the maximum number of messages to keep in each Slave mail‐
394 box. This is useful for mailboxes where you keep a complete ar‐
395 chive on the server, but want to mirror only the last messages
396 (for instance, for mailing lists). The messages that were the
397 first to arrive in the mailbox (independently of the actual date
398 of the message) will be deleted first. Messages that are
399 flagged (marked as important) and (by default) unread messages
400 will not be automatically deleted. If count is 0, the maximum
401 number of messages is unlimited (Default: 0).
402 ExpireUnread yes|no
404 Selects whether unread messages should be affected by MaxMes‐
405 sages. Normally, unread messages are considered important and
406 thus never expired. This ensures that you never miss new mes‐
407 sages even after an extended absence. However, if your archive
408 contains large amounts of unread messages by design, treating
409 them as important would practically defeat MaxMessages. In this
410 case you need to enable this option. (Default: no).
411 Sync {None|[Pull] [Push] [New] [ReNew] [Delete] [Flags]|All}
413 Select the synchronization operation(s) to perform:
414 Pull - propagate changes from Master to Slave.
415 Push - propagate changes from Slave to Master.
416 New - propagate newly appeared messages.
417 ReNew - previously refused messages are re-evaluated for propa‐
418 gation. Useful after flagging affected messages in the source
419 Store or enlarging MaxSize in the destination Store.
420 Delete - propagate message deletions. This applies only to mes‐
421 sages that are actually gone, i.e., were expunged. The affected
422 messages in the remote Store are marked as deleted only, i.e.,
423 they won't be really deleted until that Store is expunged.
424 Flags - propagate flag changes. Note that Deleted/Trashed is a
425 flag as well; this is particularly interesting if you use mutt
426 with the maildir_trash option.
427 All (--full on the command line) - all of the above. This is
428 the global default.
429 None (--noop on the command line) - don't propagate anything.
430 Useful if you want to expunge only.
431 Pull and Push are direction flags, while New, ReNew, Delete and
433 Flags are type flags. The two flag classes make up a two-dimen‐
434 sional matrix (a table). Its cells are the individual actions to
435 perform. There are two styles of asserting the cells:
436 In the first style, the flags select entire rows/colums in the
437 matrix. Only the cells which are selected both horizontally and
438 vertically are asserted. Specifying no flags from a class is
439 like specifying all flags from this class. For example,
440 "Sync Pull New Flags" will propagate new messages and flag
441 changes from the Master to the Slave, "Sync New Delete" will
442 propagate message arrivals and deletions both ways, and
443 "Sync Push" will propagate all changes from the Slave to the
444 Master.
445 In the second style, direction flags are concatenated with type
446 flags; every compound flag immediately asserts a cell in the
447 matrix. In addition to at least one compound flag, the individ‐
448 ual flags can be used as well, but as opposed to the first
449 style, they immediately assert all cells in their respective
450 row/column. For example, "Sync PullNew PullDelete Push" will
451 propagate message arrivals and deletions from the Master to the
452 Slave and any changes from the Slave to the Master. Note that
453 it is not allowed to assert a cell in two ways, e.g.
454 "Sync PullNew Pull" and "Sync PullNew Delete Push" induce error
455 messages.
456 Create {None|Master|Slave|Both}
458 Automatically create missing mailboxes [on the Master/Slave].
459 Otherwise print an error message and skip that mailbox pair if a
460 mailbox and the corresponding sync state does not exist.
461 (Global default: None)
462 Remove {None|Master|Slave|Both}
464 Propagate mailbox deletions [to the Master/Slave]. Otherwise
465 print an error message and skip that mailbox pair if a mailbox
466 does not exist but the corresponding sync state does.
467 For MailDir mailboxes it is sufficient to delete the cur/ subdi‐
468 rectory to mark them as deleted. This ensures compatibility with
469 SyncState *.
470 Note that for safety, non-empty mailboxes are never deleted.
471 (Global default: None)
472 Expunge {None|Master|Slave|Both}
474 Permanently remove all messages [on the Master/Slave] marked for
475 deletion. See RECOMMENDATIONS below. (Global default: None)
476 CopyArrivalDate {yes|no}
478 Selects whether their arrival time should be propagated together
479 with the messages. Enabling this makes sense in order to keep
480 the time stamp based message sorting intact. Note that IMAP
481 does not guarantee that the time stamp (termed internal date) is
482 actually the arrival time, but it is usually close enough.
483 (Default: no)
484 Sync, Create, Remove, Expunge, MaxMessages, and CopyArrivalDate can be
486 used before any section for a global effect. The global settings are
487 overridden by Channel-specific options, which in turn are overridden by
488 command line switches.
489 SyncState {*|path}
491 Set the location of this Channel's synchronization state files.
492 * means that the state should be saved in a file named .mbsync‐
493 state in the Slave mailbox itself; this has the advantage that
494 you needn't to care for the state file if you delete the mail‐
495 box, but it works only with Maildir mailboxes, obviously. Other‐
496 wise this is interpreted as a string to prepend to the Slave
497 mailbox name to make up a complete path.
498 This option can be used outside any section for a global effect.
499 In this case the appended string is made up according to the
500 pattern :master:master-box_:slave:slave-box (see also FieldDe‐
501 limiter below).
502 (Global default: ~/.mbsync/).
503 Groups
505 Group name [channel[:box[,...]]] ...
506 Define the Group name, opening a section for its parameters.
507 Note that even though Groups have an own namespace, they will
508 "hide" Channels with the same name on the command line.
509 One or more Channels can be specified on the same line.
510 If you supply one or more boxes to a channel, they will be used
511 instead of what is specified in the Channel's Patterns. The
512 same can be done on the command line, except that there newlines
513 can be used as mailbox name separators as well.
514 Channel[s] channel[:box[,...]] ...
516 Add the specified channels to the group. This option can be
517 specified multiple times within a Group.
518 Global Options
520 FSync yes|no
521 Selects whether mbsync performs forced flushing, which deter‐
522 mines the level of data safety after system crashes and power
523 outages. Disabling it is reasonably safe for file systems which
524 are mounted with data=ordered mode. Enabling it is a wise
525 choice for file systems mounted with data=writeback, in particu‐
526 lar modern systems like ext4, btrfs and xfs. The performance
527 impact on older file systems may be disproportionate. (Default:
528 yes)
529 FieldDelimiter delim
531 The character to use to delimit fields in the string appended to
532 a global SyncState. mbsync prefers to use the colon, but this
533 is incompatible with DOS/Windows file systems. This option is
534 meaningless for SyncState if the latter is *, obviously. How‐
535 ever, it also determines the default of InfoDelimiter. (Global
536 default: ; on Windows, : everywhere else)
537 BufferLimit size[k|m][b]
539 The per-Channel, per-direction instantaneous memory usage above
540 which mbsync will refrain from using more memory. Note that this
541 is no absolute limit, as even a single message can consume more
542 memory than this. (Default: 10M)
543
545 If mbsync's output is connected to a console, it will print progress
546 counters by default. The output will look like this:
547 C: 1/2 B: 3/4 M: +13/13 *23/42 #0/0 S: +0/7 *0/0 #0/0
549 This represents the cumulative progress over channels, boxes, and mes‐
551 sages affected on master and slave, respectively. The message counts
552 represent added messages, messages with updated flags, and trashed mes‐
553 sages, respectively. No attempt is made to calculate the totals in
554 advance, so they grow over time as more information is gathered.
555
557 Make sure your IMAP server does not auto-expunge deleted messages - it
558 is slow, and semantically somewhat questionable. Specifically, Gmail
559 needs to be configured not to do it.
560 By default, mbsync will not delete any messages - deletions are propa‐
562 gated by marking the messages as deleted on the remote store. Once you
563 have verified that your setup works, you will typically want to set
564 Expunge to Both, so that deletions become effective.
565 mbsync's built-in trash functionality relies on mbsync doing the
567 expunging of deleted messages. This is the case when it propagates
568 deletions of previously propagated messages, and the trash is on the
569 target store (typically your IMAP server).
570 However, when you intend mbsync to trash messages which were not propa‐
571 gated yet, the MUA must mark the messages as deleted without expunging
572 them (e.g., Mutt's maildir_trash option). Note that most messages are
573 propagated a long time before they are deleted, so this is a corner
574 case you probably do not want to optimize for. This also implies that
575 the TrashNewOnly and TrashRemoteNew options are typically not very use‐
576 ful.
577 If your server supports auto-trashing (as Gmail does), it is probably a
579 good idea to rely on that instead of mbsync's trash functionality. If
580 you do that, and intend to synchronize the trash like other mailboxes,
581 you should not use mbsync's Trash option at all.
582 Use of the Trash option with M$ Exchange 2013 requires the use of Dis‐
584 ableExtension MOVE due to a server bug.
585 When using the more efficient default UID mapping scheme, it is impor‐
587 tant that the MUA renames files when moving them between Maildir fold‐
588 ers. Mutt always does that, while mu4e needs to be configured to do
589 it:
590 (setq mu4e-change-filenames-when-moving t)
591
593 Changes done after mbsync has retrieved the message list will not be
594 synchronised until the next time mbsync is invoked.
595 Using Trash on IMAP Stores without the UIDPLUS extension (notably, M$
597 Exchange up to at least 2010) bears a race condition: messages will be
598 lost if they are marked as deleted after the message list was retrieved
599 but before the mailbox is expunged. There is no risk as long as the
600 IMAP mailbox is accessed by only one client (including mbsync) at a
601 time.
602
604 ~/.mbsyncrc
605 Default configuration file
606 ~/.mbsync/
608 Directory containing synchronization state files
609
611 mdconvert(1), isync(1), mutt(1), maildir(5)
612 Up to date information on mbsync can be found at http://isync.sf.net/
614 SASL mechanisms are listed at http://www.iana.org/assignments/sasl-
616 mechanisms/sasl-mechanisms.xhtml
617
619 Originally written by Michael R. Elkins, rewritten and currently main‐
620 tained by Oswald Buddenhagen, contributions by Theodore Y. Ts'o.
621 2015 Mar 22 mbsync(1)