CUNY Academic Commons

If not, perhaps we can find some way where users are automatically notified that their response will not go through to group recipients as they had intended?

In the past, there was this line added to the top of non-RBE emails:

--- Replying to this email will not send a message directly to the recipient or group ---

I forgot to port this functionality to the new email system, but I've just done this in #6695.

We never sent back a reply to the sender.

If that is true, perhaps we can enable RBE for such actions?

This has to be done on a case-by-case basis and requires extra development time for each email action.

If we want to do this for file uploads, let me know.

Thanks, Ray. I'd be in favor of NOT enabling RBE on file uploads but of sending an email back to a user who tries to reply to a file upload event. How feasible is that?

but of sending an email back to a user who tries to reply to a file upload event. How feasible is that?

This introduces some complexity.

If we want to send a reply back with a custom error message for each custom action, we would have to track non-RBE emails and alter the RBE email address to something like:

example+noreply-docuploads@gmail.com

Or something more generic that would be sent regardless of action type would be simpler.

eg:

example+noreply@gmail.com

Then, for replies to this email address, I can check to see if "noreply" is in the email address and send back a response to the sender. The negative here is not all sites with RBE would want this functionality.

Ray, I'm not really familiar with RBE's internals, but wouldn't it be possible to do something like this: when an email is received, try to find a handler that matches the hash/email content, and if one is not found, then send a generic "your message could not be posted" message? This seems like it'd be enough - something like "a custom error message for each custom action" doesn't seem important.

Ray, I'm not really familiar with RBE's internals, but wouldn't it be possible to do something like this: when an email is received, try to find a handler that matches the hash/email content, and if one is not found, then send a generic "your message could not be posted" message? This seems like it'd be enough - something like "a custom error message for each custom action" doesn't seem important.

Currenty, RBE doesn't alter every email to add a 'Reply-To' email header; only those that require it.

If we follow your approach, we would have to alter every email to use the RBE email address. There are both pros and cons to each approach.

Currenty, RBE doesn't alter every email to add a 'Reply-To' email header; only those that require it.

Ah, gotcha.

I guess the cons of my suggested approach are:
1. it would take (your) dev time to build it
2. by having a Reply-To header, it might encourage users to reply (since this header triggers certain UI in mail clients)
3. more overhead for the inbox connection (PHP IMAP in our case; additional cost when using a third-party mail service)
4. the From address on non-RBE emails, on some sites, may go to an actual inbox that someone is reading, and the proposed change will break reply behavior in that case

Of these, it seems that 4 is potentially the most serious. But I don't think it's an issue for the Commons, since we don't really monitor the commons@gc.cuny.edu for this kind of traffic. I wonder if it'd be possible to have a Commons-specific RBE addon that does the following: (a) tells RBE to add the RBE Reply-To on all outgoing emails, and (b) provides a default handler for non-supported mail types (not sure if this is easy or possible given the way RBE's internals work - I'm imagining something like a do_action() hook inside of the `default` block of a switch statement?)

Three questions: (1) Have I captured the case against my suggestion? (2) If so, what do you think of the case for making the suggested behavior Commons-only? (3) Would it be a huge lift to build it?

For context - I don't think that responding to non-supported RBE types is a huge problem on the Commons. I don't monitor the inbox, but I'm guessing it can't be more than a small handful of emails per month, and most of those people probably figure out that it does nothing when they get no response :-D So if it adds a huge maintenance burden or something to do what I've suggested, maybe we can wontfix.

Thanks for this, Ray. Would it be possible to include a link back to the post (or would that already be included in $parsed_subject?)

Would it be possible to include a link back to the post (or would that already be included in $parsed_subject?)

A link back to the original post would be hard to parse.

However, the link should be available from the $body variable since that should include the entire reply, including the original email.

$parsed_subject is just the subject line from the previous email.

Okay -- thanks, Ray

This looks great to me, Ray! If there are no objections, I think we can mark this one complete.