Real Time Email Notifications and Posts

[memetic007]

Estimate: 5d

The user should have various options for turning ON near real time (up to 2 minutes of queuing is ok) emails upon various user specified conditions and being able to REPLY where appropriate:

All emails to provide link to the content item generating the email.

All emails to have links to toggle email notification off for the condition that caused the email.

\1 System Level

• Notifications - Option in User Preferences, default YES
• no reply possible

\2 Space Level Posts

• Button in Space Right Column, check box for Items only or Items and Comments
• sends email for new Items and/or Comments
• Default NO Email
• Button toggles emails on/off
• enable replies from email

\3 Link Item Level Posts

• Button in Comments view
• sends email for new Comments
• Default NO Email
• Button toggles emails on/off
• enables replies from email

[ffunch]

If the "enable replies from email" means to be able to create comments by writing one's reply in an email, I suggest skipping that altogether. I have done that elsewhere for threaded forums, and it is very hairy and hard to ever get exactly right.

If it means to be able to click in the email and be sent to the right place in a browser window, no problem.

[myers]

@memetic007 we removed the "enable replies from email" feature line as we think this is possible weeks of work to do right. Let's talk some more.

[memetic007]

I have thought about the issue some. Indeed i did mean: _to be able to create comments by writing one's reply in an email_.

And yes, threaded structure adds one obvious major complication and one minor one compared to responding to 'flat" discussions.

the major one: is the reply a "reply" (ie nested below what was being replied to) or is it a "peer" ie at the same level as what is being replied to?

The minor one: the email to the user needs to contain information about the exact Comment that is being replied to in a format that can be extracted by the parser on the server.

Are there any other complications as compared to implementing "reply via email" for "flat"?

The "major one" COULD be resolved as simply as a policy decision.... ie "always treat an email reply as nested one level deeper than that which is being replied to".

The minor one _seems_ pretty minor....

Not obvious to me where major time or complication comes from.

On Tue, Oct 22, 2013 at 3:59 PM, Myers Carpenter notifications@github.comwrote:

@memetic007 https://github.com/memetic007 we removed the "enable replies from email" feature line as we think this is possible weeks of work to do right. Let's talk some more.

— Reply to this email directly or view it on GitHubhttps://github.com/new-day-international/reddit/issues/92#issuecomment-26838728 .

Jim Rutt JPR Ventures

[memetic007]

The obvious use case for "reply from email" is mobile devices. In Basecamp I almost NEVER used the not too bad mobile version. Always used email. I know others that had the same usage pastern.

[ffunch]

Well, if one received a post as a single email, it isn't hard to refer to where one is in the threaded structure, and what it is that one would be replying to. The most failure-proof method is to use a unique and custom email address which identifies both the post one is replying to and the person replying, with some inscrutable encrypted code.

None of those are what I'd consider a difficulty. The major difficulty is how to reliably parse the email that comes back, to figure out which part is meant to be the new comment, and which parts are quoted parts of the original post or thread, or other surrounding information, formatting, the person's letterhead, signature, etc.

You can not rely on the user to put their reply in the right place. You can not be sure that the previous message parts are "quoted". The user might put their reply above, below, in-between, or even often in the quoted part. You can not rely on them to remove all extraneous parts, even if you ask them, because they're often minified and they can't see them. You can't ask anybody to send an ascii message, rather than html nowadays. Extracting the plain text from an html formatted message is not always straightforward.

Each email program and major webmail provider its own idiosyncrasies in how stuff is formatted, how the previous message is marked, etc.

I've done this very recently, implementing the functionality in a rails app for a threaded forum to process incoming mail and posting it in the forum. Lots of regular expressions and lots of exceptions to accommodate just the major email providers. It can work fine under controlled test conditions, like if you always send the message from gmail, and you make sure you put the message at the top.

But really it is a mess that I don't think should be used in real life. With hard work it can work fine 4 times out of 5 or maybe 19 times out of 20. And the last time you'll suddenly have 17 pages of confusing garbage appearing in a comment.

[memetic007]

It seemed pretty fool proof on Basecamp.

On Basecamp a custom "message ID" seems to be inserted into the email address:

message-15431347-5a4fe9d468fd633b18fb0c21@basecamp.com

message-15565155-5a4fe9d468fd633b18fb0c21@basecamp.com

message-14665346-5a4fe9d468fd633b18fb0c21@basecamp.com

Basecamp also seems to use this line of text as a flag:

