Updated.

I have no reports of problems at the moment.

I am curious, why the limitation to 64 bytes on the username?

So many clients use an email address as the username, and that is allowed to be 320 bytes.

Or wait... are you talking about the portion BEFORE the @domain.tld?

Then that makes sense.

In a multi-domain system though the users are having to enter the entire email address though, which is what makes this seem odd to me.

Does 64 bytes = 64 characters?

One major change on the backend not mentioned in the release notes. eas.json and mapiews.json files are no longer used and the data is merged into the accounts.json file. This did cause one of our servers to have EAS and MAPI disabled for all users. So just double check your EAS and MAPI users after upgrade. Other than that, all seems OK today so far. 

Personally I would say it might not be that simple. It probably depends what chars are used in the username.

If I recall correctly SM now allows UTF-8 in usernames (accents and so on).

UTF-8 is based on 8-bit code units. Each character is encoded as 1 to 4 bytes.

So if the limitation is in bytes you can't be sure it matches the exact same amount of chars ?

For example:

Kind regards.

I upgraded all my servers to 9168 and all is going well!

The 64 byte issue was for me, and for an obscure edge case.

I tried to do an abuse report using the link provided in the message headers.  Webmail discarded my typing without explanation.   The local-part (username) was rejected because it exceeded the 64 byte standard.   I asked to either relax enforcement or provide a meaningful error message.  They chose to relax the rule 

I got around the problem by sending the report to abuse@domain instead of using the message-specific link.

I believe the standard counts octets, not characters, in the 64-byte limit.  The standard is widely ignored, at least for Mail From addresses, because they have VERP, SRS, or BATV encoding of another address 

As Douglas noted, part of the reason we put in the 64-byte limit on new usernames was because of RFC-5321. The other reason is to prevent potential issues with path lengths. While we now support Linux, many installations are still on Windows servers, which defaults to a max path length of 260 characters. Once you exclude the drive indicator (e.g., D:\) and the terminating null character, that leaves 256 characters for a path.

Note that this restriction enforces the new limit when creating or renaming a user. Because some providers, such as Google, don't enforce this standard from the RFCs, we made sure to remove any code that was checking username length as part of email address validation. This means that you should still be able to put longer email addresses in address fields when composing a message, managing a contact, or adding an attendee to a meeting. 

None of these responses address the question of:

Is the 64byte username requirement enforced on the LOGIN ?

I ask because in a multi-domain environment I need to have the ability to have my users login with the 64bytes of the mailbox name + '@' + the domain name + '.' + the TLD.   The sum-total length of all those according to the RFC is a max of 320 bytes (seemingly used interchangeably with 'characters' in this instance???).

Thanks!  Just want to make sure I understand the impact of this to my users as we are looking to finally upgrade our server to the latest version, and this could have a profound impact on my accounts for some longer domain-name clients.

Rod,

The limit only applies to the username portion, the part before the '@' character, when creating or renaming a user. It is not applied at login, as there may be users that were created previously with a username that exceeds 64-bytes.

The byte limitation can be interpreted to mean characters as long as only ASCII characters are used. If any non-ASCII characters are included, the actual number of characters will be less then the byte limit as UTF-8 encoding uses 2 to 4 bytes for characters outside the ASCII range.

Thank you for the clarification!

Unfortunately, upgrading from 9155 to 9168 (Linux) wiped 4MB of data off a user's calendar and many appointments past and future. Rolling back didn't help. I've submitted a ticket.

I've attempted to restore the .json file from a backup into a test user, but I can't figure out how to get it to take after placing it in the directory. Attach Folder (from Restore docs) doesn't seem to work. I'd appreciate any guidance on that front.

The calendar seems to have taken after leaving it for several hours.

Hey James/John! Moving an existing calendar JSON into a test user is half the process, but you'll also need to edit that user's folders.json file so it references the file ID of the file you restored. You'll want to make those edits with the SmarterMail system service in the stopped state ideally to avoid potential JSON corruption but that should do the trick! I'm curious what lead to the loss of the calendar data so I'm going to keep an eye on your ticket and will help out if/when I can. 

Hi Kyle,

What I ended up doing was adding a test appointment to create the folder-xxxxxx.json file (which was a new string of numbers), then overwriting it with the backup folder-xxxxxxx.json file with the new name. I didn't end up editing the file, but it seemed to work anyway...

I then re-created the appointments in the user's account based on the test user calendar. So we were able to get that back.

The file was 73MB, so it wasn't possible to edit with normal system utilities like Vim.

Though it seems like some filed emails are missing too... Now looking into restoring .grp files following: https://help.smartertools.com/smartermail/current/topics/systemadmin/manage/restore

Edit: Alright, this is weird. The folders that disappeared after the update still exist with the .grp files and everything, but the folder is not actually visible in the web interface/Outlook.

That makes sense James, and doing it the way you did more or less accomplished the same so you should be good there! The missing folders are likely resulting from missing entries in the user's folders.json file as well, as each one will be referenced here. Additionally there are mailbox.cfg files in each folder that index which GRPs are present and so occasionally you need to reset those as well. 

With all of that being said; the user's JSON being ~70MB is likely why they ran into trouble in the first place unfortunately, as that is a HUGE file for the system to read every time the user interacts with the calendar, making the file more susceptible to power events, corruption, etc. In the long run you might see if you can work with the user to pair that down a bit - your disks will thank you! ;-) Most of the time it is due to large attachments being sent in calendar invites and we can usually head those off by pointing out File Storage having public link access functionality. 

I hope that helps! Let us know if you have any questions along the way. 

So... if I'm reading this correctly... there IS a bug that can occur in the conversion to 9168 that can knock out a clients shared calendar entries (or at least make them inaccessible) ?

Was planning to upgrade to 9168 in production server this coming weekend (our production server is still on 8451), but if that is for sure now a known bug, I can't risk it.

Good to know it worked okay.

The missing folders relates to the user that lost several appointments/emails after the update. I haven't directly restored the appointments/folders to that user but instead restored them to a separate test user and manually recreated the forthcoming appointments for the "production" user. So I didn't overwrite anything for the "production" user; the folders were already missing (much more detail in the ticket).

Though indeed the missing folders are not referenced in the folders.json file.

We did work with Smartermail support to try to reduce the calendar folder.json last year, and in the end we brought it down from ~140MB to ~60MB. There were indeed some appointments with large attachments we deleted. However, this calendar consists of ~3600 appointments, each weighing in at roughly 20KB (no attachments bringing it down). In the end we weren't really able to find an answer other than "have less appointments", but we had reduced it by a lot. Deleting old appointments by the thousands is not a great option because you may want to review previous appointments (like filed emails).

What was a little strange is that we have another user with ~3500 appointments whose folder.json only takes up 12MB. Their average appointment size is less than 4KB. Not sure what constitutes the 5x larger file sizes when neither appointment has an attachment.