Yes. We have one user that gets this intermittent.

Somehow it looks like characters or content thats triggering this behaviour.

Manually copying the outgoing mails to a local folder on the desktop and sending them one by one, solves the issues.

I havent made a ticket yet but about to if it happens again.

Hi Brian!

The same workaround works for us, but I have several users (not just one) with the same behavior and I can't tell everyone to continue like this...

I think that UNFORTUNATELY I will have to think about downgrading and going back to the 8664...

Have you looked for errors on the server or tried new user profiles in Outlook??

YES.

In the MAPI logs there are many exceptions (nothing before the update...).

Tested to reset and recreate profiles in Outlook, but the problem remains...

Tonight I'm forced to downgrade because the customers are angry, so I can't even open a ticket because I don't have time to do any more tests or copy the system to put it on a test VM.

HAve you reported that to support??

No... Unfortunately, since I am forced to downgrade almost immediately, I don't have the material time to open a ticket and give SmarterTools time to connect and do tests and checks...

Opened a ticket for this 3B6-2D4D405F-0B21 and I will let you know the proceedings.

Tony replied

So far the best way to cleanup the issue has been to run /cleanrules on the users outlook install.
•    outlook.exe /cleanrules
•    https://support.microsoft.com/en-us/office/command-line-switches-for-microsoft-office-products-079164cd-4ef5-4178-b235-441737deb3a6
Can you give this a try and see if this resolves the issue. If it does not we can continue to troubleshoot.

Yes, I have this problem too. I don't believe I had it with 8664 either.

I have been working with Kyle from SmarterTools via a support ticket.

If I save any stuck message (the oldest one in the outbox when the outbox is stuck) as a .eml file and open it with a text editor and scroll down, I notice every stuck message (at least every one of several I checked) has an attachment called "winmail.dat". I spot checked several messages that sent normally and none of them had this attachment. Maybe this is related.

Kyle says SmarterMail doesn't support winmail.dat (proprietary Outlook format for RTF messages.), but I don't know why Outlook is making them. I tried to save an example of one of the stuck messages as a .msg file from an affected user's Outlook, copy it to my computer, and send the .msg file as an email attachment from my computer, and that email (a new email from me that had the other user's stuck message as a .msg attachment) caused MY outbox to get stuck (I have never had this problem on my account otherwise). So it seems like something is definitely broken with these messages, or at least SmarterMail doesn't like them.

Some of our affected users have additional accounts in their Outlook profile that are set up as POP--I tried chaning them all to MAPI (Kyle recommended trying to switch them to MAPI or IMAP) several days ago and haven't heard any more complaints from users yet about stuck messages, buit I'll watch it for a while longer since sometimes it takes a little while to happen.

Slightly off-topic. I remember back about 25 years ago where a client of mine (non-hosting) had their email service down for nearly a week. They were a little upset but in 1998 it wasn't the end of the world, unlike now when nearly any email interruption is a (perceived) disaster!

Thanks Brian. I did check those settings and they're set to:

Compose messages in this format: HTML

When sending messages in Rich Text format to Internet recipients: Convert to HTML format

Also in the respond settings??

One thing isn't clear to me

Are we talking about MAPI users?

Yes, only MAPI users

Had this problem on several users.  I'm on 8776.  What has solved it for me is throttle mail to keep offline to less time, allow Outlook to adjust, and then throttle it back.

I can confirm that downgradingo fron 8790 to 8706 have solved this issue (all customers confirm that they are working fine now).

For SmarterTools: are you aware of this bug?

For Brian Bjerring-Jensen: have you been answered for you ticket n° 3B6-2D4D405F-0B21?

They have released version 8797 but from changelog, that bug doesn't seem solved.

UPDATE: another customer reports the same problem to me with the 8790 (small on premise installation with 1 domain and 17 users, all MS Outlook 2019 with MAPI...).

To check, I'll try upgrading to the 8797 to see if this solves the problem.