"Write ABOVE THIS LINE to post a reply or view this on Basecamp"https://basecamp.com/1979010/projects/1063447-discussion-tidbits/messages/14665346-are-manning-and#comment_85375276

Which has a redundant message ID built into the link.

A little testing does show that various mail readers insert variously formated headers above the replied to email. That would no doubt be tricky.

On Tue, Oct 22, 2013 at 7:04 PM, Flemming Funch notifications@github.comwrote:

Well, if one received a post as a single email, it isn't hard to refer to where one is in the threaded structure, and what it is that one would be replying to. The most failure-proof method is to use a unique and custom email address which identifies both the post one is replying to and the person replying, with some inscrutable encrypted code.

None of those are what I'd consider a difficulty. The major difficulty is how to reliably parse the email that comes back, to figure out which part is meant to be the new comment, and which parts are quoted parts of the original post or thread, or other surrounding information, formatting, the person's letterhead, signature, etc.

You can not rely on the user to put their reply in the right place. You can not be sure that the previous message parts are "quoted". The user might put their reply above, below, in-between, or even often in the quoted part. You can not rely on them to remove all extraneous parts, even if you ask them, because they're often minified and they can't see them. You can't ask anybody to send an ascii message, rather than html nowadays. Extracting the plain text from an html formatted message is not always straightforward.

Each email program and major webmail provider its own idiosyncrasies in how stuff is formatted, how the previous message is marked, etc.

I've done this very recently, implementing the functionality in a rails app for a threaded forum to process incoming mail and posting it in the forum. Lots of regular expressions and lots of exceptions to accommodate just the major email providers. It can work fine under controlled test conditions, like if you always send the message from gmail, and you make sure you put the message at the top.

But really it is a mess that I don't think should be used in real life. With hard work it can work fine 4 times out of 5. And the last time you'll suddenly have 17 pages of confusing garbage appearing in a comment.

— Reply to this email directly or view it on GitHubhttps://github.com/new-day-international/reddit/issues/92#issuecomment-26862223 .

Jim Rutt JPR Ventures

[inflector]

Basecamp has had years to get it working right.

My experience with HTML email leads me to believe that this is at least a "several weeks" feature, and Flemming's experience does not seem at all outside of what I'd expect.

Flemming, how many weeks did you spend on the email replying for this other system?

[inflector]

The other major work for this is just setting up the email server itself, getting it configured and running properly, and filtering spam etc. is several days work at minimum.

And with respect to Basecamp, Jim, did you ever use any other mail client besides gmail? Getting gmail to work reliably is probably not too difficult, it's dealing with the tens to hundreds of different email clients that people might be using that represents the problem. Mobile Android clients, iOS clients, Mac and Windows clients of various flavors. Outlook? Versions?...

[ffunch]

I spent a couple of full weeks getting this to work in a rails system. And it works, but far from perfectly.

I would use a number of techniques at the same time to try to identify which parts belong to the html from the previous message(s) and which parts are new. I'd leave markers in the html that I'd try to find again. I'd look for the specific methods that various providers use to keep them apart, etc. All hoping that at least one of the methods will work.

Html mail is not at all something standard. Each provider and mail program has its own idea about what is ok and what isn't, so they remove certain elements, rewrite others, add their own stuff, etc. And the rules change once in a while, often without notice. The number of email solutions is maybe finite, but there are many, and they'd basically all have to be tested.

Handling an original post by email would be much easier than a reply in a thread, but not without its problems either.

[myers]

@ffunch It seems like Basecamp side steps the problem of looking bottom reply messages or intertext reply messages by putting the "Write ABOVE THIS LINE to post a reply or view this on Basecamp" header.

@memetic007 It's not that this feature isn't doable, it's that it's too big to be in one issue. Perhaps Step 1 would be "Setup incoming mail server that can run code on each incoming message", Step 2 would be "Insert message to an email address based on an Items thing id as a top level comment". Step 3 would be "For a Gmail sent email that uses the 'top reply' to a previous message insert it as a reply to the parent comment".

[memetic007]

I'll ponder and ask around and see if the notification without "reply" functionality is worth doing.

On Wed, Oct 23, 2013 at 1:47 PM, Myers Carpenter notifications@github.comwrote:

@ffunch https://github.com/ffunch It seems like Basecamp side steps the problem of looking bottom reply messages or intertext reply messages by putting the "Write ABOVE THIS LINE to post a reply or view this on Basecamp" header.

