* 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
Although 407a23663d will send rejection
messages for unrecognized errors, sometimes processing the email will
raise an error which has a blank message.
This commit:
1. Shows rejected emails which have already been processed and contain
a blank error in /admin/email/rejected
2. Replaces new blank error messages with the error type
The mail class seems to handle mails sent with Content-Transfer-Encoding: 8bit
somewhat weirdly: It decodes them (to utf-8), changes the raw source to base64,
and does not modify the Content-Type:charset= header.
This leads to Discourse trying the message encoding (in my example ISO-8859-1)
first, and if that does not contain any unparseable characters, it uses that.
Sadly, in ISO-8859-1, every byte sequence is valid.
Fix this by always trying to decode as UTF-8 first. The probability of someone
using another encoding that cleanly (but wrongly) decodes as UTF-8 should be
fairly low.
currently, Discourse uses '---' in its notifications to
separate the signature with unsubscribe links etc. from
the body of the message.
The RFC standard defines '-- '.
https://www.ietf.org/rfc/rfc3676.txt (4.3)
The problem has been discussed in:
https://meta.discourse.org/t/previous-replies-separator-is-not-rfc-compliant/39410
And an incomplete fix has been added a year ago:
86819f08c3
The separator is important, because some mail clients strip off the
signature automatically in replies if the signature is recognised as such.
