Patron Notices (UXPROD-18)

[UXPROD-2698] Configure custom headers in mod-email Created: 28/Aug/20  Updated: 19/Aug/22  Resolved: 27/May/21

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: R2 2021
Parent: Patron Notices

Type: New Feature Priority: P2
Reporter: Ian Hardy Assignee: Darcy Branchini
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines MODEMAIL-57 Add support for custom headers Closed
Relates
relates to UXPROD-2385 Improved logging related to patron no... Closed
Epic Link: Patron Notices
Front-End Confidence factor: Low
Back End Estimate: Medium < 5 days
Development Team: Vega
PO Rank: 100
Cap Plan Fix Version (DO NOT CHANGE): R2 2021
Rank: Chalmers (Impl Aut 2019): R2
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R1
Rank: Grand Valley (Full Sum 2021): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: MO State (MVP June 2020): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

Use Case(s):
The particular use case I'm interested in is AWS SES logging, but there are likely other reasons admins may want to add a custom header. For AWS SES logging, in order to collect more detailed email logs, emails must be associated with a ConfigSet by setting a custom header.

In scope
Add a custom header to emails as they're submitted to the SMTP server.

Proposed solution/stories
If there were a config that could be sent to mod-configuration that would allow admins to set a custom header for all outgoing emails that would be helpful.

Links to additional info
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/using-configuration-sets-in-email.html



 Comments   
Comment by Ian Hardy [ 28/Aug/20 ]

Hi Khalilah Gambrell, just calling your attention to this new issue for the mod-email backlog.

Comment by Khalilah Gambrell [ 28/Aug/20 ]

Thanks Ian Hardy, is the issue blocking another issue? Is it a blocker for a library going live or live with FOLIO?

Comment by Ian Hardy [ 28/Aug/20 ]

Hi Khalilah Gambrell, This isn't blocking any issues or implementations. I'd say this is a "nice to have" for hosting providers/implementors, but not critical for anyone afaik.

Comment by Khalilah Gambrell [ 28/Aug/20 ]

Thanks Ian Hardy. I am changing the priority as P1 means showstopper / must do. I also assume that this request would be very helpful for troubleshooting patron notices?

Comment by Ian Hardy [ 28/Aug/20 ]

Thanks Khalilah, yes configuring our email service (Amazon SES) to keep better records for troubleshooting notices is what we want to use a custom header for.

Comment by Khalilah Gambrell [ 28/Aug/20 ]

Thanks Ian Hardy. Darcy Branchini and Alexander Kurash, fyi on this request related to enhancing patron notice troubleshooting.

Comment by David Crossley [ 01/Sep/20 ]

Note that there could be a need to specify two headers:
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/event-publishing-send-email.html#event-publishing-using-ses-headers

Comment by Jakub Skoczen [ 29/Sep/20 ]

Khalilah Gambrell Darcy Branchini Hey Guys, any updates on ETA for this request?

Comment by Darcy Branchini [ 29/Sep/20 ]

I didn't see this request, Jakub Skoczen, until you tagged me. Shouldn't this be a feature request that should be ranked by others? We still have many features to address regarding notices, including allowing for the configuration of the "from" address on emails (probably different from addresses for different locations) so it seems we might want to address those before this new request unless libraries feel this is a high priority. cc Cate Boerema

Comment by Cate Boerema (Inactive) [ 29/Sep/20 ]

I didn't see this request, Jakub Skoczen, until you tagged me. Shouldn't this be a feature request that should be ranked by others? We still have many features to address regarding notices, including allowing for the configuration of the "from" address on emails (probably different from addresses for different locations) so it seems we might want to address those before this new request unless libraries feel this is a high priority. cc Cate Boerema

This makes sense to me, Darcy Branchini

Comment by Jakub Skoczen [ 05/Oct/20 ]

Darcy Branchini Cate Boerema For providers hosting on AWS and using SES, custom headers seem to be the only available way to identify sent emails. Hence to provide email tracking as described in UXPROD-2385 Closed this functionality is required.

Comment by Darcy Branchini [ 06/Oct/20 ]

Jakub Skoczen and Ian Hardy, I know know we already capture emails sent in mod-email with patron email, so just for my understanding, is this what would allow us to add sending library, user ID, and item IDs referenced, etc.? If that's the case, then it would improve logging, but perhaps it's also needed for the circ log feature?

Comment by Darcy Branchini [ 07/Oct/20 ]

From Ian Hardy via Slack:

The reason we requested opened this issue has to do with AWS SMTP for email. As a hosting provider, we use AWS simple email service to deliver mail. You can interact with AWS SES in a similar way you would with an SMTP server. We noticed AWS doesn't provide a very detailed audit of sent messages. You only get a very terse report of failed delivery, but we don't have a great way to confirm that yes, a certain message with subject x was delivered to a certain patron at a certain time using AWS's default monitoring.

You can configure better auditing, but in order to do so, you have to include a special header when you pass email to AWS that looks something like this X-SES-CONFIGURATION-SET: ConfigSet. This feature would allow a sysadmin to set a number of arbitrary headers that get attached to every email sent for a tenant. So when you configure mod-email for the tenant, you post a couple configs to mod-configuration, it would help us if you could also include configurations to include x number of arbitrary headers on every email sent from that tenant. This is not something I would expect library staff to ever need to touch. I would expect that it's configured the same way the SMTP info is configured through mod-configuration.

Comment by Darcy Branchini [ 07/Oct/20 ]

Vega team estimated this, but they are not using the same client that is referenced in the description so they are not sure if it'll be as easy as the description references. Also, we cannot expect that all hosting providers will use AWS for a SMTP server, so I'm not sure if there's more to investigate/research regarding other services.

Comment by David Crossley [ 07/Oct/20 ]

Darcy Branchini This just needs the ability to add any headers to the email. The specific header names and values are to be configured by the FOLIO service provider for whatever email system that they use.

Comment by Jakub Skoczen [ 02/Nov/20 ]

Darcy Branchini Cate Boerema Guys, our DevOps see this as a limitation to track email delivery. Any chance this will be addressed in R1? It is a relatively small development task. Thanks!

Comment by Darcy Branchini [ 02/Nov/20 ]

Jakub Skoczen, I'll talk to Cate Boerema about this. If it's a relatively simple task, it seems reasonable to include it in R1. Can you explain what it allows us to track specifically? At one point I heard that this would allow hosting providers to distinguish which library a specific email belongs to if you're using one email service instance for all libraries hosted. Is this true or does this provide us with something else? Also, it's always been my understanding that we can only track delivery to the point of the recipient's server, correct? We can truly track delivery or receipt beyond that, correct?

Comment by David Crossley [ 04/Nov/20 ]

With this ability, we will be able to confirm that the email has successfully passed through our system, and so the issue is likely to be at the user's end.

Yes, an additional use would be to enable the deliveries to be categorised.

Generated at Fri Feb 09 00:26:07 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.