@memetic007 https://github.com/memetic007 It's not that this feature isn't doable, it's that it's too big to be in one issue. Perhaps Step 1 would be "Setup incoming mail server that can run code on each incoming message", Step 2 would be "Insert message to an email address based on an Items thing id as a top level comment". Step 3 would be "For a Gmail sent email that uses the 'top reply' to a previous message insert it as a reply to the parent comment".

— Reply to this email directly or view it on GitHubhttps://github.com/new-day-international/reddit/issues/92#issuecomment-26926890 .

Jim Rutt JPR Ventures

[myers]

@memetic007 it's not that you can't reply. You just have to follow a link to reply.

[inflector]

So basically, instead of hitting the "Reply" button in gmail which will open a compose window, you'll hit the (or some such text) button in the email body itself which will take you to the exact spot in lightnet where you can reply.

[memetic007]

yes, i got that, but that requires the user to transition from the mail reader to the browser ... much more annoying on a phone than on a computer.

On Wed, Oct 23, 2013 at 2:19 PM, Curtis Faith notifications@github.comwrote:

So basically, instead of hitting the "Reply" button in gmail which will open a compose window, you'll hit the (or some such text) button in the email body itself which will take you to the exact spot in lightnet where you can reply.

— Reply to this email directly or view it on GitHubhttps://github.com/new-day-international/reddit/issues/92#issuecomment-26929979 .

Jim Rutt JPR Ventures

[inflector]

not on iOS :)

[ffunch]

Alright, so we're talking about emailing a variety of items: Notifications, Posts and Comments.

Notifications - There will be several kinds. I can imagine that the user might want to check off which kinds they'd want in email and which they don't. I'd suppose we of course will leave out notifications that are covered by the Posts and Comments emailing, so they don't get them twice. But I'll also suppose that if one gets a notice about a post or comment, one needs to see some context in the email. I.e. the format and content of a notification email will depend on the kind of notification it is. If it is about a post, you'd want to see the post, I think, or part of it. If it is about a comment, I think you somehow need to see at least a little bit of its neighborhood.

Posts - Should show the whole post, more or less like it looks on the site, I assume. Which might require some compromises to make it show well on the most likely devices, as we don't know in advance what they are. And major email programs and providers have drastically different ideas about what elements of html they allow. But our posts are quite simple, so probably nothing very hard about that.

Comments - The tricky question is how to show the context in a meaningful manner. Do we show just the comment or post that's directly being commented on? Do we show that branch? Do we show everything, but minimized?

As to the reply by email thing, I suggest that we do at least what Myers suggests: split it off into a couple of separate issues. One would be to set up an incoming mail server. Another would be the processing and posting functionality. Would you be ok with that, @memetic007 ? We could very well prepare for it in this issue here, by making sure that the emails we send out are marked with identifiers (headers, the reply-to address) that later can tell us what it is that was replied to.

Also, to address it early on, it is getting harder and harder to manage an outgoing mailing system for a community site. Users will have issues of "I didn't get that email!", "Why did it go to my spam folder?", and we will once in a while be blocked and blacklisted by various providers, etc. None of which is much fun to deal with. It is worth considering outsourcing that part. I've used Postmark from several sites, with good success. https://postmarkapp.com/ Simple API, and it is cheap.

[inflector]

