February 2026 - dovecot

Dovecot marking outgonig emails as unread
by stef204 03 Mar '26

03 Mar '26

Starting a few days ago, I have one email account where ALL outgoing emails are automatically marked as UNREAD. The message is sent, then copied to the "Sent" folder, and has status "unread". Then, a couple of minutes later, something happens where this message gets marked as UNREAD, without ANY interaction of client side. This occurs not matter the email client used, I have tried it with multiple email clients, both local and via web interface, the behavior does not change. This is via Dovevot on Cpanel. if I look at the [1]changelog, it is difficult to identify which changes could have triggered this as there seem to be changes impacting Dovecot almost with every update. I do not control the server myself, this is on a shared hosting plan; tech support has been willing to troubleshoot but is unable to locate the problem. This problem does NOT occur on other email accounts on the same domain, so it looks to me like some corruption or problem syncing flags perhaps? I am at a loss at the moment to fix this behavior. Any suggestions or ideas welcome. Thanks. References Visible links 1. https://docs.cpanel.net/changelogs/132-change-log/

3 5

[Pigeonhole] extracttext on "message/rfc822" attachment ignores included headers
by quentinduchemin＠tuta.io 03 Mar '26

03 Mar '26

Hi everyone! I'm not sure this is a design decision, a bug, something not implemented or malformed input on my side. My use case is the following: users that forward their mails outside the domain I manage have the option to report spam as attachment so the spam classifier can learn anyway. I prefer attachment over forward because MUAs have their own way to do it and it's difficult to reliably reconstruct some headers/email structure that can be important for the spam classifier. Each input message is processed through a Sieve extensions of RFC 5703 to extract the attachment. I ask user to produce a file with .eml extension through any export-like feature of their MUA. Below is an example EML file produced by Tuta (Thunderbird does a similar thing with a different encoding for the body). I'll use a bunch of = characters as a separator in the rest of this. =============================================== [...bunch of header...] X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-0000000000 00 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYSPR04MB7035 Content-Type: multipart/related; boundary="------------79Bu5A16qPEYcVIZL@tutanota" --------------79Bu5A16qPEYcVIZL@tutanota Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXB0b3MsIEFwdG9zX0VtYmVkZGVkRm9udCwgQXB0b3 NfTVNGb250U2VydmljZSwgQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 [...base64 encoding of the body...] =============================================== While attached and sent, the received messaged looks like this: =============================================== [...headers of the actual email...] X-Infomaniak-Routing: alpha This is a multi-part message in MIME format. --------------5jyKrhQ08xXUif7LHhgg648N Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit --------------5jyKrhQ08xXUif7LHhgg648N Content-Type: message/rfc822; name="a.eml" Content-Disposition: attachment; filename="a.eml" Content-Transfer-Encoding: 7bit [...headers of the spam....] Subject: Re: //Re: AI + Ranking /// Thread-Topic: //Re: AI + Ranking /// [....] Content-Type: multipart/related; boundary="------------79Bu5A16qPEYcVIZL@tutanota" --------------79Bu5A16qPEYcVIZL@tutanota Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXB0b3MsIEFwdG9zX0VtYmVkZGVkRm9udCwgQXB0b3 NfTVNGb250U2VydmljZSwgQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 [...base64 encoding of the spam....] --------------79Bu5A16qPEYcVIZL@tutanota-- --------------5jyKrhQ08xXUif7LHhgg648N-- =============================================== I face two issues: 1. Only the base64 decoded string can be retrived through foreverypart/extracttext; 2. It has a lot of newlines. - 2. is not a big deal. The original spam has a lot of HTML junk, and each line with HTML without an inner text node is stripped, but the newline is kept. I don't know if this is intended. - 1. is more of a big deal. To try to confirm that, I made an over-simplified version of the Sieve script (I skip configuration but plugins are loaded etc, please ask if useful). =============================================== [...require...] foreverypart { extracttext "eml"; debug_log "PART ============================== ${eml}"; } =============================================== mail_debug is activated. In the logs, I can read: =============================================== Info: sieve: DEBUG: PART ============================== Info: sieve: DEBUG: PART ============================== Info: sieve: DEBUG: PART ============================== Info: sieve: DEBUG: PART ============================== Info: sieve: DEBUG: PART ============================== Info: sieve: Info: sieve: Info: sieve: Info: sieve: Info: sieve: Info: sieve: Info: sieve: Hello, Info: sieve: Info: sieve: Hope you're doing well. Info: sieve: Info: sieve: Info: sieve: Info: sieve: Info: sieve: Would you like attract more traffic with our AEO + GEO + SEO services. AI-driven search is here—don’t miss out. =============================================== So multiple parts are analyzed but only the last gives something. The RFC says that "If the transfer encoding or character set is unrecognized by the implementation or recognized but invalid, an empty string will result.". But it's over my knowledge. I activated trace for Sieve with "matching" level, and the file looks like (this is another test but was the same result): =============================================== Sieve trace log for message delivery: Username: REDACTED Session ID: ozNMOEPNl2nlAAAAO14Lzw Sender: REDACTED Final recipient: REDACTED Default mailbox: INBOX ## Started executing script 'move-spam' 33: foreverypart loop begin 33: loop ends at line 36 35: extracttext command 36: assign 'eml' [0] = "" 36: debug_log "PART ============================== " 36: foreverypart loop end 36: switched to next message part 36: looping back to line 35 35: extracttext command 36: assign 'eml' [0] = "" 36: debug_log "PART ============================== " 36: foreverypart loop end 36: switched to next message part 36: looping back to line 35 35: extracttext command 36: assign 'eml' [0] = "" 36: debug_log "PART ============================== " 36: foreverypart loop end 36: switched to next message part 36: looping back to line 35 35: extracttext command 36: assign 'eml' [0] = "" 36: debug_log "PART ============================== " 36: foreverypart loop end 36: switched to next message part 36: looping back to line 35 35: extracttext command 36: assign 'eml' [0] = "Hi, Just checking in to see if you had a chance to review my earlier message. [...body spam....] 36: debug_log "PART ============================== ????????????Hi, ?? ??Just checking in t..." 36: foreverypart loop end 36: no more message parts 36: exiting loops at line 36 ## Finished executing script 'move-spam' =============================================== Hypothesis: A. Could it be because the mail headers are indistinguishable from the part headers? B. Or is it related to Pigeonhole not implementing yet the enclose extension, which do this the other way? I hope this message is not too hard to read with all the code/logs. Please tell me if there is a better way of doing it. And thanks in advance for any help, because I don't really know what to do and trying to take a (superficial) look at the Pigeonhole code didn't helped.

