This article applies to: AppSMTP
What is AppSMTP?
AppSMTP is an email relay. It is used by multi-function printers (scanners), other devices that send email (such as monitoring equipment), and processes such as websites that need to send email.
Why is CIT changing AppSMTP?
Over 90% of attacks on organizations begin with malicious email. In cooperation with the IT Security Office, CIT's email team is making changes to reduce exposure to potential email abuse. AppSMTP is a target because it can relay mail from any sending email address to any place in the world.
The new AppSMTP puts limits on how it can be used, which makes it a must less exploitable target.
- All sending addresses must be registered.
- You can only send from an email address that is associated with an EGA - Exchange Group Account.
- All mail is routed by Office365 which checks for viruses.
- Via the AppSMTP portal, you specify which hosts are allowed to use your email sending addresses.
I’m not an IT person. Why was I contacted about this?
If you don’t work in IT, please forward any messages you receive about this project to your department’s IT group. In an effort to make sure all IT folks were aware of the upcoming changes, CIT sent messages to everyone listed in various databases related to IT.
Can I use a single EGA for multiple sites?
Yes. The portal allows you to enter as many hosts as you need for a single sending address.
What connection settings work with AppSMTP?
AppSMTP only uses port 25. TLS is generally recommended, but not required. However, if you are using the certificate authentication method, you must also use TLS.
But I’ve got 250 MFPs to support. Do I need to enter all of their IP Addresses?
No. You have two options:
- Enter one or more CIDR ranges that cover all of the hosts instead of entering individual addresses.
- Use a SAN certificate that covers all of the hosts.
The portal says that my address is already registered, but I need to add my host IP to be used with that sending address.
The only people that can register a sending address are admins for the EGA associated with the address. You can find out who they are using the EGA Management Tool. Once you find out who created the registration, ask them to add you as an admin for the registration. Best practice is to always add all EGA admins as admins for the AppSMTP registration to avoid this lockout situation.
How will I know if my new registration is working?
You are currently being covered by broad pre-registrations CIT made that do blanket coverage of entire domains, such as @cornell.edu. These pre-registrations will be removed in mid-April. When you use one of these it is seen in CIT’s logs as distinct from an explicit customer registration. CIT will send at least two more mailings that will only be for systems that have not been registered by the customer. If you don't get another email, then you know you're good to go. Otherwise CIT will be contacting you periodically between now and mid-April.
If, come April, we miss a script, will there be some form of error process that will inform us of failed sends, or must we identify “missing” mail on our own?
After CIT does the cutover, you will get a 500 error if you try to send through AppSMTP using a sending address that wasn’t properly registered.
How will we continue to point services toward appsmtp.mail.cornell.edu?
Same as you are now. The new system is still at appsmtp.mail.cornell.edu.
I have a lot of code that generates sender addresses in the form of “root@[hostname]”. It’s been a pretty standard approach for a very long time. Is there some way to accommodate this without creating EGAs for every server or seeking out and editing scripts?
Not exactly. If you need to identify that the message came from a specific host and don't want to create an EGA address for each host you can use sub-addressing. This is what CIT's server farm team will be doing. Wikipedia’s article does a good job of explaining sub-addressing.
Is it possible to send in an excel spreadsheet to you to get them uploaded into the AppSMTP registration pool?
No, CIT is not offering that service at this time.
Can I use a certificate?
This depends on whether or not your application supports the use of a certificate. You should check the documentation for the software or device that you are using to see if it supports certificate authentication.
What does the certificate do?
A certificate can identify your host when it sends email. It is used in place of an IP address or Hostname. The certificate is presented to AppSMTP when you service/device connects.
Does the certificate identify the sender?
No. A certificate only identifies the server or application that is sending the email. You must still register each email address that will be used to send email.
Why would I use a certificate?
If you have a server that changes its IP address or name often (such as an AWS using elastic IPs) then using a certificate will not require re-registering your host when your host changes IP addresses.
How is the certificate used?
When you register a certificate, we extract specific information from the certificate so that your application can be identified when it connects to AppSMTP. We do not store your certificate.
What kind of certificate should I get?
This depends on the nature of your application.
- Single Server – for use on a single server.
- Multi-Domain – used when your application will send from multiple host names.
- Multi Host – uses the came certificate on multiple hosts.
How long does a certificate last?
Certificates have a one-year lifetime if you use the IT Security Office’s Certificate Service, so they will need to be renewed once per year.
Where can I get a certificate?
The IT Security Office offers no-cost SSL server certificates through the InCommon Digital Certificate Service. Please see the SSL Server Certificate site on IT@Cornell for more information.