Extra carriage returns in emailed Notes

You need to have your mailserver present the mails as plaintext

Filed a ticket with Solarwinds on this issue in April (we're using IMAP).

Update for Case #602193 - "IMAP import adding extra blank lines." Hi Patrick, Thank you for the update. Just keep me posted then on what will be the update next week. Also, I got a confirmation from Development that this is a known issue that will be fixed in the next future releases. No ETA yet as to when nor what version but it is one of the things being worked on.

Yup, same here back in March.  Got pretty much the same response and the ticket is still "In Progress."  It really makes emails that are longer than a few lines look horrible, especially if there's a signature too.

Extra line-spacing in tickets when sent from email

Hello,

I agree that this is a bit annoying. If the tickets come in like in your example (and if I have the time) I edit the extra lines out of it. But it would be brilliant if this could be addressed by Solarwinds.

It is more than a "cosmetic" issue because if a ticket starts to get complicated and the entries grow, it can be very difficult to read and follow up the history.

Regards,

Eberhard

This is off topic, but this is how your note came in my inbox:

Solarwinds can't escape the extra lines!

Just sadly noting that this silly and annoying issue is still happening in v12.2....

This is interesting. johndcciu have you double checked if you are also not sending extra newlines?

I found a workaround for this issue in my environment; not sure if it's applicable more generally for other mailservers that might trigger this WHD issue, but it worked to resolve the issue here.  We had originally been on a non-Exchange email system when we implemented WHD (and POP3 worked fine with that mailserver, no extra carriage returns) and we had it set to POP3 retrieval.  When we switched to Office 365 (i.e. Exchange in the cloud), I'm not sure if we just didn't notice the "Exchange" option in WHD, or if it's a new option, but either way, we were still using the POP3 protocol to hit Office 365 and still getting the extra carriage returns.

As an aside, heeding the suggestion above to make sure that the server was sending plaintext, I used a PowerShell command to ensure that any POP3 retrieval would be plaintext.  That did not resolve the issue, so it's not an issue with plaintext versus anything else.

But I then changed the "Account Type" field from "POP3" to "Exchange 2010/2013" in the WHD email retrieval settings and that did the trick.  I don't know if that "Exchange 2010/2013" option is new, or that we just didn't notice it when we switched to Office 365, but it worked to work around this issue at our site.

Note that the POP3 (and IMAP) protocols still have this bug (and those protocols should really work with Exchange servers too....and they will need to for servers that don't have EWS running), but those who are experiencing it with Exchange servers that do run EWS (whether on-premises or in the cloud) should be able to work around the bug by changing the retrieval protocol to "Exchange 2010/2013".  In my case, I didn't even have to re-do the credentials or other settings:  it worked immediately after I changed that "Account Type" field.

I changed our incoming mail setup from IMAP to Exchange 2010 & the notes are now formatting correctly without all the additional lines & spaces- great!- except now instead of the mails being deleted when they are processed by WHD, they are going Unread into the Deleted Items folder. Good job I noticed the mailbox size was increasing

Has anyone else seen this? Any ideas if there is a policy I need to change on the exchange ?

There's likely a default expiration policy (probably 30 days) for deleted items on your Exchange server, so they should respect that policy.  But you can verify it by looking at the policy on that Deleted Items folder to make sure, and apply it manually if it's not already there.