The SMTP-relay service supports sending email for devices, such as faxes or copy machines, that can't authenticate properly with an existing email service such as PennO365 or GMail. This service should not be used by vendors or services that are not managed by a Penn staff or faculty member.
- Service Overview
- Ordering Service
- Client Requirements
- Client Configuration
- Sample Server Postfix configuration
Simple Mail Transfer Protocol (SMTP) is the communication protocol used on the internet to send email. The SMTP protocol uses a store and forward technique to accept email from remote senders (servers, work stations or other devices), store it temporarily and then deliver it either to a local email account, or forward it to another server (using the same SMTP protocol) that has been advertised on the internet as the server able to receive email to a specific email address.
ISC maintains an SMTP-Relay service that allows devices to relay email to destinations on the internet. The SMTP-Relay service will accept, store and forward the email to the correct SMTP server on the internet. This allows devices that are not able to implement the full SMTP protocol, such as scanners, lab equipment, etc. to still send email. The service will not permanently store email locally.
The ISC SMTP-Relay service will accept email for email addresses that are part of the Penn email environment. Those are emails that are in the following email domains:
|
ac.upenn.edu |
hep.upenn.edu |
phil.upenn.edu |
Additionally, the service will accept messages destined for email addresses that are anywhere in the world, if the device sending the email is registered with the service. You can find details on how to register devices with the ISC SMTP-Relay service on the Ordering Service tab. The service will only provide support for clients who have registered their device with the service.
If you need to use the SMTP-Relay service to deliver messages to email addresses not affiliated with Penn, you need to register the name of the device sending the email. To register that device, you will need to fill out an SMTP-Relay Request. Once this form has been submitted a staff member will contact the requestor to finalize the registration and set up the service for their use.
Clients that register with the SMTP-Relay service to deliver message to email addresses not affiliated with Penn need to comply with the following requirements:
- The client should use a Kerberos service principal with a password to gain authorized access to the service. Typically that principal will be in the format smtp-relay/<servicename>.<tld>.upenn.edu, as an example smtp-relay/sendservice.isc.upenn.edu. Please work with your Local Support Provider to obtain such a Kerberos service principal. If the client software can not support SMTP authorization, please indicate this in the comment area on the registration form.
- The client is required to use the STARTTLS option of the SMTP protocol when authenticating to the SMTP relay server with the Kerberos service principal.
- The DNS name of the system needs to be able to be reverse resolved by DNS to it's registered IP address. This means that if the name of the server resolves to a specific IP address (the DNS A record), the reverse lookup of that IP address needs to resolve to the registered name (the DNS PTR record). If the lookup of the IP address does not match the name, or no name can be found, the SMTP-Relay service will not deliver email to non Penn-affiliated addresses.
- The SMTP relay service generally does not support systems that are protected by a firewall that performs Network Address Translation (NAT). If SMTP relay service is needed by a system behind a NAT firewall, or by systems that are on a cloud provider (such as AWS or Azure), authentication using a Kerberos service principal is required.
- The client software using the SMTP-Relay service is required to use a valid email address as the 'From' address. This is required for the SMTP-Relay service to be able to send a 'Non-Delivery-Report' (NDR) for emails it could not deliver to a remote email system. Inability to deliver NDRs by the SMTP-Relay service to the 'From' address will result in suspension of the service for the mis-configured device. To restore service, a ticket with the ISC Help desk will be required after the mis-configuration of the device has been mitigated.
- The client software should not use personal email addresses as the 'From' address, but rather use a functional account email address or mailing list.
- This service should not be used for personal devices at home locations.
- The SMTP-Relay service should not be used for sending bulk email. The PennNet Mailing Lists service should be used for that purpose.
Client configuration option naming conventions are highly dependent on the software used to relay Email. General configuration is as follows:
| Description/Name | Value |
|---|---|
| SMTP Relay Server Name | smtp-relay.upenn.edu |
| SMTP Relay Server Port | 25 |
| SSL/TLS/STARTTLS | Enabled |
| Username | Kerberos Service Principal, e.g. smtp-relay/servicename.upenn.edu |
| Password | Password shared from Kerberos Team when creating the Kerberos Service Principal |
Servers can be configured to use the SMTP Relay service as well. Please note that it is important to configure the software in such a way that sending email addresses are valid. Below please find a sample Postfix configuration that uses rewriting rules to update email messages emitting for system accounts. The sending address in the sample uses pre-configured email address, sampleaccount@tld.upenn.edu, that additionally uses the submaddressing mechanism to show the original sender. If needed, your email administrator can help you with setting up a specific address in the Penn Email Routing application.
/etc/postfix/main.cf:
myhostname = systemname.tld.upenn.edu
#
# setting the origin to the hostname will allow the
# virtual_alias_maps to be used effectively.
#
myorigin = $myhostname
#
# relay everything through smtp-relay.upenn.edu
#
relayhost = smtp-relay.upenn.edu
#
# only listen for local connections, e.g. cron email
#
inet_interfaces = loopback-only
#
# no local delivery of email at all
#
mydestination =
#
# We will allow relaying from localhost (mynetworks, since we
# only listen on loopback)
#
smtpd_relay_restrictions = permit_mynetworks, reject
#
# Since there is no local delivery, /etc/aliases will normally
# *not* be consulted. But the virtual_alias_maps *will* be.
# Therefore virtual_alias_maps is just set to /etc/aliases.
# Ensure that *any* email coming from local accounts is accounted
# for in the /etc/aliases. The easiest way to do this is to make
# everything come from the local root account and have one alias
# in the virtual_alias_maps that routes to an actual working
# address e.g. root@isc.upenn.edu. example entry:
#
# root: sampleaccount@tld.upenn.edu
#
# Do not forget to run 'postalias /etc/aliases' after updating
# /etc/aliases.
#
virtual_alias_maps = hash:/etc/aliases
#
smtp_tls_security_level = verify
#
# rewrite all addresses to they appear to come from vmic@upenn.edu+lhs-machinename
#
sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps = regexp:/etc/postfix/sender_canonical_maps
smtp_header_checks = regexp:/etc/postfix/header_check
#
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/smtp_sasl_password
smtp_sasl_security_options =
#
smtp_tls_loglevel = 0
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
/etc/postfix/smtp_sasl_password:
smtp-relay.upenn.edu smtp-relay/servicename.tls.upenn.edu:random_password_here
/etc/postfix/sender_canonical_maps:
if /@systemname\.tld\.upenn\.edu$/i
/([^@]+)@(.*)/ sampleaccount+${1}-${2}@tld.upenn.edu
endif
/etc/postfix/header_check:
if /^From:.*@systemname\.tld\.upenn\.edu$/i
/^From:\s*([^@]+)@(.*)/ REPLACE From: sampleaccount+${1}-${2}@tld.upenn.edu
endif