1 2

Panic: file imap-sieve-storage.c: line 216 (imap_sieve_add_mailbox_event): assertion failed: (ismt->src_box == NULL || ismt->src_box == src_box)
by Christian Kivalo 28 Feb '26

28 Feb '26

Reposting my reply from a few days ago to a thread with the same panic message. I found this in my logs when some mails that got deleted on the phone were still visible in roundcube. I currently have three users that trigger the panic. One user with an iPad accounts for nearly all of the panics. The problem shows when the account is accessed from android (thunderbird) or ipad. The same accounts show no problems when beeing used with roundcube or thunderbird on windows. I enabled core dumps on 2026-01-14 and have ~8500 core dumps of the imap binary until now. What causes this error and how can I fix it? In the logs all I see is the users login, then the panic. # doveconf -n # 2.4.2-2+debian13 (0962ed2104): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.2-2+debian13 (767418c3) # OS: Linux 6.12.0-custom.kvm x86_64 Debian 13.3 ext4 2026-01-13T21:44:32.317609+01:00 uschi dovecot: imap-login: Logged in: user=<user(a)example.com>, method=PLAIN, rip=<IP1>, lip=<IP2>, mpid=4194077, TLS, session=<cpkID0tId7dUc9rl> 2026-01-13T21:44:38.455379+01:00 uschi dovecot: imap(user(a)example.com)<4194077><cpkID0tId7dUc9rl>: Panic: file imap-sieve-storage.c: line 216 (imap_sieve_add_mailbox_event): assertion failed: (ismt->src_box == NULL || ismt->src_box == src_box) 2026-01-13T21:44:38.458755+01:00 uschi dovecot: imap(user(a)example.com)<4194077><cpkID0tId7dUc9rl>: Error: Raw backtrace: #1 [unw_get_proc_name() failed: -10] -> #2 [unw_get_proc_name() failed: -10] -> #3 i_panic[0x7f6b6c46c2f6] -> #4 [unw_get_proc_name() failed: -10] -> #5 [unw_get_proc_name() failed: -10] -> #6 [unw_get_proc_name() failed: -10] -> #7 mailbox_save_alloc[0x7f6b6ca103c0] -> #8 [unw_get_proc_name() failed: -10] -> #9 command_exec[0x55654e677400] -> #10 [unw_get_proc_name() failed: -10] -> #11 [unw_get_proc_name() failed: -10] -> #12 [unw_get_proc_name() failed: -10] -> #13 client_handle_input[0x55654e67ddc0] -> #14 client_continue_pending_input[0x55654e67e0b0] -> #15 io_loop_call_io[0x7f6b6c565490] -> #16 io_loop_handler_run_internal[0x7f6b6c567230] -> #17 io_loop_handler_run[0x7f6b6c5673c0] -> #18 io_loop_run[0x7f6b6c5675a0] -> #19 master_service_run[0x7f6b6c4b27f0] -> #20 main[0x55654e6688a0] -> #21 [unw_get_proc_name() failed: -10] -> #22 __libc_start_main[0x7f6b6c234ce0] -> #23 _start[0x55654e668eb0] 2026-01-13T21:44:38.459536+01:00 uschi dovecot: imap(user(a)example.com)<4194077><cpkID0tId7dUc9rl>: Fatal: master: service(imap): child 4194077 killed with signal 6 (core dumps disabled - https://dovecot.org/bugreport.html#coredumps) # coredumpctl dump PID: 1071230 (imap) UID: 5000 (vmail) GID: 5000 (vmail) Signal: 6 (ABRT) Timestamp: Fri 2026-01-16 19:17:15 CET (2s ago) Command Line: $'dovecot/imap [user(a)example.com <IP redacted> UID MOVE]' Executable: /usr/lib/dovecot/imap Control Group: /system.slice/dovecot.service Unit: dovecot.service Slice: system.slice Boot ID: 3668d179bda340229a780d5d43e426c3 Machine ID: 05698baa30ae984c9bd014566e16da18 Hostname: uschi Storage: /var/lib/systemd/coredump/core.imap.5000.3668d179bda340229a780d5d43e426c3.1071230.1768587435000000.zst (present) Size on Disk: 1.1M Message: Process 1071230 (imap) of user 5000 dumped core. Module libgcc_s.so.1 from deb gcc-14-14.2.0-19.amd64 Module libstdc++.so.6 from deb gcc-14-14.2.0-19.amd64 Module libzstd.so.1 from deb libzstd-1.5.7+dfsg-1.amd64 Stack trace of thread 1071230: #0 0x00007fbd1ca9f95c n/a (libc.so.6 + 0x9495c) #1 0x00007fbd1ca4acc2 raise (libc.so.6 + 0x3fcc2) #2 0x00007fbd1ca334ac abort (libc.so.6 + 0x284ac) #3 0x00007fbd1cc6caa0 n/a (libdovecot.so.0 + 0x6caa0) #4 0x00007fbd1cd49e67 n/a (libdovecot.so.0 + 0x149e67) #5 0x00007fbd1cc6c3d0 i_panic (libdovecot.so.0 + 0x6c3d0) #6 0x00007fbd1c42f942 n/a (lib95_imap_sieve_plugin.so + 0x4942) #7 0x00007fbd1c431223 n/a (lib95_imap_sieve_plugin.so + 0x6223) #8 0x00007fbd1d258f10 n/a (libdovecot-storage.so.0 + 0x11bf10) #9 0x00007fbd1d1a843b mailbox_save_alloc (libdovecot-storage.so.0 + 0x6b43b) #10 0x00005590b7ed4a69 n/a (n/a + 0x0) ELF object binary architecture: AMD x86-64 -- Christian Kivalo

