|Email Notices (university) sent from the Aleph Server|
|Purpose & Scope|
Allows university libraries to have email sent directly from the Aleph server rather than from their library's campus mail server.
There are two types of email sent based on how its generated:
1) From client (on the fly), Ex. UBorrow Arrival Letter generated when item is Received or Loan/Return Receipts
2) From Server, Ex. Overdue, Lost, Recall Notices, generated at regular intervals via job_list
1. Remove some of the settings to email that may exist on the local pc.
- Remove the MailServer address
- Delete the Print Daemon that is used for email (under Print Daemon - select the printid - Setup - Delete)
*Note: Keep the printid used for printing
2. Keep, or add Email and Print printid (ex, circe/circp)
Depending on the type of job, the printid needs to be added to the print.ini.
- If email generated on the fly - printid added to module/tab/print.ini
- If email generated from job_list - printid added to Alephcom/tab/print.ini
How it works:
- Once the email notice is generated, it is sent to a print directory on the server with the printid extension.
- If the patron account does not have an email address, the notice will be printed, and a printid for printing will be used to direct notices to the pcs default printer.
- Software on the server will check the print directory at a predetermined time, and send the email via the MailServer used by FCLA.
- All of the settings: From Address, Reply-to address, address for bounced email, address for Log file, is listed in the software's config file.
- There is a log file that sent for each job. It includes the following - example below:
This message is to inform you that batch emails from Aleph have been sent.
Processed file: "filename.printid"
Sent 1 email message(s)
Sent 1 messages to printout file
Sent 0 messages to retry file
Message added to print file for hardcopy.
Message emailed to "email address"
- If the library is prevented from, or has difficulty sending email because of security issues, for example, only one pc given rights to email out, emailing from the server will help.
- A Log file is generated which gives information about the success/failure of the email sent.
- Reports that are printed on a regular basis, will still need to be setup with a printid, print daemon activated and printid added to print.ini file.
Since this setup is still needed, emailing from the server may be less attractive, especially for institutions with multiple campuses because the effort to setup and maintain the clients and *.ini files still exists.