This is the reply I made to the ticket

ent: Wed, 31 Jan 2024 12:33:41 -0700
To: Support
Subject: MAPI issues messages stuck in outbox

Have instructed the user to use Convert to HTML when replying to an email and to see if the issue persists.

It seems to be related to RTF replies in Outlook.

All my users were already using HTML... I checked it myself.

I'm waiting for more feedback on 8797, but it seems to work better...

Finger crossed!

But its the replies that is the issue me thinks. Not the composition of emails...

Replies settings im Outlook have "convert RTF to HTML" enabled...

EDIT: I have e to add that no users had this issue before updating from  8664/8706 to 8790... And downgrading to 8706/8664 again make Outlook work fine immediately.

So I doubt it's an Outlook fault...

Hope that 8797 will be the solution, but I'm not sure...

I have exact the same problem (currently 8768 installed). Here is the log:

 

[2024.02.06] 13:48:40.313 [{xxxxxxxxxxxxxxx}:24] [offfice@xxxxx.xxx] Exception: System.NotSupportedException: Invalid property value type.
[2024.02.06]    at SmarterMail.Common.WinMail.WinMailWriter.WritePropertyValue(Object value)
[2024.02.06]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.MapiMimeWriter.CreateWinMailDatFile(PidPropertyDictionary messageProperties, Guid tnefKey, ValueTuple`2 embeddedMessage, WinMailWriter writer, Encoder encoder, PidProperty pidTagMessageClass, List`1 recipients, Boolean isRequest, List`1 embeddedAttachments)
[2024.02.06]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.MapiMimeWriter.CreateSimpleWinMailDatFile(PidPropertyDictionary messageProperties, Guid tnefKey, ValueTuple`2 embeddedMessage)
[2024.02.06]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.MapiMimeWriter.CreateMimeKitMessage(PidPropertyDictionary messageProperties, List`1 attachmentEntries, List`1 recipientEntries)
[2024.02.06]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.MapiMimeWriter.CreateMessage()
[2024.02.06]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.EmailHandle.GetMimeFromHandle(MapiFolderContextData folderContext, String sentRepresentingEmailAddress, String sentRepresentingDisplayName, Boolean& attachmentModified, Boolean& importing, Mailbox mailbox, Boolean fromSend, Boolean sendingOnBehalfOf)
[2024.02.06]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.EmailHandle.SendNow(MapiContext context)
[2024.02.06]    at SmarterMail.Protocols.MAPI.Rops.TransportRops.RopTransportSend.Process(List`1 payloadServerObjectHandleTable)
[2024.02.06]    at SmarterMail.Protocols.MAPI.RequestTypes.ExecuteRequest.Process()
[2024.02.06]    at SmarterMail.Protocols.MAPI.MapiProcessor.Process()

i am really angry that every new release something is buggy/not working. our customers are going to MS365 (and i have nothing to offer for them) - they do not want to be beta testers....

greetings 

Rudolf

Agreed Rudolf.

On build 8776.  Had a few more instances of this MAPI problem on several different version of Outlook (2016/2019).   Issue only appeared since update from 8629.  Originally I thought changing how much mail was offline worked.  Turns out not to be the case.

If user has, say, 10 emails stuck in the outbox I have had some luck getting them to send by opening the emails in outbox and trying to send them one by one.  Eventually I hit one that sends and then they all go by themselves.

Guessing one email that SM is having difficulty with is blocking everything in the queue.

It is like that.

And there is no logic to whats the issue.

Copying them to a folder on the desktop as .msg and opening them one by one and hit send, they go away as normal as well.

Have you updated to the new 8979? If yes, do you still see this issue?

Not yet. Waiting for feedback. I am tired of all the problems all the time.... basic shit is not working and clients are going to O365 for that reason.

Basic things are missing compared to Exchange.... me not 100% happy.

I quite agree with you, Brian, but I'm still hoping for some good news or at least some commentary on this issue from SmarterTool.

So far none of them have commented, so I take it that it's a hot topic...

My on premise customer who is experimenting with the 8797 says that so far he has no longer had problems with emails stuck in the Outbox.

Let's hope this problem is resolved, but wait a bit to be sure...

Anyway, there is another problem that remains (and which was also present in the 8790...):

We need to get in touch with development and make sure that this gets in the pipeline...

Right now I have a 212 user company that wants what we have, but waiting to get things right so they dont have to change the way they work compared to office365 and things like groups in Exchange.

Its frustrating.

I agree with you, Brian...

I also have several customers who are using MS Exchange (approximately 53 customers) and others who use Kerio Connect (about 30...).

For now I don't trust migrating them all to SmarterMail due to the lack of functionality compared to Exchange and also due to the various BUGS I'm seeing on this latest version...

I consider SmarterMail an excellent product (especially considering that I came from MailEnable...), which could become the definitive solution, but first it still has some way to go to:

- cover all the basic features of MS Exchange that are missing (only 3 or 4 missing, we're almost there...)

- but above all it must become REALLY stable, because at the moment these BUGS are causing me a lot of waste of time and complaints from customers...

Couldnt have stated it better. Its costing a lot of valuable time and we dont get a refund.... :)

I haven't upgraded to 8797 yet as waiting to see if a newer version is released that explicitly fixes the MAPI problem.

Maybe better way to avoid issues is to release SM like fortinet firmware does.  Have a Beta version of the software with a defined set of new functionality which is expected to be full bugs and then a General Release version that is expected to have most known bugs solved.

Upside is less bugs in the General Release software.  Downside is a much slower tempo of new functionality added to the software.

I don't know if SM has the user base to do this.

We need the rolling releases to push development forward and designated LTS releases that get necessary patches for enterprise level customers.

I find this silence from SM on the issue deafening.

I don't understand if they have replicated it, if they are working on it, if.... I don't know...

I've been dealing with MAPI and user lockouts (whether they are on AD authentication or SM authentication) the username on our network gets locked out of AD 100's of times a day. ITS INSANE. I've tried all the usual things like creating new profiles, hacking registry, making new usernames. EVERY single day I am struck by locked out issues and SmarterMail is of no help. Has anyone experienced this?

We have been a customer for 20+ years, and have not experienced such garbage customer service ever. I am dying to get this fixed for over 2 months, and at this point we are going to switch to 365 because SM is of no help. It's ridiculous, I can't even get a screen share with a tech, and if you call them, it goes straight to voicemail. 

WHAT THE HELL IS GOING ON?!?!

Joshua Rosen, 

I'm sorry you're still having trouble with your Outlook authentication, but it's not from lack of effort on our part.

 

Your ticket in November was closed due to lack of response to our attempts to engage you and the multiple follow-ups that were sent. As for the new ticket you submitted 2 weeks ago, we've been struggling to get a hold of you for a phone call or screenshare. (Your phone goes to voicemail as well.) I've replied to your support ticket directly with some time slots of availability. We are eager to help you get this resolved and look forward to getting something scheduled.

For what it's worth, I've had a ticket open for this issue for quite some time and although we haven't found the solution yet, support has been very active in ongoing troubleshooting with me, so the problem definitely isn't being ignored. I plan to install the custom build tonight and hopefully it gives some useful information.

No ma'am - we're not having issues - I apologize if this was misunderstood.  My comment was in response to another user's post about release schedules and LTS concept.  I should probably delete it since it was off topic.  My apologies.

As to the other issue - I want to take a moment and apologize for the ticket issue as well. I had tasked a technician with the followup and mitigation of that issue and I was unaware that no followup between him and you occurred.  Now that I look at our configuration - I see that the domain we had issues with then on that ticket had it's configuration changed to use external delivery (to get around the DMARC issue we had) and then walked away.  This is a failure on several levels on our end - and I am resolving several of those failures before the day is through, rest assured.

Thank you for taking the time bring this to my attention - It seems I will be personally taking over handling issues like this on our end for the foreseeable future.

I will reach out next week to look into clearing all this up (the past ticket issues) via email/support.  For the interim time being we are up and running - and not having immediate issues we are unable to resolve.

Just so we're all on the same page...

Some issues are simple enough to get resolved, others take longer. This is especially true when we are unable to replicate an issue, such as this one, or when people stop responding. We don't doubt that something is going on, it's just that without the ability to SEE the issue occurring, and being able to replicate the issue, we have to take alternate routes. That includes things like Builds with extended logging, using tools like Wireshark, etc. These routes, however, take time, and then there's no guarantee that even these will find the cause. Whenever possible we send custom Builds to help narrow down, if not outright resolve, an issue. 

For the record, my experience with Build 8797 is very good.

1) We had problems with users being blocked from Webmail (supposedly invalid credentials) but able to log in with EAS and MAPI.   All of our users use Active Directory authentication.    Build 8797 said that it fixed the problem and it did.

2) We had two users with messages getting stuck in Outlook.   I followed the support recommendation to launch Outlook with the /CleanRules option, even though the suggestion made no sense and the users had no configured outlook rules.   (Documentation says that it will remove all rules, so users with rules should be aware.)    No new reports of messages stuck in Outlook.   SM Support did say that this switch has been a useful solution to strange Outlook problems for some time, not just this time around.

And no new problems introduced.

[2024.02.08] 11:39:17.291 [{xxxxxxxxxxxxxxx}:18] [office@xxxx.xx] Exception: System.NotSupportedException: Invalid property value type.
[2024.02.08]    at SmarterMail.Common.WinMail.WinMailWriter.WritePropertyValue(Object value)
[2024.02.08]    at SmarterMail.Common.WinMail.WinMailWriter.WriteProperty(WinMailPropertyTag tag, Object value)
[2024.02.08]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.MapiMimeWriter.CreateWinMailDatFile(PidPropertyDictionary messageProperties, Guid tnefKey, ValueTuple`2 embeddedMessage, WinMailWriter writer, Encoder encoder, PidProperty pidTagMessageClass, List`1 recipients, Boolean isRequest, List`1 embeddedAttachments)
[2024.02.08]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.MapiMimeWriter.CreateSimpleWinMailDatFile(PidPropertyDictionary messageProperties, Guid tnefKey, ValueTuple`2 embeddedMessage)
[2024.02.08]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.MapiMimeWriter.CreateMimeKitMessage(PidPropertyDictionary messageProperties, List`1 attachmentEntries, List`1 recipientEntries)
[2024.02.08]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.MapiMimeWriter.CreateMessage()
[2024.02.08]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.EmailHandle.GetMimeFromHandle(MapiFolderContextData folderContext, String sentRepresentingEmailAddress, String sentRepresentingDisplayName, Boolean& attachmentModified, Boolean& importing, Mailbox mailbox, Boolean fromSend, Boolean sendingOnBehalfOf)
[2024.02.08]    at SmarterMail.Protocols.MAPI.ServerHandles.Items.EmailHandle.SendNow(MapiContext context)
[2024.02.08]    at SmarterMail.Protocols.MAPI.Rops.TransportRops.RopTransportSend.Process(List`1 payloadServerObjectHandleTable)
[2024.02.08]    at SmarterMail.Protocols.MAPI.RequestTypes.ExecuteRequest.Process()
[2024.02.08]    at SmarterMail.Protocols.MAPI.MapiProcessor.Process()