5 12

LDAP AD Quota override not working
by wt.forsaken＠gmail.com 26 Feb '26

26 Feb '26

Hi there, I'm testing the new version of Dovecot 2.4 in Debian 13 before upgrading to my customers and I'm having difficult on trying to override the user's quota. The LDAP base is from Samba4 AD and having been trying the following configuration: auth-ldap.conf.ext: ldap_uris = ldap://localhost ldap_auth_dn = cn=admin,dc=localdomain ldap_auth_dn_password = password ldap_base = ou=users, dc=localdomain passdb ldap { filter = (&(objectClass=person)(sAMAccountName=%{user})) bind = yes fields { userdb_quota_storage_size = %{ldap:telephoneNumber}B } } userdb prefetch { driver = prefetch } userdb ldap { fields { quota_storage_size = %{ldap:telephoneNumber}B } } 90-quota.conf mail_plugins { quota = yes } quota "User quota" { } quota_storage_size = 40M Since there is no quotaBytes in Samba AD, I'm testing to map the telephoneNumber parameters to override the quota, also I'm just testing a 40M to see how it works. Roundcube webmail can see the quota being overriden in its inferior bar, but when I send an email to the user which is above the quota, the journal log inform "failed to store into mailbox 'INBOX': Quota exceeded (mailbox for user is full)". I don't know how to override the quota, since in passdb section I used the "userdb_" prefix but it is not being passed to userdb when I input the "doveadm user ..." command. I don't know if I have been clear in my request, but I'd appreciate any help.

