Configuring different sender e-mail addresses (SMPT-envelope-from) for one letter-type
For now the SMTP-envelope-from definition for Alma Letters can be set only once per letter-type. This isn’t suitable. E.g., our libraries need more than one sender email address for different acquisition departments. Vendors should be able to reply directly to the departments E-Mail-address. Using one no-reply-address (as SMTP-envelope-from value) in combination with a “reply-to”-addresses written in the Mail Footer cannot be a permanent solution.
Actual situation in Alma:
When an E-Mail is send in the context of a job Alma takes the SMTP-envelope-from value from the „addressFrom”-definition in the concerning letter-configuration (general configuration -> letter emails).
When an E-Mail is send manually by a staff member (e.g. conversation letter, also used for claims to vendors) Alma takes the SMTP-envelope-from value from the definition in the settings for “preferred E-Mail-Address” of the acting staff member.
ALMA already allows the definition of up to 5 E-Mail-Addresses of different types for each department or library (primary, billing, shipping, claim response, patron communication). Unfortunately these types can be used only as output-values in the letter-content (=text), but not as actual SMTP-envelope-from addresses. This function could be extended as follows:
When E-Mails are send from a job or manually by a staff member, the values “from” and “Reply-to” in the SMTP-envelope section should be taken from a specific E-Mail-Address in the contact-definitions of the department (e.g. preferred). If no E-Mail-Address is defined in the concerning department the E-Mail-Address of the library and (if none defined) at least the E-Mail-Address of the institution should be taken (or even the value from „General Configuration - Configuration menu - General Configuration - other settings - envelope-from”).
This improvement would give the whole system more flexibility not only for Acquisition-departments.
(This is in addition to Ners request ID 5184)