Additional Question: is a downgrade from 8797 possible and to which version do i have to downgrade?

Thanks in advance!

Rudolf

Hi Rudolf!

Same here with 8797. The problem is intermittent (sometimes it works ok, sometimes not)

Now I'm installing a custom build, hope that it helps...

We are unable to replicate the issue.  It seems there is a unique order of events that must occur for it to happen.  We have 4 or 5 tickets on this have sent customers custom builds with changes and additional logging to see if we can determine this unique order of events.  

Can you check if the affected accounts have more than one MAPI account in the mail repository?

My stuck Outbox problem returned, and this time /cleanrules was no benefit.   I am creating a new profile for the user, with only one mail connection, to see if it makes any difference.   It is a large mailbox with lots of folders, so rebuilding the sync is taking a long time.  Will open a new ticket.

@Brian: all my users have only one MAPI account 

Hi all

FWIW I've been having this "mail stuck in outbox" MAPI issue on my own mail account and a couple of customers since the upgrade from 86xx to 87xx.  But it doesn't seem to affect everyone using MAPI. It only happens one email out of 20? or 30? The problem is definitely not between chair and keyboard.

Hitting send/receive doesn't do anything. I usually solve it by closing outlook, hitting exit and send later button. Re-opening Outlook. Going to outbox. Opening the email. Ignore the "recent versions" message. His send again. And off it goes... and appears in Sent Items in Outlook and then I check webmail (so I know it's definitely gone).

