Proposal for easier replies

x00

@hgtonight‌ mentioned an issue with the replypush service. Granted it is a feature not a bug as such, but it is down to a practical limitation.

There is a requirement to put /eom at the end of the message so the service knows were to snip.

It may seem trivial to remove the original message without help, but that is far from the case. There was a paper published on this very subject the 2000's needless to say it was pages and pages, and that only cover plain text email not the html experience, and was based on machine learning (essentially AI techniques). There is not fool proof solution at all, and it only takes into consideration English language.

Why is it so difficult? We there is simply no standard way to wrap the original message. There are countless email clients, and user settings.

Yes you can restrict to certain email clients, if you can trust the source to produce predictable result, but I don't want to have any such restriction.

Removing the original message itself is not the difficult problem, it is the surrounding annotation of the message by the email client which is the problem, distinguishing that from the reply is hard, to impossible.

So I've come up with a comprise. I use already a hidden tag (or visible one in text only), this gets retained when the original message is replied to. Everything bellow this can be stripped.

The reply "stationary" can remain, but I will strip emails, and and replier's email name. I will include in the message some "substitution tags" so everything that is stripped is also send with the notification, but not in the content body.

So then the plugin can decide what to do with it.

Practically speaking it might look like this (simplified without the html junk)

This is the reply

On 22/12/14 17:07, {YourName}<{YourEmail}> wrote:
{OriginalMessage}

or if you are unlucky could be as bad as this

This is the reply

---

From: {YourName}[mailto:{YourEmail}]
Sent: 17 December 2014 17:45
To: {Replier}
Subject: coop statements
{OriginalMessage}

Then for instance you can provide a reference if required, in place of {OriginalMessage} so you don't get the whole message and any email signatures, etc.

I will strip some common patterns, so you might not get any of that, especially "On [Date], ... wrote:" type thing, and average text replies would be easier. There will be some other smart stripping also.

I plan to keep /eom as an optional alternative, especially if the email client fails to retain the marker.

Anyway I can't implement this straight away, as it will require some development and testing time. Meanwhile the service is still usable.

hgtonight

I didn't mean to take away from the awesomeness of this addon. It is truly great!

Good luck with your enhancements.

x00

It is something I have been thinking of for a while, it is just difficult to gauge the appropriate action.