3 3

Dovecot 2.4 LMTP socket for Postfix / Dovecot base_dir not created upon restart
by Philip Iezzi 24 Feb '26

24 Feb '26

Hi there, After over a week of Dovecot 2.3 -> 2.4 upgrade testing in various mailserver clones, I am now ready for the big picture. Thanks Aki for the Config Upgrader https://dovecot.org/upgrader/ which helped a lot! Tomorrow, I am planning to upgrade a larger mailserver in these 3 steps: 1) Debian Bullseye / Dovecot 2.3.21 => 2.4.1 2) Debian Bullseye => Bookworm / Dovecot 2.4.1 => 2.4.2 3) Debian Bookworm => Trixie Postfix needs to talk to Dovecot over LMTP, using the following in main.cf: virtual_transport = lmtp:unix:/run/dovecot/lmtp Now, while testing this in a full server clone, I stepped over my planned LMTP server setup: =============================================== service lmtp { unix_listener /run/dovecot/lmtp { mode = 0666 user = postfix group = postfix } } protocols = imap pop3 sieve lmtp =============================================== The socket needs to be owned by postfix:postfix for some (security) reasons, otherwise Postfix complains. That's why I cannot go with the default, as documented here: https://doc.dovecot.org/2.4.2/core/config/delivery/lmtp.html#lmtp-server > The UNIX listener on $base_dir/lmtp is enabled by default when protocols setting contains lmtp. But, when using an absolute path on unix_listener, upgrade step 2) Bullseye=>Bookworm breaks with: Processing triggers for dovecot-core (2:2.4.2-2+debian12) ... Job for dovecot.service failed because the control process exited with error code. (...) dovecot[34446]: master: Error: service(lmtp): Socket already exists: /var/run/dovecot/lmtp dovecot[34446]: master: Fatal: Failed to start listeners I then moved to `unix_listener lmtp`: service lmtp { unix_listener lmtp { mode = 0666 user = postfix group = postfix } } Bookworm upgrade (restarted from scratch with a fresh server clone) went through fine. But even after several dovecot.service restarts, the socket ended up in /run/lmtp without creating the /run/dovecot directory, and after a full system reboot, it was suddenly back where I have expected it: /run/dovecot/lmtp I never changed base_dir, which defaults to /var/run/dovecot/ So, here's my question: Is that really the recommended setup (using `inet_listener lmtp` instead of an absolute path) and how can I trust Dovecot to always create the socket in $base_dir/lmtp as documented? Are you guys aware of this issue or was it just me, a temporary hiccup on my just upgraded server? I just found this in mail.log: dovecot: master: Error: bind(/var/run/dovecot/lmtp) failed: No such file or directory dovecot: master: Error: service(lmtp): net_listen_unix(/var/run/dovecot/lmtp) failed: No such file or directory dovecot: master: Fatal: Failed to start listeners Again, this problem seems to have occurred both with `unix_listener /run/dovecot/lmtp` and `unix_listener lmtp` and only resolved after a full system reboot. Thanks, Philip