Outlook isn't helpful - the error is "We can't complete this because we can't contact the server right now".

Mail is set to compose in HTML format. Nothing to do with RTF.

I've had to set up a whole new Outlook profile due to other issue. No change.

I'm running build 8776.24543

Also since upgrade the MailService service doesn't start when the server is rebooted - or tries to start then crashes - so I have to start it manually in Window services each time. Annoying but oh well.

I'd submit a ticket but I'm too cynical to spend time on this. Already burnt a lot of time in the upgrade process and helping people with their Outlook and doing re-syncs.

We had one user with this and since doing the cleanrules/other stuff we havent seen the issue again.

@Bert: For the issue involving SmarterMail failing to start on reboot, can you try setting a delayed start on the SmarterMail service to see if this helps? In the past I've seen other services on the server experience delays causing SmarterMail to fail or timeout during initial startup. Setting the delay gives the rest of the server time to wake up before we start SmarterMail up. 

On another note; I'll be going through the logging accumulated from the few tickets we have open on this today to see what diagnostic information our custom build was able to generate, so hopefully we'll have some updates on this soon!

About failure to start:  I have my SmarterMail configuration on an ISCSI drive.   The service has to be configured for "automatic (delayed start)" so that the ISCSI disks are present the SmarterMail service is launched.   I manually make that change after each new build is installed.