We're using Amazon's SES (see: http://aws.amazon.com/ses/) for the moment. Seems to work fine so far.

[ffunch]

Ah, forget about that part, then. Should be perfectly fine.

[memetic007]

ok, let's defer REPLY via EMAIL until some future date.

https://postmarkapp.com/ is 15X the price of Amazon SES. Not an issue in the short term, but I'd prefer not to build in the expense exposure for the future if we could avoid it. $1.50 per 1000 vs $.10 per 1000.

Posts - Should show the whole post, more or less like it looks on the site, I assume. Which might require some compromises to make it show well on the most likely devices, as we don't know in advance what they are. And major email programs and providers have drastically different ideas about what elements of html they allow. But our posts are quite simple, so probably nothing very hard about that...

Yes, show the whole post. Make the "go to link" or "go to file" links live as they are in the Lightnet Daily Summary emails. Also like the Summary, have the Title be a live link to the Item Comments Page. probably also needs a more explicit link at the end. Something like "Read or Reply on Lightnet".

Comments - The tricky question is how to show the context in a meaningful manner. Do we show just the comment or post that's directly being commented on? Do we show that branch? Do we show everything, but minimized?

I'd suggest we just send the Comment itself, more or less like in the Comments view of Follow: http://lightnet.is/space/follow/comments/ except change "by Item_Starter" to "started by Item_Starter" and drop the Vote buttons.

provide a link at the bottom: "Read in Context or Reply on Lightnet"

For Comments:

[memetic007]

While snooping around today on email processing and such I came across this RSS to EMAIL project.

https://github.com/wking/rss2email

SInce the Reddit Code already has RSS feeds, could this simply implementing the feature?

[ffunch]

That's an off-the-wall creative idea. But we still need to access the user's settings, email address, etc., and probably the full data of each post. So, probably best to do in the more normal way, which is that the notification, post & comment creation puts the item in a queue, to be dealt with in various ways at the back end, including sending it to people it needs to be sent to.

[ffunch]

One issue about real-time notifications is that it maybe isn't desirable that it is too real-time.

When I post something, a post or a comment, I will usually right away discover some minor typos or things I could adjust a little bit. It might be a minute or two before I'm happy with it and move on to something else. Which would be the perfect time to send it out to those who's settings demand it.

The item will be put in a queue right away, but I think the back end could have a criterion of adding an arbitrary delay. One to two minutes, I would say. Actually I'm not sure yet how that works with the queueing, but I imagine it might be straightforward.

[memetic007]

I'm one of those people who almost always edits lengthy posts (over a paragraph) ... often 2 or 3 times. Usually done in like 2 or 3 minutes. On the other hand, the edits seldom change the real sense of the post, just add in dropped words, correct spellings, fix markdown issues etc.

Basecamp allowed edits for some substantial but fixed period of time (an hour maybe) but sent alerts out much sooner (a minute maybe?). i don;t recall any problems with that logical disconnect.

On Mon, Oct 28, 2013 at 9:14 AM, Flemming Funch notifications@github.comwrote:

One issue about real-time notifications is that it maybe isn't desirable that it is too real-time.

When I post something, a post or a comment, I will usually right away discover some minor typos or things I could adjust a little bit. It might be a minute or two before I'm happy with it and move on to something else. Which would be the perfect time to send it out to those who's settings demand it.

The item will be put in a queue right away, but I think the back end could have a criterion of adding an arbitrary delay. One to two minutes, I would say. Actually I'm not sure yet how that works with the queueing, but I imagine it might be straightforward.

— Reply to this email directly or view it on GitHubhttps://github.com/new-day-international/reddit/issues/92#issuecomment-27209730 .

Jim Rutt JPR Ventures

[ffunch]

Alright, so now as to how the interface to the settings should look...

For a space, I imagine something like this in the sidebar:

Might as well allow choosing posts and comments separately, rather than posts vs posts & comments.

As for comment emails from a post, one possibility is to put it in the same place, instead of the space email settings, when one is looking at just that post and its comments. There would be just one checkbox, and it could say something like:

"email me new comments in this thread"

Alternatively it could be an added item in the "comment share save hide delete spam remove approve nsfw" after each post in the space view, but it is probably not a good idea to make it too easy.

But give me some feedback.

[memetic007]

Looking pretty good!

Some questions/comments:

1. If the intent is: "Might as well allow choosing posts and comments separately, rather than posts vs posts & comments." then the "too" in "email me new comments too" is not correct. the 'too" implies "comments AND posts".
2. As to the "send comments in thread" I like the first alternative: "put it in the same place, instead of the space email settings, when one is looking at just that post and its comments. There would be just one checkbox, and it could say something like: "email me new comments in this thread""

On Wed, Oct 30, 2013 at 9:25 PM, Flemming Funch notifications@github.comwrote:

Alright, so now as to how the interface to the settings should look...

For a space, I imagine something like this in the sidebar:

[image: image]https://f.cloud.github.com/assets/714310/1442738/fc1464de-41c6-11e3-91ec-f32df0c12f81.png

Might as well allow choosing posts and comments separately, rather than posts vs posts & comments.

As for comment emails from a post, one possibility is to put it in the same place, instead of the space email settings, when one is looking at just that post and its comments. There would be just one checkbox, and it could say something like:

"email me new comments in this thread"

Alternatively it could be an added item in the "comment share save hide delete spam remove approve nsfw" after each post in the space view, but it is probably not a good idea to make it too easy.

— Reply to this email directly or view it on GitHubhttps://github.com/new-day-international/reddit/issues/92#issuecomment-27454524 .

Jim Rutt JPR Ventures

[ffunch]

I guess my "too" was at attempt of both not sounding repetitive, and also planting the idea that it would be silly to click the second one without clicking the first. But, yes, maybe that just makes it ambiguuous what will happen if one clicks on only the second. Or of course I could make it work like you said, sending both posts and comments if they click only the second box.

[inflector]

I'd send both posts and comments if they click the second one.

[memetic007]

If that's the behavior we want then less ambiguous lange could be something like:

1. email me new posts in this Space
2. email new post AND new comments in this Space

I'm a great believer in clarity over terseness where people have to make a CHOICE. Choice under ambiguity is stressful for normal people (ie not people like us!) so that ambiguity MASSIVELY reduces the proportion of people that will choose ANYTHING.

[ffunch]

Right, best to be explicit. But then I think I might as well go back to:

• email me new posts in this space
• email me new comments in this space

Which gives the maximum of choice and the minimum of doubt. Looks a bit repetitive, but maybe that's just the writer in me who's bothered by that.

[memetic007]

that is nice and explicit too.

Question is, is it reasonable that somebody would want the Comments but not the Posts?

If so, your proposed design provides maximum LOGICAL flexibility, but it is possible that users might tend to think about it Hierarchically from narrow to broad in which case the previous version would be better..

I'm not sure. Others' thoughts?

On Thu, Oct 31, 2013 at 10:36 AM, Flemming Funch notifications@github.comwrote:

Right, best to be explicit. But then I think I might as well go back to:

• email me new posts in this space
• email me new comments in this space

Which gives the maximum of choice and the minimum of doubt. Looks a bit repetitive, but maybe that's just the writer in me who's bothered by that.

— Reply to this email directly or view it on GitHubhttps://github.com/new-day-international/reddit/issues/92#issuecomment-27490753 .

Jim Rutt JPR Ventures

[inflector]

I can't think of a reason why anyone would want to see the more granular comments without being advised of posts themselves which are the more important containers of comments.

[ffunch]

I can't think of a reason either that they would want it, but I kind of believe in not making too many assumptions about what people logically should want in the future.

And to me the existence of two checkboxes becomes illogical if the second one includes the choice of the first. It will then be ambiguous what happens when I check the second and then uncheck the first, because I don't want to see the posts. In that case it should be a radio button, not two checkboxes. But if it is a radio button, there would have to be a third choice, of not emailing anything. Which I think would be more clumsy.

[inflector]

There's always a tension between flexibility and cognitive load.

The other way to handle it is to automatically check the first when the second is checked, and uncheck the second when the first one is unchecked.

[memetic007]

Probably the smart thing is while the code is being worked implement all three logical possibilities, even if we decide to surface only two.

Since there is no principled way to decide now without more research than it is worth, start with the independent Post and Comment options and listen to what feedback we get and what data we collect. On Oct 31, 2013 2:08 PM, "Curtis Faith" notifications@github.com wrote:

There's always a tension between flexibility and cognitive load.

The other way to handle it is to automatically check the first when the second is checked, and uncheck the second when the first one is unchecked.

— Reply to this email directly or view it on GitHubhttps://github.com/new-day-international/reddit/issues/92#issuecomment-27510817 .

[ffunch]

Then, as to how the messages should look, here's what a post would look like:

and here's what a comment would look like:

Except for that the actual subject line was "Re: Here's my post". Gmail changes it, to associate it with the original thread.

Not particularly pretty, but I used the html from the summary email, which I assume has been tested to be ok in most email systems.

[memetic007]

Should repeat the header (title, links, author, time) information in the body of the email in a way that is visually reminiscent of the Lightnet Online interface.

The apporach used in the daily email summaries is a good approximation.

On Thu, Nov 7, 2013 at 5:05 PM, Flemming Funch notifications@github.comwrote:

Then, as to how the messages should look, here's what a post would look like:

[image: image]https://f.cloud.github.com/assets/714310/1496284/5776de10-47f8-11e3-8e4d-5c9d47c1db0a.png

and here's what a comment would look like:

[image: image]https://f.cloud.github.com/assets/714310/1496290/66d1f2d2-47f8-11e3-87ae-8fe653b78d33.png

Except for that the actual subject line was "Re: Here's my post". Gmail changes it, to associate it with the original thread.

Not particularly pretty, but I used the html from the summary email, which I assume has been tested to be ok in most email systems.

— Reply to this email directly or view it on GitHubhttps://github.com/new-day-international/reddit/issues/92#issuecomment-28011354 .

Jim Rutt JPR Ventures

[ffunch]

As to the checkbox for getting the new comments in a thread, I tried to put it in the same place as the two checkboxes for posts/comments for the space would go. BUT that gives some caching issues that aren't straightforward to get around. Essentially, no problem with the user/space settings, as we already have a button there for whether one is subscribed to the space or not, so that is already cached appropriately, for that user for that space. But a setting that is for one thread only, that is something else.

So, what I suggest instead is to put it over with the comments, like this:

which probably is more logical for the user anyway, and more consistent with how it looks on other sites. No problems with caching there, and I'm doing it as a proper template/class that is added to the "pane stack", rather than sneaking it into an unrelated element.

[ffunch]

As to the look of the email, @memetic007, are you saying I should put the title of the post down in the white part, rather than in the grey border part where I put it?

I will show the link, if there is one.

As to the time, since it is a static text sent in an email, it can't really say "X minutes ago" in any meaningful way. I could give the actual time it was posted, but we never see that on the site itself, so it doesn't particular help to identify the posting.

I can either say how many comments there are, or when the last one was posted, or anything else that changes over time, and probably is no longer true by the time one reads the email.

Then again, I can see that the daily summary is showing "X hours ago" and the number of comments. Do you prefer that I do it altogether the same way?

[ffunch]

Alright, so the format of the mails is now like this for a post:

and like this for a comment:

Let me know if you see any problems with this.

[memetic007]

Formats look pretty good.

Seeing "posted 710 milliseconds ago" is strange. Can we do the actual time, say in Eastern Time?

otherwise looking good.

[ffunch]

I think we should maybe make a more global decision on that. The daily summary email does the same. And it of course makes no sense when one is reading it half a day later. But I think it should be considered, at least as an option, to show when something was posted on the site itself, rather than always showing "so-and-so many days and hours and minutes and seconds and milliseconds ago". Like, the same day it might be useful to see how long time ago it was. But beyond that, I'd rather have the date and time, which is a useful reference point. It kind of makes a big difference for me whether your post was on April 1st or April 2nd. And I think time should be in the user's local timezone.

[inflector]

In this case, however, since emails are coming out within two minutes of posting. The times are pretty accurate when the email gets sent and the reader is likely to be getting the email soon after sending. Unlike with the summary emails where the reader is likely to be reading the email hours after it was sent.

[memetic007]

Looks good in testing so far. Is there a built in delay? Seems like it took maybe 2 minutes to receive email.

Minor increasing salience of email options would be help, also adding Space level options to Comments Page:

[memetic007]

minor tweaks, reopening

[ffunch]

Yes, there's a 2 minute delay

[memetic007]

that's probably about right.... give people a chance at an edit or two before it goes....

On Mon, Nov 11, 2013 at 5:24 PM, Flemming Funch notifications@github.comwrote:

Yes, there's a 2 minute delay

— Reply to this email directly or view it on GitHubhttps://github.com/new-day-international/reddit/issues/92#issuecomment-28245853 .

Jim Rutt JPR Ventures

[memetic007]

For a second email with the same title, gmail is truncation the message BEFORE the Read in Context or Reply on Lightnet message.

[memetic007]

Our addressing/subject line scheme is less clearly identifiable as compared to Basecamp:

Perhaps lightnet-no-reply as the address? or possibly [Lightnet: spacename] in the subject or possibly both!

[ffunch]

I increased the thread checkbox from 10 to 12px, same as the other checkboxes. Personally I think that does it.

I made the space checkboxes show also when one is looking at a thread.

The sender address comes from the global settings. I used one called "share_reply", which is set to just "noreply@[ourdomain]". All the email addresses set in the settings are simple addresses, i.e. no name part, like "Lightnet". I'm going to check if it works to give a full address.

The gmail thing, yeah, I noticed too. Gmail's algorithm for choosing what to hide is a bit inscrutable to me, possibly involving identifying parts that also appeared in the previous email, which makes it kind of hard to force it to show a footer which indeed is exactly the same as in the messages before it.

[inflector]

WRT Gmail, perhaps we could add a line in small text at the bottom which says:

Sent at 12:28 PM on Monday, November 11th

Since that will change every time, that might keep GMail from collapsing the text