2 2

Migrating a mailbox from v2.2 to v2.4, production server to pre-production server.
by Mike 23 Feb '26

23 Feb '26

I'm migrating a mailbox from dovecot v2.2 to v2.4. Not that it matters, I'm also changing from mbox to Maildir. As an initial test I used this command: sudo doveadm sync -1D -u theuser -m amailbox remote:theuser@destination.com I received this error: Error: doveadm: Unexpected or incomplete option: -U After changing the dsync_remote_cmd to: dsync_remote_cmd = ssh -l%{login} %{host} doveadm dsync-server -u%u I was able to transfer the mailbox without issue. Before changing it, the setting on the source server was: dsync_remote_cmd = ssh -l%{login} %{host} doveadm dsync-server -u%u -U I'm interested to discover what the -U was intended for since I couldn't find specific documentation to its use. I'll accept that it was a legacy thing and removing it won't cause any unintended consequences...but I do still have that curiosity about what it was for. Additionally, the subscription status doesn't seem to flow to the new server. When checking the source server with: doveconf -d | grep subscriptions doveconf -n | grep subscriptions No value is returned...So I'm wondering if I need to specifically set subscriptions = yes in the source server to make this happen properly. Maybe this is an artifact of using sync -1? Thanks for any insight you may provide. Mike

1 0

Localhost Dovecot server without ssl?
by Steve Litt 23 Feb '26

23 Feb '26

Hi all, I'd like your opinions to add to my own opinion. Bottom line question: If I trust everybody with physical access to my Daily Driver Desktop (DDD) computer, my Dovecot IMAP runs on my DDD, I access my Dovecot IMAP *exclusively* from my DDD, and I trust everybody with physical access to my DDD (that would be my wife), then if I serve out IMAP on localhost (127.0.0.1), am I being unduly risky using plain text auth (port 143)? Details: I use a Dovecot IMAP server, on my DDD, specifically to hold all my email messages. Therefore, I can use any IMAP aware email client, interchangeably, to view every email I've received since April 2001. People whose emails are held by their email clients are "locked in" to their email client unless they convert their email data. I can switch between Evolution and Claws-Mail, because one of the two is always doing something stupid. Bottom line: I use Dovecot IMAP exclusively to hold my emails and folders. Graphical description below: ISP ---> My --------> procmail --> Dovecot IMAP fetchmail Maildir | | V email <--- Dovecot client IMAP server For the time being, I don't need to access my Dovecot IMAP from any computer except my DDD, and therefore, I can serve Dovecot IMAP on 127.0.0.1. So here's my question. Assuming (and I know this is a big assumption) I'm not worried about somebody gaining physical possession of my DDD, is there any reason not to use plain text to access this server? Thanks, SteveT Steve Litt http://444domains.com

2 1

Copies/duplicates of Dovecot indices
by Joseph Tam 23 Feb '26

23 Feb '26

In my setup, I put mail indices outside the user's mailbox locations (user mailboxs are NFS, indices stored local attached storage). I notice that sometimes, there are 2 sets of indices representing the same mailbox: one at top level, one underneath .imap/. (They usually appear in the latter.) For example, if I have the configuration (Dovcot version 3.2.21) mail_location = mbox:~/mail:INBOX=/nfs/mail/%n:INDEX=/cache/%n I see for a particular user [1] drwx------ 5 user group 512 Feb 22 21:56 /cache/user/box [2] drwxr-xr-x 5 user group 512 Feb 22 21:46 /cache/user/.imap/box cooresponding to their mailbox in ~user/mail/box. Each of these have the dovecot.* index files. If I delete [1], it comes back. The timestamps are close to each other so both sets are being used, possibly by different clients. Another quirky discovery is 2 /.imap/ folders beneath each other e.g. /cache/user/.imap/folder1/folder2/.imap/box/dovecot.index What determines which index pathname gets created or used? Joseph Tam <jtam.home(a)gmail.com>