Good news: since installing custom build 8804 a week ago, I have not had any users complain about messages stuck in the outbox.

Likewise.. I have been running 8804 since Sunday night with no new incidents.

I have 8804 too (about a week now) and it seems to works fine.

Hope this is the solution.

Does the custom build solve the problem?

Not 100% sure, but yes for now

Thanks Gabriele!

I hope ST will release a build with the solution to the problem ;)

Nice! Sometimes, when save a message in a Draft and return after few minutes or hours to edit and send the message still in Outbox. Need to save again the Draft and sent the message.

Related to our memory issues and potentially these IMAP sending/draft issues as mentioned in this thread.... We seem to also be getting synchronization log errors in large batch (that drive up the MailService.exe memory... Perhaps related to this sending problem above? Seems to hit different users at different times. We're running Build 8797 (Feb 1, 2024)

User reported:

Opening a ticket.

Hi Michael!

This post is only for issue with MAPI protocol and Email blocked in Outbox, so you are out of topic...

Please open a new post for your issue...

Fair point, Gabrielle. 

I'll start a new thread on the synronization errors flood and matters affecting duplicate sent items and drafts appearing in Outlook on MAPI connected accounts. 

I only posted here since I suspected a connection with the outbox issues above and the duplication of sent items that we're seeing. 

But all good. A new thread is probably better. 

Has anyone heard if the new build mentioned above will go live this week?

Yes, we are planning on having a new Build out today with a number of fixes, including the one for the Outbox issue. 

This issue appears to have been resolved in SM 8818