Portals
Transforms
Actions
PDF
Print to
Windows printing
Text markup
Queues
How to
Workflow
Archive
Email
Purpose
In order to meet the expectations of the LPD user community, RPM Remote Print Manager® ("RPM") provides notifications and alerts directly. RPM also emails print jobs directly to users.
The LPD print protocol has an option to send an email notification when a job prints successfully. We had wanted to do that for some time, and when we added the email action in RPM 5.0 the door was opened for us.
How RPM uses email
Today we have three distinct uses for email:
- Send a print job (the email action)
- Send notification that a job printed (status)
- Notify someone that there is a problem that needs attention (alert)
Let's explore the underlying issues these have in common.
Under the hood
The most important thing about RPM's email capabilities is this:
RPM connects to a mail server. We don't send an email directly to your Outlook inbox.
In that sense, RPM is not quite as friendly and mail-attuned as your current email program or Web service. We send the mail but we require just a little bit of work on your side. Note that Outlook is configured to work with your Exchange server, and your Web mail client has mail services readily available to it, but RPM has none of those luxuries.
So, the points we make below all have to do with connecting to and working with a mail server.
The mail server
When sending any email, the first question RPM asks is: what mail server do we connect to? We consider two things when addressing that issue:
- if the user specifies a mail server, then we use that
- otherwise we get it from the "to" address
The way we get the mail server from the "to" address is by looking at the text after the "@" character. We give that to a network function that looks up the mail services for that address. For instance, take "support@brooksnet.com". The network tells us that the mail services for "brooksnet.com" can be found at "mail.brooksnet.com".
Your results will vary, of course. Your organizations mail server won't necessarily be called "mail.example.com".
Login Authentication
The next step is login authentication, also called "SMTP Auth". Some mail servers require a login and password. This is not part of the normal mail protocol; it was added due to the rise of spam. Login authentication is a way of telling a mail server that you are a customer of this organization and have a legitimate right to use their mail software.
We all know about logging in to a mail system to see our own mail. This is about proving who you say you are when you send mail. That's the difference.
If your mail server requires this, then use the user login and password provided by the setup.
Relaying
Another issue to consider is this: the mail server you use may not allow you to relay. Again, due to spam, many mail servers are set up to receive mail only, but not to send it off site (when you connect the way RPM does).
For that reason you may want to leave the "SMTP server" blank and let RPM connect to the site that is going to receive the mail, by using the "to" address as describe above. Or, check with your network staff to see if you have a mail server in-house that is configured to relay.
Final
The "from" address needs to be compatible with your mail server. If you use the form:
user @ domain [without the spaces]
where "domain" includes .com, .net, etc., then you are probably in good shape.