* FEATURE: add indication if incoming email attachment was rejected and inform sender about it
* include errors for rejected attachments in email
* don't send warning email to staged users
* use user object instead of user_id in add_attachments method
* Add possibility to add hidden posts with PostCreator
* FEATURE: Create hidden posts for received spam emails
Spamchecker usually have 3 results: HAM, SPAM and PROBABLY_SPAM
SPAM gets usually directly rejected and needs no further handling.
HAM is good message and usually gets passed unmodified.
PROBABLY_SPAM gets an additional header to allow further processing.
This change addes processing capabilities for such headers and marks
new posts created as hidden when received via email.
This updates tests to use latest rails 5 practice
and updates ALL dependencies that could be updated
Performance testing shows that performance has not regressed
if anything it is marginally faster now.
Ignores the site setting "find_related_post_with_key" and always tries to honor the `In-Reply-To` and `References` header for emails sent to a group.
The senders email address must be included in the `To` or `CC` header of a previous email sent to the group and the `Message-ID` of that email must be included in the current email's `In-Reply-To` or `References` header.
* `rescue nil` is a really bad pattern to use in our code base.
We should rescue errors that we expect the code to throw and
not rescue everything because we're unsure of what errors the
code would throw. This would reduce the amount of pain we face
when debugging why something isn't working as expexted. I've
been bitten countless of times by errors being swallowed as a
result during debugging sessions.
This change allows email-clients to show threaded views of mails as
expected. Apparently most algorithms expect the message ids of mails
in the Reference-header-field to be sorted such that they build a
traversal through the thread, so the oldest (original) message being
first, then its child, grandchild and so on until it arrives at the
message id that the "new" mail (that is to be sent) is the reply to.
MSGA [1]
+- Re: MSGA [1-1]
| +- Re: Re: MSGA [1-2-1]
| +- Re: Re: MSGA [1-2-2]
+- Re: MSGA [1-1]
If the stuff in brackets would be the message ID, the References-Header
field of a message that is a reply to [1-2-1] should look like:
References: 1, 1-1, 1-2-1
Discussion took place in:
https://meta.discourse.org/t/e-mail-threading-in-ml-mode-does-not-work-in-thunderbird
Main information taken from:
https://www.jwz.org/doc/threading.html
* store time it took to index message in DB (to find performance issues)
* ignore listserv specific files
* better examples for split_regex
* first email in mbox shouldn't contain the split string
* always lock the DB in exclusive mode
* save email within transaction
* messages can be grouped by subject and use original order (for Listserv)
* adds option to index emails without running the import
