ISSN: 2474-3542 Journal homepage: http://journal.calaijol.org Investigation of the Email Notice Issue in Aleph Gordon F. Xu and Yi Chen Abstract: Based on experimental results and existing resources, the paper explored and identified the major contributing factors to the email notice issue, including local administrator status, Aleph client, mail server, Aleph system files, and security settings. The paper elaborated the troubleshooting process, and how to find the solution to the issue. The authors suggested recommendations based the lessons learned from the project experience. The project experience presented in this paper should be instructive for libraries solving the similar problems. To cite this article: Xu, G., & Chen, Y. (2017). Investigation of the email notice issue in Aleph. International Journal of Librarianship, 2(2), 92-103. https://doi.org/10.23974/ijol.0.vol0.0.27 To submit your article to this journal: Go to http://ojs.calaijol.org/index.php/ijol/about/submissions http://ojs.calaijol.org/index.php/ijol/about/submissions INTERNATIONAL JOURNAL OF LIBRARIANSHIP, 2(2), 92-103 ISSN:2474-3542 Investigation of the Email Notice Issue in Aleph Gordon F. Xu, Yi Chen New York City College of Technology, Brooklyn, NY, USA ABSTRACT Based on experimental results and existing resources, the paper explored and identified the major contributing factors to the email notice issue, including local administrator status, Aleph client, mail server, Aleph system files, and security settings. The paper elaborated the troubleshooting process, and how to find the solution to the issue. The authors suggested recommendations based the lessons learned from the project experience. The project experience presented in this paper should be instructive for libraries solving the similar problems. Keywords: email notification issue, Aleph, integrated library system, Ex Libris, academic libraries, library automation INTRODUCTION Ursula C. Schwerin Library Ursula C. Schwerin Library at New York City College of Technology (City Tech) is a member of The Libraries of The City University of New York (CUNY). CUNY is a nation's leading public urban university, which provides high-quality, accessible education for more than 269,000 degree- credit students and 247,000 adult, continuing and professional education students at 24 campuses across New York City (City University of New York, 2015b). CUNY's library system is an academic library consortium of 31 libraries that support learning, teaching, and research to the University's 24 senior, community, honors, and professional colleges, as well as CUNY's more than 100 research centers and institutes (City University of New York, 2015a). The CUNY Central Office of Library Services (OLS) provides centralized services to all 31 CUNY Libraries. The OLS staff works with campus librarians to coordinate and enhance library services. The services provided by OLS include the acquisition, licensing, and management of electronic resources as well as print and digital collections; technical services including cataloging and metadata management; as well as institutional repository management. As a service desk organization, OLS provides direct support and best-practices guidance to CUNY Libraries for all centrally managed library technology services (City University of New York, 2015c). The technologies selected and Xu and Chen / International Journal of Librarianship 2(2) 93 maintained by OLS for CUNY Libraries include: Aleph, Primo, SFX, 360 Link, Digital Commons, EZproxy, ILLiad, CUNY+, Drupal, CORAL, etc. Founded in 1946 as New York State Institute of Applied Arts and Sciences, City Tech is the largest public, baccalaureate college of technology in the Northeast, with over 17,000 enrollment (New York City College of Technology, 2015). The collection of the library contains over 198,000 volumes. The library staff consists of 15 library faculty, 10 adjunct faculty, 10 administrative and technical staff, and many student employees. Aleph integrated library system The Aleph integrated library system provides academic, research, and national libraries with an efficient array of automated tools for managing library materials and streamlining delivery of library services. Developed by Ex Libris, Aleph has been adopted by many academic libraries around the world. Among 9,504 academic libraries included in libraries.org, 17% of libraries are using Aleph 500. Aleph implementation in academic libraries ranks 6th in United States, while it ranks first in United Kingdom (Library Technology Guides, 2015a, b). The Email Notice Issue Libraries often need to send notifications to their patrons for circulation and acquisitions purposes, such as overdue, lost, recall, courtesy, and hold notices. Those notices can be sent either by mail or email. Once a service like overdue notices is set up to generate in the job list of Aleph, the result can be automatically emailed or printed using Aleph print daemon. At City Tech, we send notifications via email, and if there is no email address in aleph for a patron, the notice will be printed. When the author joined City Tech, the Aleph server had stopped sending email notices to patrons for more than one year. The symptom was that email notices would bounce back to the mail server for patrons with non-institutional email addresses, but could be sent to institutional ones. No studies in the published literature were located that concentrated on how to solve the email notification issue in Aleph. The pertinent documentation and other resources did not help resolve this unique issue in our Aleph. How we resolved the issue is the focus of the paper, which might be instructive for troubleshooting and problem solving in similar projects. Related Literature and Other Resources The initial attempt to solve the email notification issue was to search for existing resources. We consulted Aleph documentation, the Ex Libris Knowledge Center (A central place for documentation, training, knowledge articles, and more) (Ex Libris Ltd., 2015b) and the OLS technical support Website (Office of Library Services, 2015). Those resources documented detailed information on automatic notice processing. In the "Product Documentation" of the Ex Libris Knowledge Center, we found several documents related to GUI email and installation, including "How to define exchange to send email via GUI", "How to confirm if your mail server is working", "How to define antivirus to send email via GUI", "How to define the GUI to send Xu and Chen / International Journal of Librarianship 2(2) 94 Email introductory", and "The use of a secure SMTP server" (Ex Libris Ltd., 2015c). Those documents are very instructive for troubleshooting the email notification issue. The first document dealt with unauthenticated mail servers, which stated "There are some exchange servers which are defined to send email to internal email addresses only if they are authenticated users. If this is the case, then the ALEPH GUI will not send email." It also came up with three solutions. The symptom is quite similar as ours, but the solutions seemed not quite applicable to our particular situation. We reviewed literature in library science databases, including Library and Information Science Abstracts (LISA), Library, Information Science & Technology Abstracts (LISTA), and Library Literature & Information Science. The search for relevant information also extended to public Websites. However, none of those efforts obtained effective solutions. Many Websites discussed how to configure settings in Aleph for automatic emailing patron notices, but those solutions were not especially applicable to our library (Florida Virtual Campus, 2012a, b; Webb, 2013). We also sought solutions to the issue in Listserv Archives at listserv.nd.edu and consulted with our peers through those listservs. Many replied to our inquiry with useful insights, including Christine Moulen at MIT Libraries and Theo Engelman at Utrecht University Library. They believed that the problem was related to an authenticated SMTP mail server as it only affected external email addresses. Moulen also suggested checking antivirus software and the local firewall. We tried to follow their suggestions and experience, but the issue still persisted. Based on the review of existing documentation and the consultation with peers, the email notification issue was thoroughly explored with the direction of OLS, and finally the solution was developed and the issue was solved, which will be elaborated below. Later, the author also presented the solution to this issue at the ELUNA 2016 Conference. After the presentation, Ex Libris told the author that they would include my finding in their Knowledge Base as no documentation regarding this issue existed in their Knowledge Center. TROUBLESHOOTING PROCESS The CUNY Libraries' Aleph integrated library system is managed by the OLS staff in close cooperation with several library committees, and the Computing and Information Services (CIS) Department of the CUNY Central Office. Each college campus also has their own Computing and Information Services Department. The CUNY Central Office's CIS is called central CIS, while each college's CIS is referred to as local CIS. The local CIS provides some basic technical services for the library, such as network infrastructure, mail service, creating and managing patron, etc. To realize automatic notice processing for overdue, hold, and other notices, there are many factors to consider, including local administrator status, Aleph client, mail server, Aleph system files, and security settings. We investigated each of those factors and will elaborate them below. Xu and Chen / International Journal of Librarianship 2(2) 95 Local administrator status To let Aleph function properly on a Windows PC, the user account that is logged in should be a local administrator or has administrator privileges. If having local administrator status is not permitted for library staff on their workstations, the IT staff need to alter the settings of the folder that the Aleph client is installed in to grant general user accounts full control of the Aleph folder. Aleph client The Aleph client and the aleph print daemon must stay open at all times for automatic notice processing to work. A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user. The print daemon transfers print files from the Aleph server to the workstation for processing. When the daemon is activated, it periodically looks for files in the print directory of a particular library, transfers those files to the workstation, and prints them on the workstation's default printer. The print daemon can be started manually from the Task Manager of the Aleph Client. However, the daemon needs to be running in the background in order for automatic notice processing. So it is suggested setting the print daemon to be automatically activated when the Aleph client is opened, and automatically deactivated when the client is closed. Mail server To let Aleph send emails, the mail server must be defined. The mail server is not the server on which Aleph is installed, and it is the machine that receives and sends email messages, which must be adjusted to suit a library's particular technological environment. The Aleph system requires a working SMTP (Simple Mail Transfer Protocol) mail server to work properly. Many mail administrators block all SMTP mail traffic. So it is necessary to check with the IT department to see if the campus mail server can be configured to accept SMTP email from Aleph client workstations. Besides it is likely that to have SMTP mail work in Aleph, the workstation needs to be assigned a valid static IP address. To investigate our particular issue, SMTP mail server was our focus factor of this research work. Like other college campuses, we had been always using OLS SMTP mail server in Aleph. We learned from OLS that we were the only college campus had such an issue, and other campuses had not. Also this issue happened around one and a half years ago. At that point, we did not change Aleph system configurations or SMTP mail server. So it seemed that this issue was not caused by mail server. Nevertheless we wanted to test to see if we could send notifications to external email addresses by using our campus CIS' SMTP mail server. However, our campus CIS informed us that we had no local SMTP mail server on campus. Aleph system files To enable automatic notice processing, two Aleph system files, alephcom.ini and circulation print.ini, need to be updated. Those system files are respectively located in the directories of AL500\alephcom\tab and AL500\circ\tab. In the [PrintDaemon] section of alephcom.ini, the print Xu and Chen / International Journal of Librarianship 2(2) 96 daemon can be configured to be active every time the Aleph client is started. The targets parameter needs to be set to tell the daemon which notice jobs to look for. The Mail server should be defined in the [Mail] section, which must be adjusted to suit a particular library's environment. The names of the notice jobs that the Aleph client watches for set in alephcom.ini need to be added in print.ini. This allows the Aleph client to know what to do with the content of the notice jobs. The file print.ini is also the place to specify how notifications are delivered. Notices can be set to be emailed directly to patrons. If there is no email address for a patron in the Aleph record, the notice will be printed. If there is a bad email address in the record, the notice would bounce back to the mail server. Notices can also be set to be printed only or both printed and emailed. We thoroughly checked each entry in those Aleph system files, and also had OLS staff examined them, and we did not find any anomalies. Security settings First of all, we extensively investigated antivirus software for security settings. The document "How to define antivirus to send email via GUI" stated that Aleph GUI sends email via a SMTP mail server port 25. In computer networking protocol, a port is a logical construct that identifies a specific process or a type of network service. Many antivirus PC programs by default have this blocked. OLS also instructed that for the installation of Aleph GUI there is a known antivirus issue: McAfee Antivirus can interfere with emails being sent by Aleph to patrons, and it must be modified to allow exceptions. It seemed that the McAfee access protection rules blocked certain network port, and filtered the email feature as malicious. We also noticed McAfee logs stating "Anti-virus Standard Protection: Prevent mass mailing worms from sending mail" from Aleph. So we adjusted security settings in McAfee Antivirus and placed exceptions in access protection that prevents mass sending mails, and even had McAfee completely turned off, the problem still persisted. Then we thought this issue might be related to firewalls or local group policies set on the workstations. We had our local CIS IT staff checked firewall settings, and they did not find anything that prevented emails from being sent. To see if local group policies affected email notices, we tested to send notices from Aleph client on a freshly installed PC, but this did not work either. We virtually exhausted all of above-mentioned factors contributing to the email notification issue. Revisiting all those factors, local administrator status, Aleph client, mail server, Aleph system files, and security settings, we could certainly rule out all of them except for mail server. So we reset our focus on the local SMTP mail server. From the URL of the faculty web email, we figured out our possible local SMTP mail server. In an effort to dig further into the email settings with Aleph and SMTP, we listed as many parameters as we knew for our local college SMTP server to try to reproduce the same problem programmatically using PHP. //Local college SMTP parameters $config['protocol']='smtp'; $config['smtp_host']='email1.citytech.cuny.edu'; // <<-- SMTP host IP $config['smtp_port']='25'; // <<-- host port $config['smtp_timeout']='30'; Xu and Chen / International Journal of Librarianship 2(2) 97 $config['smtp_user']='libsysservices@citytech.cuny.edu'; // <-- Account to log in SMTP $config['smtp_pass']= 'Actual password here' // <-- Account password $config['mailtype'] = 'html'; $config['charset'] = 'utf-8'; $config['newline'] = "\r\n"; There are many ways to confirm if the SMTP mail server is working, including sending mails from a PC without using the GUI by directly typing commands (see "How to confirm if your mail server is working"). If it works without the GUI, then it should work with the GUI. Likewise if the PC cannot send mails with the defined mail server without the GUI, then certainly the GUI will not be able to deliver mail. During testing the settings with different parameters, including ports and with/without a valid user account on the local SMTP mail server, we found out that the problem lay in the authentication for our local SMTP mail server. Using the PHP script with a valid user and password for the mail server, we were able to send emails to any valid email accounts, regardless for internal or external email addresses. On the other hand, without a valid user account, the PHP script had the same symptom as in the Aleph client that internal email addresses could be reached and any external ones were rejected. At this point, we virtually certainly believed that our issue was due to the mail server. The test reminded us that we might actually have already found the solutions to our problem during literature review ("How to define exchange to send email via GUI"). We reported what our findings to OLS, and they believed that our college has a local SMTP mail server that requires authentication for sending emails to external email addresses. They suggested using the secure SMTP email protocol by adding "AuthMethod=LOGIN" in the Aleph system file alephcom.ini, and then tested to see if the Aleph client would ask for the user name and password. When testing, we got the error message "Authentication; User Name required". Previously when trying to send notices to external email addresses, the error message we got was "Errors detected in required email(s)". It seemed that the solution might be workable. So we planned to include the authentication in the Aleph client permanently. The user name and password to log in to the local SMTP mail server can be included in Aleph via the Aleph admin module. By clicking "E-mail Settings" in Alephadm GUI module under the "Configuration" menu option, a dialog box "E-mail Settings and Options" would appear where we could choose the authentication type and enter the user name and password to log in to the mail server (Figure 1, 2 and 3). Each time a user name and password is entered into the system, a file called EMailPwd.dat will be created that contains the authentication in an encrypted format. The EMailPwd.dat file should be put in the directory AL500\alephcom\tab\ in the Aleph client. Then we tested again, and finally we could be able to send notices to both internal and external email addresses. Xu and Chen / International Journal of Librarianship 2(2) 98 Figure 1. The AlephAdm module Figure 2. Authentication types in the AlephAdm module Figure 3. The username and password in the AlephAdm module Xu and Chen / International Journal of Librarianship 2(2) 99 DISCUSSION At City Tech, like all other CUNY colleges, we had always been using OLS SMTP mail server for Aleph. Since all other CUNY colleges had no email notification issue, when this issue occurred to us, what we have been troubleshooting concentrated on security issues, and settings of the Aleph client, and the SMTP mail server was the least factor to consider. After we had virtually exhausted all factors contributing to the email notification issue, we realized that the SMTP mail server was the most likely culprit. As a matter of fact, we suspected from the beginning that the email notification issue was due to the settings of the local SMTP mail server. However we were told by our campus IT that we had no local SMTP mail server on campus. Nevertheless we managed to figure out our local SMTP mail server and tested that we could send notifications to external email addresses by using it with the authentication information. We assumed that our local CIS administrators, at a certain point, had somehow configured our local network to allow sending emails to external email addresses only through a local authenticated SMTP server account. Later this assumption was confirmed by our local CIS, and they made this change in our local SMTP server for authentication due to security. Ever since they modified the mail server, the Aleph client stopped sending email notices to external email addresses. Although we had always been using the OLS SMTP mail server, the change on our local SMTP server prevented the email notices sending to external email addresses. This can be explained that even though the OLS SMTP mail server works independently from our campus network, the email transmitting process will be starting from our local workstations. That is why even local firewalls, group policies and antivirus software on the workstations can prevent or allow this process. RECOMMENDATIONS We learned a lot from the experience of the project. Here are some recommendations that we feel useful when undertaking similar projects. Troubleshooting process: As troubleshooters, we all know that obviously there is no substitute for experience in troubleshooting. But troubleshooting is a set of attitudes, priorities and procedures that should be followed: • First of all, getting a good attitude is very important. In troubleshooting, we must have the right attitude to succeed. We can solve it, it is not magic, and there is always an explanation. Like Gene Wolfe, an American science fiction and fantasy writer, said in his book, Shadow and Claw, "There is no magic. There is only knowledge, more or less hidden." Above all, our troubleshooting power comes from our troubleshooting process. • Then, we need to set our priorities and follow some certain procedures. Prior to doing anything that could cause damage, we should make a damage control plan and determine appropriate precautions, such as machine precautions that prevent damage to the machine or system, and data precautions that prevent loss of valuable data. Xu and Chen / International Journal of Librarianship 2(2) 100 • The next step is to reproduce the symptom. If we have not reproduced the problem, we cannot toggle it on and off to narrow the scope of the fix. This step can also help develop the accurate symptom description. This is very crucial during troubleshooting if we ask someone else for help. The more accurate and detailed the symptom description, the less work we have to do. A good symptom description minimizes the risk of "fixing the wrong problem". • And then narrow it down to the root cause, which is the core step of troubleshooting. Mathematics tells us the fastest way to find a single element in an ordered set is binary search. Binary search is the process of repeatedly ruling out half the remaining search area until the element is found. If we keep narrowing it down, whether binary or not, as long as we do not repeatedly double back in areas we have already tested, it is a mathematical certainty that we will eventually find the problem. This process can be thought of as continually forcing the problem into ever smaller boxes, until it is trapped (Litt, 2014). • The last step of troubleshooting is to take preventive actions, for example, do appropriate maintenance, document the symptom and solutions, etc. As the case at hand, we investigated all possible factors that affected the email notification issue, from a minor and easily fixed factor to a more complicated one. First of all, we checked local administrator status at the workstations, and confirmed that the Aleph client and the aleph print daemon stay open all the time. Then we examined the configurations of the SMTP mail server and Aleph system files. The last we explored the security settings, including antivirus software, firewalls and local group policies. Although after exploring all possible factors, we did not catch the culprit, we narrowed the scope of the fix and set our troubleshooting target, and eventually we fixed our problem. Lessons learned: Our problem was quite unique. When it occurred, first we contacted our consortium and tried to find out if other CUNY libraries had the same issue as all CUNY libraries use the same system. We were told that we were the only library had such an issue, and then we realized that the problem might come from our local campus. Our consortium suggested that we check with our local CIS to see if the local SMTP mail server, antivirus software, firewalls or group policies affected the email notification. On hearing that we had no local SMTP mail server, coupled with the fact that all other CUNY colleges had no email notification issue, the SMTP mail server was the least factor for us to consider. So we checked all those factors that our consortium suggested except the local SMTP mail server, however we did not find any problem. Then we reset our focus on our local SMTP mail server, and eventually figured out our possible local SMTP mail server. During testing, by using the PHP script with a valid user and password for the local SMTP mail server, we successfully sent emails to any valid email accounts. Therefore finally we fixed the issue. Only then did we suspected that the settings of our local SMTP server might have been modified to allow sending email notices to external email addresses only through a local authenticated SMTP server account. Later this assumption was confirmed by our local CIS, and they modified our local SMTP server due to security concerns. We learned some valuable lessons from our troubleshooting process: Xu and Chen / International Journal of Librarianship 2(2) 101 • Consulting other libraries is helpful, but that is all it can ever be. To find out whether other libraries with a similar technological environment, especially the libraries within the same consortium, have the same issue is always useful. However, if they do not have the issue as we do, this does not mean that we can certainly rule out some similar contributing factors to the issue. One the other hand, however, this can indicate that the issue might be local one. Like all other CUNY colleges, we had always been using OLS SMTP mail server for Aleph. Since all other CUNY colleges had no email notification issue, we assumed that this problem was certainly not due to the SMTP mail server, and it was least factor for us to consider. As a matter of fact, we did not realize that our local CIS had changed the settings of the local SMTP mail server, which actually was the root cause to our issue. • Regular meetings with the local campus IT is necessary. During the troubleshooting process, we discussed the issue with both OLS and our local, and they claimed that the problem lay in the other side. Later we found that both the Aleph server and the OLS SMTP mail server were working for all other CUNY colleges, which proved that the issue was the local one. This also reminders the authors of another incident. Once our local CIS migrated to a new set of IP address ranges, but they did not inform us of the change because they did not realize this would affect us, which caused a big problem for our library. Those incidents tells us that regular meetings between the library and the local campus IT is very important whenever there is any change in technological environment. We now have regular and periodic meetings between the library and our local campus IT, whether for sharing information between two sides, for discussing each side's new projects or the projects are undertaking, or for any technological environment changes. This open channel seems to work very well for us. CONCLUSION Aleph is a very popular integrated library system, and has been adopted by many academic libraries around the world. Libraries frequently send notifications using integrated library systems to their patrons for circulation and acquisitions purposes, and those notices can be sent either by mail or email. Nowadays the use of mobile devices for studying skyrockets among college students. Therefore sending email notifications has become a more preferable way for libraries. The email notification issue is a very typical and complex issue which will likely occur to any libraries. This article identified main factors contributing to the issue and provided pertinent solutions. The experience and solutions elaborated in this article will shed light on problem solving in similar situations. References City University of New York (2015a), "Libraries - CUNY", available at: http://www.cuny.edu/libraries.html (accessed 1 October 2015). Xu and Chen / International Journal of Librarianship 2(2) 102 City University of New York (2015b), "The Nation's Leading Public Urban University", available at: http://www.cuny.edu/about.html (accessed 1 October 2015). City University of New York (2015c), "The Role of the OLS", available at: http://www2.cuny.edu/about/administration/offices/library-services/about-us/ (accessed 1 October 2015). Ex Libris Ltd. (2015a), "Aleph Integrated Library System", available at: http://www.exlibrisgroup.com/category/Aleph (accessed 1 October 2015). Ex Libris Ltd. (2015b), "Introducing the Customer Knowledge Center", available at: http://support.exlibrisgroup.com/ (accessed 1 October 2015). Ex Libris Ltd. (2015c), "Product Documentation", available at: http://knowledge.exlibrisgroup.com/Aleph/Product_Documentation (accessed 15 July 2015). Florida Virtual Campus (2012a), "Email Notices from the Server", available at: https://fclaweb.fcla.edu/node/4683 (accessed 1 July 2015). Florida Virtual Campus (2012b), "How do I setup Printing/Email?", available at: https://fclaweb.fcla.edu/content/how-do-i-setup-printingemail (accessed 1 July 2015). Library Technology Guides (2015a), "Market share report: Academic Libraries in United Kingdom", available at: http://librarytechnology.org/lwc-ils- marketshare.pl?Country=United+Kingdom&Type=Academic (accessed 1 October 2015). Library Technology Guides (2015b), "Market share report: Academic Libraries in United States", available at: http://librarytechnology.org/lwc-ils- marketshare.pl?Country=United+States&Type=Academic (accessed 1 October 2015). Litt, S. (2014), "The Universal Troubleshooting Process (UTP)", available at: http://www.troubleshooters.com/tuni.htm (accessed 1 December 2015). New York City College of Technology (2015), "About City Tech", available at: http://www.citytech.cuny.edu/aboutus/ (accessed 1 October 2015). Office of Library Services (2015), "Support @ OLS - Technical Support for CUNY Libraries", available at: http://support.cunylibraries.org/ (accessed 1 October 2015). Webb, H.J. (2013), "Emailing Patron Notices Automatically in Aleph", available at: https://librarywebbsolutions.wordpress.com/2013/11/18/emailing-patron-notices- automatically-in-aleph/ (accessed 1 July 2015). Xu and Chen / International Journal of Librarianship 2(2) 103 About the authors Gordon F. Xu is a Systems & IT Librarian (Coordinator) at New York City College of Technology. He holds a Master of Library and Information Studies, a BSc and MSc in Natural Sciences. He provides technical support and system development for the smooth functioning of library automation systems. He can be contacted at: fxu@citytech.cuny.edu. Yi Chen is working as an IT Associate at New York City College of Technology. He can be contacted at: yimechen@citytech.cuny.edu. 07.Uncovering email notification_title 07.Uncovering email notification