Need Help with AppleMail Persistent Crash

TidBITS Talk
1

I’m hoping people here can help me fix this–AppleCare Level 2 wasn’t much help.
Hardware:
27-in. 2020 Intel iMac
Ventura 13.7.8 (yes, I have a reason for sticking with Ventura for now)
Yes, it’s plugged into a UPC

House power went out; I shut down Mac normally while it was running on UPC power, but did not manually shut down Mail first (in case that matters). Mail had several emails open on desktop, and (somewhere) it’s set to restore whatever state it’s in when I close it.

Power came back on; I rebooted, then opened Mail.

Mail opened normally for about 20 seconds, then crashed while restoring previously open emails, etc.
I’ve run through all the obvious things to try, up to and including re-installing Ventura, but Mail always crashes at one of the same two points. I know just enough to spot that in the crash reports, but not enough to know what it actually does or how to fix it.

Thread that crashes involves MFEWSPeristenceTaskHandler, OR–
When I’ve just done a cold reboot, it’s always IMAPNetworkTaskHandler.
Here are the summaries for both those situations, followed by links to the full reports.

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               Mail [4411]
Path:                  /System/Applications/Mail.app/Contents/MacOS/Mail
Identifier:            com.apple.mail
Version:               16.0 (3731.700.6.1.21)
Build Info:            Mail_App-3731700006001021~2
Code Type:             X86-64 (Native)
Parent Process:        launchd [1]
User ID:               502

Date/Time:             2026-03-19 13:15:37.1282 -0700
OS Version:            macOS 13.7.8 (22H730)
Report Version:        12
Bridge OS Version:     9.6 (22P6083)
Anonymous UUID:        08AE973F-3199-47AC-836D-A1B29DA8DB23


Time Awake Since Boot: 10000 seconds

System Integrity Protection: disabled

Crashed Thread:        44  Dispatch queue: MFEWSPersistenceTaskHandler queue (QOS: BACKGROUND)

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process:   Mail [4411]

Application Specific Information:
abort() called

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               Mail [4271]
Path:                  /System/Applications/Mail.app/Contents/MacOS/Mail
Identifier:            com.apple.mail
Version:               16.0 (3731.700.6.1.21)
Build Info:            Mail_App-3731700006001021~2
Code Type:             X86-64 (Native)
Parent Process:        launchd [1]
User ID:               502

Date/Time:             2026-03-19 13:10:37.8559 -0700
OS Version:            macOS 13.7.8 (22H730)
Report Version:        12
Bridge OS Version:     9.6 (22P6083)
Anonymous UUID:        08AE973F-3199-47AC-836D-A1B29DA8DB23


Time Awake Since Boot: 9800 seconds

System Integrity Protection: disabled

Crashed Thread:        14  Dispatch queue: IMAPNetworkTaskHandler queue (QOS: BACKGROUND)

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process:   Mail [4271]

Application Specific Information:
abort() called

Dropbox Link to Full Report–MFEWSPersistenceTaskHandler.txt
Dropbox Link to Full Report–IMAPNetworkTaskHandler.txt

Can anyone figure out what’s actually failing here? And is there a straightforward (e.g., command-line) solution? I’m comfortable entering commands via Terminal, but would need to know the exact command(s) to enter. And for various reasons, relying on email-via-browser (or my phone) is a stopgap at best.

Many thanks for your thoughts, suggestions, etc!
Levanah

2

It certainly sounds like Mail is failing when it tries to contact your IMAP provider. What happens if you turn off Wi-Fi and make sure your Mac can’t connect to the Internet?

If you can get Mail to launch without network access, it would be interesting to see what happens when you re-enable access.

Another interesting data point might come from testing Mail with a clean setup in another user account on your Mac.

The other workaround I can think of would be to try a different email app. I’m not entirely sure what works on Ventura, and it might depend a little on your email provider’s setup too (Gmail vs standard IMAP), but there are options like Outlook, Thunderbird, MailMate, and Spark.

3

Interesting! I tried your suggestion, and Mail launched just fine, and I have full access to all my email that’s already downloaded (including OnMyMac mailboxes). Turning Wi-Fi back on with Mail still open crashes it again immediately, showing the IMAPNetworkTaskHandler error. So, any ideas on how to fix?

Re other email apps: I have several different email accounts & providers (for business & historical reasons), mostly standard IMAP, but also Gmail and Outlook. I’ve had all my accounts operating well via Mail + MailTags, since ~2008. I’m considering (planning) to switch over to MailMaven when it’s really stable, but need Mail to work again first.

4

I don’t want to post the full, lengthy AI dump but ChatGPT suggested the following:

That IMAPNetworkTaskHandler error on an older iMac (typically in Apple Mail) is a fairly common “catch-all” failure — it usually points to a breakdown in connection, authentication, or TLS compatibility, especially on older macOS versions.

Here’s how to systematically fix or bypass it :backhand_index_pointing_down:

:wrench: Most Common Causes (on older iMacs)

  1. Outdated TLS/SSL support
  • Older macOS versions (El Capitan, Sierra, etc.) may not support modern email server security requirements.
  1. Incorrect mail settings
  • Ports, SSL settings, or authentication mismatches.
  1. Account authentication issues
  • Especially with Gmail, Outlook, iCloud (OAuth changes).
  1. Corrupt Mail cache / keychain
  • Apple Mail can break silently.
  1. Server blocking “less secure” clients
  • Gmail in particular tightened this in recent years.

You could probably ask it to diagnose the entire crash log if you want to investigate deeper. I simply asked about the main error and it did post several steps to try to resolve, but as I said earlier, I don’t want to do a ‘massive dump’ here.

5

So the next test is to see if you can get Mail in another account to work.

If that crashes as well, the culprit is almost certainly something in a message, so I’d log in with a webmail app if possible, and see about deleting unnecessary messages right after the last ones you can see in Mail with connectivity disabled.

6

If the account(s) are IMAP or Exchange (Gmail, Outlook, etc.) rather than POP3, I think I’d suggest just deleting the accounts and setting them up again.

1 Like
7

Followup: Using “Guest User,” Mail opens with a “setup account” popup.

  1. I set up my Yahoo account (using the auto-setup popup). Account shows as “offline”; Connection Doctor shows I’m connected to the SMTP server, but not the IMAP server.

  2. I set up one of my "vanilla” IMAP accounts manually, trying both thru Mail, and thru System Settings. In both cases, “Could not verify user name or password”. –>The settings I used are working perfectly on my phone BTW.

Re a corrupt email: This issue started first on my laptop, then ~1 week later on my desktop, so I don’t think a corrupt email is the issue. I can access all my email accounts using a browser BTW.

I will try trilo’s suggestion re ChatGBT, and if need be, go through deleting & re-adding all my email accounts later today if possible.

8

Hadn’t thought of that. Corrupt cache/keychain seems possible. I’ll try asking ChatGBT about the whole crash log later today if I have time. Thanks!

9

I’m a little perturbed that you don’t seem to be able to set up the accounts again—I guess it’s not inconceivable that there’s something funny about being in a Guest account rather than a normal user account. But if you can’t set up the accounts from scratch, you definitely don’t want to delete them until you can prove that you can set them up again.

Try another app first.

1 Like
10

Who is your email provider?

That might make a difference, particularly on an older version of the OS, and an email provider (such as Yahoo or other entities that have contracted with Yahoo to provide email services, such as Comcast and Frontier) that requires more “modern” types of authentication that Ventura doesn’t have.

Can you access your email provider using a browser-based interface?
If so, and if you can remember the emails that were open at the time of the outage, I’d go there and do -something- with those emails – move them, archive them, delete them, etc.

Then try opening Mail again…

11

In a similar failure…my up to date Tahoe M4 Pro MBP frequently has Mail crash when I click the delete button…nothing useful in the crash report. Same Mail server and settings I’ve been using for going on 20 years but the crashes started with the first couple updates to Tahoe. Disk Utility, rebuild mailbox envelope index, nothing has helped.

12

Yes, I can access all my providers via browser. They are:
Yahoo IMAP
Gmail IMAP
Exchange/Outlook – this is via GoDaddy’s connection to Microsoft 365, not at all by my choice BTW
Earthlink (very vanilla IMAP)
ChatGPT was pointing me here:
**********************************************
This is the key insight:
:collision: The crash is NOT specific to Exchange or IMAP
Because:
• It happens on both EWS and IMAP accounts
• It happens during message body access
• It always involves MailTags hooking into rule evaluation

You now have two independent crash paths (EWS + IMAP) with:
• Same failing method (_dataPathForMessage)
• Same operation (body fetch during rules)
• Same injected code (MailTags)
:backhand_index_pointing_right: That’s about as definitive as it gets:
MailTags is causing Mail to crash when processing certain messages.

**********************************************
The Chat was then offering to help me isolate which message, or if necessary, remove MailTags but retain the tags – but then unfortunately it wanted me to create an OpenAI account, which I did, thus losing the previous chat thread. (I did save it locally & will try re-entering it.)

Adam, thanks for the warning re deleting/re-creating an email account – I’ll leave that idea alone for now.

13

If you are confident in the log analysis’ identification of MailTags as the source of the error, I suggest contacting MailTags support about the issue.

Sometimes AIs can be useful for log analysis, but often they’re not. I’ve had very mixed results using a variety of AIs to review logs. Probably at least half the time, I’ve had experiences that more closely resemble Harold Oakley’s result than those that have reached a successful outcome.

Just last week, I asked an AI to try to analyze a web server log to identify suspicious activity. It generated a detailed set of possibilities, one of which did turn out to be indirectly related to the root cause, but it missed the series of sequential, unauthenticated, successful password resets for multiple accounts that appeared in the log. When I asked the AI why it ignored those lines, it literally responded with “Now that you mention it, those entries do look suspicious.” In other words, had I relied on AI instead of me actually reading through the log, I probably would have missed the moment of compromise. (FWIW, the compromise was caused on day zero of a zero-day exploit in a third-party user management plugin.)