8 – Email

The 8.x parameters have been provided to manage aspects of how RefTracker interacts with email.

8.2 Service email address: This should be an email address set up for the specific purpose of being seen to be the address from where RefTracker emails come. Often libraries will set up a new email address that reflects their RefTracker service name for this purpose e.g. <reftrackerservicename>@<yourDomain> which would need your IT department’s assistance, or for hosted systems, Altarama can provide you with an address.

If your IT department provides you with an address for this purpose, it is important that the address is correctly set up so that the outbound email sent from it is not detected as spam. RefTracker provides a configuration file at config/setting/mailserver.xml that provides a number of ways to configure the connection to this email address, if that is necessary. Your RefTracker support representative, who has access to the Support manual where documentation for this file can be found, can help your IT department with set up using the config/setting/mailserver.xml file.

Most customers will want to associate an alias for their Service email address using this parameter 8.2 by specifying the alias in front of that email address, in double quotes – for example if you specify “ABC corp” abc@reference-service.info in parameter 8.2, email from your service will appear to come from ABC corp as shown in the screen print below. 

If you do not want to use RefTracker Email importing, the email address you specify here has to be monitored for any replies and non-delivery notices returned to it.  This is usually done having your email system manager redirect this email address to your System administrator, or to a shared email address that is monitored by your library team.  Email arriving back at this address will have to be read and any updated required to RefTracker will have to be manually made so it might be useful to make the email address something like DoNoReply@<yourDomain>.

However most organisations will use RefTracker Email importing so that email arriving back at this address (such as non-delivery notices and replies not submitted using the RefTracker links provided) is automatically integrated into the appropriate RefTracker question and the allocated staff member notified. In that case, this Service email address must be an account dedicated to RefTracker outgoing email and set up as a POP3 or IMAP account. For in-house RefTracker systems your email system manager will have to set up this email account with its POP3 or IMAP access. If you have a hosted system and use, or would like to use, a reference-service.info, researchservices.info, or libraryresearch.info email account, Altarama will happily set this up for you. Hosted customers can also use their own email accounts if their IT department will allow relaying to a POP3 or IMAP account.  As this email account is email in relation to already existing RefTracker questions (primarily outgoing email), some organisations set the alias to something like “from ABC corp” to emphasise that new requests should not be submitted through this email address.  Click here for information about setting up email accounts where new questions can be submitted.

8.3 Email importing alerts address: This is the email address (or addresses separated by a semicolon) to which alerts about issues with importing specific emails will be sent. Alerts about email importing issues are normally sent to the Active system administrator, and leaving parameter 8.3 blank will result in that continuing to happen. But often, especially when the System administrator is from IT, or a support department, or is Altarama (when the contract administrator service is used), Administrator alerts about emails that cannot be imported (such as when they come into the Service email address but do not include a valid request number in the subject line, as is the case for many non-delivery notices) need to be sent to an address/es where reference staff will see them and be able to address them quickly. If this is the case for you, you will normally enter a shared email address used by your reference staff in this parameter.

Note that email addresses set as Resender addresses in System>Batch process menu>Data import/export>Email importing are automatically removed from all emails, so this address cannot be an address set as a Resender address.

8.5 Maximum email attachment size client (Mb): This parameter determines the total size of attachments to a client or third party (Refer or Redirect) email generated by RefTracker, that will result in the attachments being delivered in that email as hyperlinks instead of traditional attachments. The value set here (default 9Mb) applies only to client/requester emails. This parameter is important in reducing the volume of traffic passed over the internet, and in ensuring that emails to clients can be received even when the client’s email system has a small size limit on attachments, or their email box is nearly full. It will also reduce the number of non-delivery notices that staff have to deal with, and eliminate any possibility of an infinite loop of emails being generated by non-delivery notices being imported from a full email box, only to generate a confirmation email that generates another non-delivery notice, and so on. Please take the time to review this parameter. The default value is 9Mb, to ensure that emails fit under the common email box size limit of 10Mb, but If you are a public library you may want to lower this figure to 4Mb to ensure your emails can be delivered to clients that have low attachment size limits. Hosted customers should not increase this value past 14Mb as Altarama’s hosted system email server is set to 20Mb of encoded text in order to retain our reputation as a good email sender – constant sending of large files could result in Altarama being blacklisted and all our hosted systems unable to send email so this is an important limitation. If you run an in-house system where emails are only ever sent in house you may want to increase this limit to match the limit of your in-house email system. Parameters 2.7 and 2.8 set the maximum individual file size that clients/requesters can upload to RefTracker, and this parameter may also need to be increased by in-house customers. You will need to balance the benefits of not having large documents occupying email boxes and the convenience of having attachments where clients traditionally expect to see them – in the attachment line, versus them being provided as hyperlinks at the end of the Answer text in that email. Note that hyperlinks to access attachments presume that the attachments are file types that can be viewed by a web browser. If you deliver attachments that cannot be viewed by a web browser, you will need to ensure that the value you set here is larger than the largest size of the files you send that cannot be viewed by a web browser (though the browser should offer an option to download files it cannot display). Setting this parameter to 0 will ensure that all attachments go out as hyperlinks, should you wish that to happen. 

