E-mail Reject Attachment Template or add note to topic indicating [attachment rejected %reason_for_rejection]

First post so please help if this is the wrong place to create the topic.

I asked @codinghorror and @erlend_sh quite a few questions before I set up a first Discourse installation to support Mailing List Mode and E-mail-In and Reply By E-mail. Thank you!

I have E-mail-In and Reply by E-mail enabled and have been testing the Mailing List Mode. The tests show two cases where there is no rejection notice when an e-mail is sent to Discourse. The behavior is for the topic text to appear in the forum without the attachment and without any error or notification that part of the contents were dropped or a reply sent by e-mail to the sender.

I think most folks would expect either a reply rejection if the inbound message does not meet the discourse community settings concerning either or both file attachment size or file type/extension, or an appended error in the forum that shows the attachment was dropped and an explanation.

I started looking at the error responses under /admin/customize/email_templates and it gave me the idea that it might be possible to add another template and reject e-mails with Attachment size/extension issues.

:question: Is it possible to add a new template such as: E-mail Reject Attachment template?

:question: How hard would it be to enhance the current e-mail parsing to append an error message to the text that acknowledges a file attachment was rejected due to invalid file type or exceeded max message size?

If I need to sell this option, I think either solution would inform the user of the issue and acknowledge what happened rather than leave them wondering if they forgot to attach a file or conclude file attachments are not working.

Ideally, I would like the user’s e-mail to generate the topic and include acknowledgement that the attachment was dropped with a specific reason, and to also have a notice sent back to indicate the attachment was dropped and include a link to the topic along with the indication of allowed file types and sizes in a template. Some users might resize the attachment(s) or edit to reference the attachment using a hyperlink.


Sure @zogstrip can we repro this?

I should specify the exact version of Discourse I am running: Version v1.6.0.beta11 +146

It was installed using the INSTALL-cloud.md guide. I would have specified the link but I am not permitted yet. Are mentions considered hyperlinks? I don’t see that I have used any hyperlinks, yet Discourse said I am not permitted to enter more than two. Am I missing something as a NooB? :confused:

I wonder if this topic is dead? Tomorrow makes 30 days and I hoped to get some kind of feedback on whether the issue I observed is:

  • an intended omission
  • a bug
  • something that should be put into a feature request

Perhaps someone will offer an opinion or suggestion.

Thank you,


Sure this seems like a reasonable error case to support, when the attachment is large enough, explain why it was not allowed – either too big, or not in allowed file types. I think we see a lot of “trivial” attachments which are signature images and the like which might make this tough.

It can be on our list but I don’t know when we can get to it or how hard it is cc @zogstrip

Can we keep it simple and focus on two simple changes?

  1. IF any part of an e-mail is rejected… the whole e-mail is rejected (no forum post is created with partial content).
  2. Add a notification template to address Email Reject Attachment with some text that explains why attachments were rejected.

Why should we care?

Discourse is rejecting attachments and does not tell anyone! This behavior needs to be addressed sooner rather than later.

I think it is better and clearer to reject the entire e-mail and all content when anything in the e-mail is rejected. ALL or NOTHING. Discourse needs to give notice to the sender when it rejects anything so they have the opportunity to fix the content. Discourse should not pick and choose silently – in the worst case it is taking things out of context because it rejects some of what has been submitted and accepts the rest without knowing what part the content creator considered most important.

An e-mail that announces and describes the content in an attachment is not worth much without the attachment. An e-mail discussing an image attachment isn’t worth much if the image is not there.

The user’s reaction when they find partial content is to assume they forgot to include the rest. They create another e-mail and are sure they add the attachments… so Discourse receives more partial content by accepting only the text and silently rejecting the attachments. The forum gets multiple partial content topics rather than rejecting the entire e-mail and educating the user about why it was rejected so they can learn and fix the issue.

Discourse already has a ton of Email Reject functions under Admin - Email Templates:

  • Email Error Notification
  • Email Reject Auto Generated
  • Email Reject Destination
  • Email Reject Empty
  • Email Reject Invalid Access
  • Email Reject No Account
  • Email Reject Parsing
  • Email Reject Post Error
  • Email Reject Post Error Specified
  • Email Reject Reply Key
  • Email Reject Screened Email
  • Email Reject Topic Closed
  • Email Reject Topic Not Found
  • Email Reject Trust Level
  • Email Reject User Not Found

Adding more logic and additional considerations pushes this in another direction and assures it will not happen for a long time.

The concern over “trivial” or a minimum file size to avoid “trivial” is a separate issue. Discourse has “Strip images from emails having size less than 2800 Bytes” so if you want to add a “trivial” threshold for image sizes it would be a new feature/option. How would you decide on the minimum size? Once anyone discovers the minimum size that is allowed, they can make their trivial image large enough to pass over that threshold.

In terms of policy and thinking, I prefer to rely on the community admin, staff, moderators to address issues on a case-by-case basis and resolve issues with specific users rather than punish everyone by policy for the potential issues only a few create.

This has been fixed in