mail
mail copied to clipboard
Render iMIP invitations
Is your feature request related to a problem? Please describe.
- Create outlook meeting and send invitation to participants from outlook
- Open invitation mail as participant with Mail app
Describe the solution you'd like
The mail is displayed properly and the event can be downloaded as attachment.
As a follow-up https://github.com/nextcloud/mail/issues/6803 will allow users to create replies to those emails.
Hi @connium,
AFAIK there's a standard for that kind of email. We'd have to detect it and display an appropriate detail view, ideally with some info from your Nextcloud calendar to see if you're free or busy.
How's the invitation displayed now? I think it should be displayed in a readable form though.
Hi @ChristophWurst,
this is how it looks like right now.

There is no attachment displayed. Directly below the invitation message there is the response area. A PM with the original email is on its way to you.
Of course it would be nice to have a detail view. Actually I'd be happy if the attached appointment is displayed, so I can see there is any :wink:
Got another mail with an embedded image where only the text/plain part which isn't displayed.
Looks like there is a general issue with multipart mails. Is multipart expected to work out of the box or is this a planned feature?
Well, at least there is some code that does something about multipart https://github.com/nextcloud/mail/blob/4eacfd3de09dcfbe8362685a579fe786e3510d04/lib/model/imapmessage.php#L387-L392 🙈
Thanks man, you're really fast!
I guess the problem is, that especially for HTML mails images and other stuff is kind of embedded in the content. It's included as a separate part each but has no filename (https://github.com/nextcloud/mail/blob/4eacfd3de09dcfbe8362685a579fe786e3510d04/lib/model/imapmessage.php#L409-L423) and thus it is not handled as an attachment.
At least it's true for the two mails I'm noticing this behavior (the outlook invitation yesterday and the embedded image today).
I will play around with multipart mails and add my findings to this issue.
Good catch! Do you know how to fix that? A PR for that is very welcome 😉
To be honest, I have no idea how to fix it. It seems to be not that easy:
- For embedded parts a filename must be "generated".
- How to handle the mail body if the mail contains
text/htmlandtext/plain
Most probably some more. I'll try to figure this out.
Most mail clients seem to count the parts and name the file accordingly part_<part-number>.<file-extension>. The file extension obviously is determined from the Content-Type of the respective part.
While sending several multipart test mails I didn't discover any other (un)obvious behavior.
I looked at the code to figure out what changes are needed, but I have to admit that I don't understand the parsing routines. So I can't help with a PR :disappointed:
I can confirm the behavior: No attachments are displayed for me as well; the setup is similar to OP so it doesn't make sense to duplicate that one. Some time ago, I wrote a python mail parser; from that issue I remember the following rough architecture: Mails are organized as trees (parts/mulitparts). Most Mail User Agent (MUA) friendly MUAs provide a MIME/html part and, alternatively, a text-only part. Mostly, the text-only part does not contain the attachments. My mail parser had the task to extract a text-only version of the mail (or, alternatively, translate the html part to text-only) and additionally extract all attachments that are part of the mail tree. What I did is: Iterate through the complete tree and extract all text/plain parts that are tagged as alternative and fall back to text/html parts. This allows the text-only application to digest the mail contents quite well. Additionally, all mime parts have been extracted and saved as attachments. So now comes my suggestion (without looking at the PHP code) for a change:
- extract the text AND the HTML version of the mail tree
- preferably display the text version and provide a button to display the HTML version if available
- for text versions: separately display all embedded pictures as attachments, but show that they are embedded pictures; mostly they are icons from virus scanners, logos and non informative nonsense
- additionally present all other attachments in a list / iconic view (no preview, this eats CPU and screen real estate)
- additionally identify .ics attachments as calendar entries and allow the choice to add them to the calendar (sometimes these attachments are meeting confirmations; they have to be treated differently; apple mail doesn't, we can do so if we want)
- additionally identify .vcs attachments as contact information that could be added to contacts app.
I won't review or code PHP. But, if somebody decides to do it, I can offer to join the testing.
@connium @joergmschulz thanks a lot for your insights. This helps a lot improving the app's code for handling that type of mails. I will consider refactoring the code based on your findings. I want to touch it anyways because we have close to no unit test coverage in that code area. 🚀
Hello, while my old tool did something comletely different than displaying mails, and has just been good enough for that special job for Outlook and AppleMail elements, the following python snippets might be an inspiration:
"""
save all attachments with filenames to specified directory. Duplicates will get merged / overwritten. Returns list of filenames.
# http://stackoverflow.com/questions/6225763/downloading-multiple-attachments-using-imaplib
"""
def SaveAllAttachments(eMail, directory):
attachmentNames = []
for part in eMail.walk():
if part.get_content_maintype() == 'multipart':
continue
if part.get('Content-Disposition') is None:
continue
filename = part.get_filename()
attPath = os.path.join(directory, filename)
fp = open(attPath, 'wb')
fp.write(part.get_payload(decode=True))
fp.close()
attachmentNames.append(attPath)
return attachmentNames`
and:
# extract as much text from multipart messages as possible
def get_first_text_block(email_message_instance):
body = u''
maintype = email_message_instance.get_content_maintype()
if maintype == 'multipart':
#pdb.set_trace()
for part in email_message_instance.walk():
messageType = part.get_content_type()
# charset = str(email_message_instance.get_content_charset())
charset = str(part.get_content_charset() )if (part.get_content_charset()) else str(email_message_instance.get_content_charset())
if messageType == 'text/plain':
if part['Content-Transfer-Encoding'] == 'base64':
body = base64.b64decode(part.get_payload(decode=False))
return unicode(body, charset, "ignore")
elif part['Content-Transfer-Encoding'] == 'quoted-printable':
# return unicode(part.get_payload(decode=(email_message_instance['Content-Transfer-Encoding'] == 'base64')), charset, errors='ignore')
return unicode(part.get_payload(decode=True), charset, "ignore")
elif part['Content-Transfer-Encoding'] == '7bit':
body = unicode(part.get_payload(decode=True),charset, "ignore")
else:
body = body + part.as_string()
elif messageType == 'text/html': # here, we strip text out of the HTML message
return unSoupPayload(part, charset)
elif messageType == 'multipart/alternative': # sender gave alternative - we ignore it
continue
else :
pass # pdb.set_trace() # dunno what kind of msg has to be treated
# if we have text, it is enough, we return.
if (len(body) > 0):
return body
elif maintype == 'text':
charset = str(email_message_instance.get_content_charset())
if email_message_instance.get_content_subtype() == 'html' :
return unSoupPayload(email_message_instance, charset)
else:
#body = unicode(email_message_instance.get_payload(decode=(email_message_instance['Content-Transfer-Encoding'] == 'base64')), errors='ignore')
body = unicode(email_message_instance.get_payload(decode=True), charset, "ignore")
return body
@ChristophWurst : can we somehow contribute to this issue as non-PHP user?
This screenshot shows the situation: while other mail clients display the attachment (well, that apple Ical has difficulties to digest the .ics is just another story) our mail app doesn't even show there is an attachment. Source system that accepted the invitation is outlook.

This persists in the current master with NC12. Sorry to say that.
I have justely this problem. I see that If I can do it.
still the same for 0.7.4.
Hey there,
I'd just like to let you know that due to the ongoing issue with Bountysource we're discussing ways to move to a different platform. As it looks right now, Bountysource might claim some of the money that was contributed by the community. We will try our best to prevent that. Historically we – the Nextcloud GmbH employees – simply put the claimed bounties back to other tickets until one was solved by a community member. So the money was always from the community and for the community. We'll therefore move to a better platform and currently don't post any new bounties until this situation is resolved. The current goal is to move/donate the money to Nextcloud include but details will follow in the forum post.
Hope this makes sense. If you have any questions please ask them on the forum. This comment will be copy-pasted to all open issues with bounties.
Christoph and the Mail team
In my opinion it is a core feature to see those outlook invitations; would you mind adding this to the roadmap? I don't want to nudge, nor be a nuisance; just for the sake this year-long deficit doesn't get forgotten. Still didn't learn to code PHP, sorry.
I know this isn't for everyone but what really helps us fund this project in the long run is a Nextcloud Enterprise Subscription with groupware. So if your organization uses Nextcloud in an enterprise environment please consider becoming a customer of Nextcloud Gmbh if you aren't already.
Otherwise I'm afraid this is further down our roadmap, so I can not give any estimations about a possible delivery of this feature, even though I see the importance for certain environments.
The issue is still open with NC20 and Mail 1.5.0 - unfortunately one of my clients is still on Outlook :-) and sends me invitations as ics files which do not even appear as attachments. If not mentioned in the text that it is an invitation you'll never know...
(I'm not shure if this is the right issue - but we've talked about that a while ago. No support for calendar entries is better than the current state)
Yes, we still don't have this as time didn't allow us to work on it yet. Any help is welcome and appreciate, as always :v:
So @jancborchardt and I thought about how this could look like, and here's what we came up with

Just a simple card with date, location if available, attendees, and options to RSVP
- the container has border of 2px solid
var(--color-border), border-radius of 8px and no shadow - the text in the first 2 lines ("You have been invited to...", "Appointments review"), icons and buttons are left aligned with the mail header text (Sarah Connor)
- Show the date and time in the recipient's time zone
- Ideally we don't need to have the .ics file shown, but that would mean the 3 options in the 3 dot menu of the attachment would be missing :/

For the different kinds of updates eg. event rescheduled, cancelled etc, it would be in the first line and the RSVP options would be changed accordingly

For the sake of keeping it short, we are not including description, etc as this infocard is just a summary of the event. What do you think?
Looks awesome! Two things came to my mind - first, what happens if f.e. the location field is really long (like a long Zoom Link), would the card then expand (as there is probably most of the time a lot of vertical screen space available), or will it continue to be a rather compact card but with a lot of (potentially ugly) line-breaks?
And secondly, I personally often receive invitations where the most important parts are written in a rather long description which I have to read to decide if I want to accept or decline this invitation - could we make it at least configurable if one wants to see the description in the cards, or not?
wow, this thread of 2016 .... Yes, I like this design (less is more). But, as @jgonsior said, sometimes more is even more. Wouldn't it be possible to include a rendering of the full invitation (might even be a long email thread with attachments) under 'More options'? These additional options should also have a 'suggest other date' and a 'tentative' as well as a 'forward'.
@jgonsior @joergmschulz such option would probably need to be non-binary and rather represent some notion of the "maximum vertical size allowed" (0 meaning the design without any description shown, 1 meaning e.g. "show one line", 2 2 lines, 3 ..., ..., inf "show always everything").
As @st3iny and I discovered, there is also a 3rd state we haven't considered yet:
User Alice invited Bob (who uses Mail) to an event.
User Alice updates the event, Bob gets a second email to the same event. But now the text should not say "You have been invited"but "an event you have been invited to has been updated" and offer the same buttons again.
For the first stage is should be fine not to display this. The backend will do the right thing when writing to CalDAV and will update the correct event provided the user imports the event to the same calendar again.
But we might need to search a user's calendar collection for the UID of the event to determine if this is the initial rquest or an update.
Since we provide a processed column, it should be possible to do this without overloading the mail app and decresing performance.
@nimishavijay Thank you for the detailed mockups. I'm almost finished implementing them but I'm still unsure about one thing: Which actions should be available inside the "More options" menu?
I think the "More options" was based on the way NC sends calendar invite mails, where the "More options" button takes you to a page where you can respond with the number of guests and comments. I don't think this is possible for iMIP invitation, so just Accept and Decline can work :)
I think the "More options" was based on the way NC sends calendar invite mails, where the "More options" button takes you to a page where you can respond with the number of guests and comments. I don't think this is possible for iMIP invitation, so just Accept and Decline can work :)
It is actually mentioned in the RFC that guests and comments are allowed to be submitted in a REPLY.
This part of the iMIP features - the rendering - was done with https://github.com/nextcloud/mail/pull/6782. The replying part is tracked in the other ticket https://github.com/nextcloud/mail/issues/6803.