8.6 Maximum email attachment size staff (Mb): This parameter determines the total size of attachments to a staff email generated by RefTracker, that will result in the attachments being delivered in that email as hyperlinks instead of as traditional attachments. The value set here (default 0Mb, so that means ALL attachments sent to staff in emails from RefTracker will be sent as hyperlinks) applies only to staff emails. This parameter is important in reducing the volume of traffic passed over the internet, and in ensuring that emails to staff do not unnecessarily fill up the staff member’s email in-box. You may wish to increase this parameter if you want staff to be able to see the attachments outside of your secure in-house environment (if you are set up that way). If you use a hosted system, this value should ideally be set to 14Mb or less. Parameter 2.7 sets the maximum individual file size that staff can upload to RefTracker, so take a look at that parameter at the same time as you consider this parameter 8.6.

8.9 Mail server connection timeout: This relates to the amount of time that the system will wait for a connection to the email server where it picks up email for importing. It allows for adjustments to the timeout value where a slow connection to that email server exists. You should never have to adjust this value unless advised to do so by Altarama. The default is 10 seconds but the time can be extended to handle slow connections. The background process will not start a new import until the current import is finished, but nevertheless, if you are extending this parameter, think about scheduling the email import frequency to more than 1 minute!

8.10 Email alert delay: Administrator alert emails generated due to email server connectivity issues are ignored for the period that you specify here. We recommend that the value of this parameter should be at least the default value of 5 minutes in order to ensure that you do not receive multiple alerts in relation to issues that automatically resolve themselves, such as email server reboots, and short Internet drop outs. Using an example parameter 8.10 value of 10 minutes (default value), the connection would have to fail continually for 10 minutes before an Administrator alert email is triggered. After that email alert is issued, a new Administrator alert email in relation to the same connectivity issue will not be sent for double the amount of time since one was last sent up to a maximum of 120 minutes (so for the default 10 minutes value of this parameter notices would be issued at 10, 20, 40, 80, and 120 minutes, then at 120 minute intervals until the issue is resolved when they will stop automatically.

8.11 Connection failure notification: This is the number of consecutive email connection failures that can occur for any given email importing account before a notice is provided about the failure. The default value of 10 will ensure that customers with email importing pickup rates of 1 or 2 minutes are advised promptly if email importing is likely to be down (has not picked up for 10 or 20 minutes), but are not advised if it is just too busy to service all pickup requests. Customers with less frequent pickup rates may want to reduce this parameter to ensure they are notified more promptly.

8.12 Address limit for imported email: Allows for adjustments to the number of to:, or cc: email addresses in an imported email before the email will be regarded as spam, and advised to the Parameter 8.3. email address instead of being imported as a new question.  For example, the default setting of 20 means that if an imported email has 21 addresses in the cc: field, it will not be imported as a question.  Instead the Parameter 8.3 email address will receive an email containing the contents of that email, including all the email addresses in the cc: field, so that the person monitoring that email address can make a decision about whether to manually create a question from that information, or just ignore the email as spam.  Note that the bcc: address field is also checked, but when the RefTracker email importing address receives an email that was sent as part of a long bcc: list as spammers do, the email arrives with the RefTracker email address in the to: list and the bcc: field empty.

8.13 Email from address preference: Allows your organisation to choose the precedence of email address fields to be used when determining the client’s email address from imported emails.  Customers should not normally need to change this parameter as the default setting of “ReplyTo,ReturnPath,From” is the industry standard, allowing RefTracker to automatically pick up the correct email address for RefTracker to reply to, for both personal emails and emails sent on behalf of clients such as from an online database. 
If you need to change this parameter, all three values must be present and separated by a comma.
Ask Altarama for assistance if the email address being determined by RefTracker is not correct for your system. Also talk to your Altarama representative if you need this feature per imported email address rather than system wide as a further development if being considered to support that. 
You can see the Reply-To, Return-Path, and From address information being provided by your incoming emails by viewing the Message header information recorded for the imported email in the History of the question.

8.14 Import email attachment sentinels: This parameter allows the text used to identify an email as containing .eml files as attachments that need to be imported into RefTracker.  The default identifying (sentinel) text that staff add to the subject line is

$import
It can be added anywhere in the Subject line of the forwarding email.  But if your organisation operates in multiple languages, or happens to use $import for other purposes, this parameter allows you to define one or more unique pieces of text that can be used for this purpose.  For example, if your organisation operates in English, French and Italian you might want to set three sentinel words that can be used (each must be on a separate line in this parameter).
Or you might prefer to change
$import
to a language independent key such a
$%^&
The sentinel text you define here must be unusual as the occurrence of this text in any imported email subject line will result in the attachment creating a question rather than the question itself, if the attachment/s is an .eml file.

Exercise:

Consider the effect of these parameters on your library’s requirements. Make any desirable changes, and if you make any, click on Update. Then in Select parameter group choose 80) Application.