1 0

2.3 replication issue throwing errors
by Paul Kudla 22 Feb '26

22 Feb '26

shows same error on both servers Server 1 : # sync faye(a)scom.ca doveadm(faye(a)scom.ca)<90952><BJq9J2dHmGlIYwEA0dxyZQ>: Warning: Mailbox changes caused a desync. You may want to run dsync again: Remote lost mailbox GUID f982a82747469869ea0f0100cf58dcff (maybe it was just deleted?) Server 2: # sync faye(a)scom.ca doveadm(faye(a)scom.ca)<90952><BJq9J2dHmGlIYwEA0dxyZQ>: Warning: Mailbox changes caused a desync. You may want to run dsync again: Remote lost mailbox GUID f982a82747469869ea0f0100cf58dcff (maybe it was just deleted?) i am aware there is a mismatch on one of the servers but there does not seem to be a clear cut way to find the offending file to delete it or force a backwards sync ? How would i identify what GUID f982a82747469869ea0f0100cf58dcff means? same on both servers. doveadm force-resync -u faye(a)scom.ca '*' have tried reindex etc etc etc issue persists logs ?? mail18 02-20 06:45:24 {dovecot} [67632] (3014654310) doveadm(faye(a)scom.ca)<71073><hOl0ClRJmGmhFQEAz1jc/w>: Debug: open(/proc/self/stat) failed: No such file or directory mail18 02-20 06:45:24 {dovecot} [67632] (3014654311) doveadm(faye(a)scom.ca)<71073><hOl0ClRJmGmhFQEAz1jc/w>: Debug: open(/proc/self/io) failed: No such file or directory mail18 02-20 06:45:24 {dovecot} [67632] (3014654312) doveadm(faye(a)scom.ca)<71073><hOl0ClRJmGmhFQEAz1jc/w>: Debug: Namespace inbox: type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:~/ any help would be appreciated -- Thanks - Paul Kudla (Manager SCOM.CA Internet Services Inc.) Have A Happy Friday AND Happy Sucessful 2026 ! Scom.ca Internet Services <http://www.scom.ca> 104-1009 Byron Street South Whitby, Ontario - Canada L1N 4S3 Toronto 416.642.7266 Main 1.866.411.7266 Fax 1.888.892.7266 Email paul(a)scom.ca

2 2

How do you use doveadm fetch -S
by Steve Litt 20 Feb '26

20 Feb '26

Hi all, I have a working plain text 127.0.0.1:143 Dovecot 2.4.2 on my Qemu VM guest. The following command displays the Receive date, From and Subject for every email in my golugTech mailbox, exactly like the docs say it should: =================================================== doveadm fetch -u slitt "date.received hdr.from hdr.subject" mailbox golugTech =================================================== But when I add the -S in order to specify the 127.0.0.1 listener at port 143, it throws the following error: =================================================== [slitt@mydesk ~]$ cat junk.jnk [root@dovecotvoid dovecot]# doveadm fetch -S 127.0.0.1:143 -u slitt "date.received hdr.from hdr.subject" mailbox golugTech doveadm(slitt): Error: conn 127.0.0.1:143 (127.0.0.1:143): doveadm server sent invalid handshake: * OK Waiting for authentication process to respond.. doveadm(slitt): Error: cmd fetch: 127.0.0.1:143: Command fetch failed for slitt: Connection closed [root@dovecotvoid dovecot]# [slitt@mydesk~]$ =================================================== The docs say -S is to specify the socket_path, and it should be expressed as hostname:port. For hostname, besides 127.0.0.1, I tried localhost and dovecotvoid, the latter of which should not work because dovecotvoid is not 127.0.0.1, it's 10.0.2.15. The docs say "This allows an administrator to execute doveadm(1) mail commands through the given socket." So I guess finding the server isn't the purpose of socket_path. My plain text 143 Dovecot 2.4.2 IMAP works just fine without the -S. Is there ever a case where doveadm fetch would need to know the specific address and port of the dovecot IMAP server, and if so, how would I specify it? Thanks, SteveT Steve Litt http://444domains.com

2 1