Mail relay
The University's mail relay service is provided by oxmail.ox.ac.uk and known locally as Oxmail
The Oxmail system acts in one of two roles.
Mail Exchanger
A mail exchanger is responsible for receiving the mail destined for a mail domain. DNS MX records describe the exchangers linked to each domain. When oxmail acts as an MX it is normally receiving mail from servers outside Oxford. Oxmail's role as a mail exchanger is diminished (although not eliminated) by the introduction of OxCERT's HES service which (as of May 2019) acts as the MX for most 4-part Oxford domains (e.g. of the form foo.ox.ac.uk).
Smarthost
-
A smarthost delivers mail on behalf of other mail servers. It makes the routing decisions and handles any errors that arise. Oxmail only acts as a smarthost for Oxford mail servers.
Oxmail aims to provide a reliable mail relay service. No messages are discarded or filtered.
There are three possible outcomes for each message presented.
Accept-and-deliver
As much checking as is practical is performed prior to acceptance of a message to maximise the chance of delivery. For mail from outside Oxford, the recipient address is checked with the downstream MTA. The sender address is verified (for external senders just the domain) in order to help ensure that in the event of non-delivery after acceptance that an error message can be sent to the sender.
Accept-retry-and-bounce
-
Pre-acceptance checking tries to ensure that all accepted messages are deliverable. Any message that cannot be immediately delivered is queued and further delivery attempts are made from time to time. The retry interval starts small and increases with time. A message will be queued for 7 days before being returned to the sender.
Rejection
Rejection occurs at SMTP time. The sending MTA is responsible for informing the sender of this.
All messages are scanned by ClamAV. Any message found to contain malware is rejected after the DATA command.
This section relates to sending mail from inside Oxford to oxmail in its smarthost role. This should be done by MTAs. MUAs should use the message submission service.
Connection
ICTC Regulations require hosts to be registered in the DNS. Hosts that are not are denied service.
HELO/EHLO
Mail transactions must start with HELO.
Since all Oxford IPs must be registered in the .ox.ac.uk domain, the HELO argument must end in .ox.ac.uk. This is effective protection against compromised hosts running ratware which forges the HELO.
MAIL FROM
Although there is no restriction on the sender address, if it isn't valid then you won't know about delivery errors and may fail the recipients' sender address checks.
RCPT TO
The maximum number of recipients allowed for one message is 500. Excess recipients are temporarily rejected.
DATA
The maximum message size is 100 Mbytes.
This section relates to sending mail from outside Oxford to oxmail in its mail exchanger role.
Mail to postmaster@ox.ac.uk and abuse@ox.ac.uk bypasses most checks in order to allow queries about problems.
DNS-based blacklists
The following DNSBLs are used.
| Name | Zone | Web |
|---|---|---|
| IBM | dnsbl.cobion.com | http://www-01.ibm.com/support/docview.wss?uid=swg21436643 |
| PSBL | psbl.surriel.com | http://psbl.org/ |
| Spamcop | bl.spamcop.net | http://spamcop.net/ |
| Spamhaus ZEN | zen.dnsbl.ja.net | http://www.spamhaus.org/zen/ |
Mail coming from a server listed in one or more of these DNSBLs may be rejected and also experience small delays in response to some SMTP commands.
HELO/EHLO
Mail transactions must start with HELO.
The HELO argument must be syntactically correct. See RFC1123 section 5.2.5 and RFC5321 section 4.1.1.1 for guidance on choosing your HELO argument. A common mistake is to use the underscore character; this is not allowed.
MAIL FROM
The envelope sender domain must exist.
RCPT TO
No recipient local-part may contain any of the following characters: @ ! % / | "
The maximum number of recipients allowed for one message is 500. Excess recipients are temporarily rejected.
DATA
The maximum message size is 100 Mbytes.
Here is a list of error messages given by the University mail relay service.
When the term HELO is used it should also be taken to include EHLO.
Words beginning with $ are variables which are substituted with applicable values in each message.
DAT-CLM: Message contains malware ($malware_name)
Explanation
Message contains malware. The name Oversized.Foo means that an archive of format Foo had too high a compression ratio (currently limited to 300:1).
Solution
Remove the malware. Please contact postmaster@ox.ac.uk if you believe your message didn't contain malware.
For Oversized.Foo you can try one of the following
- Reduce the compression ratio to below 300:1
- Encrypt the archive to prevent unpacking
- Use a protocol designed for file transfer (SMTP wasn't)
HLO-FOR: Forged HELO
Explanation
The sending MTA is forging the HELO command by using another host's identity.
Solution
The sending MTA must use its own identity.
HLO-INT: Oxford host claiming non-Oxford identity
Explanation
An Oxford host is claiming an identity with the HELO command that is not in the ox.ac.uk domain. All Oxford IP addresses must be registered in ox.ac.uk .
Solution
Use a HELO argument in the ox.ac.uk domain.
If you are unable to configure your mail server correctly then you should smarthost to smtp.ox.ac.uk instead which does not impose this condition.
HLO-MIS: No HELO before mail transaction
Explanation
The mail transaction was started without first using the HELO command. See RFC5321 section 4.1.4.
Solution
Use the HELO command before starting the mail transaction.
HLO-SYN: HELO is syntactically invalid
Explanation
The HELO command does not meet basic syntax standards. Read RFC1123 section 5.2.5 and RFC5321 section 4.1.1.1 for the rules of choosing the HELO argument.
Solution
Use a valid HELO. If your mail server is called foo.example.com then issue the command HELO foo.example.com .
HLO-UND: HELO contains invalid underscore character
Explanation
The HELO argument contains an underscore. The underscore character (_) is not a member of the SMTP character set. A common mistake is for MS Windows administrators to use the host's NetBIOS name containing an underscore.
Solution
Use a HELO argument without an underscore.
HST-BAN: Sending host blacklisted
Explanation
The sending host is blacklisted.
Solution
Check to make sure that the IP of your sending mail server is not listed by any of the DNS blacklisted in section 5 above. If the IP is not listed at all, please contact postmaster@ox.ac.uk for advice making sure to include the IP address in question.
HST-PTR: Oxford host has no PTR record
Explanation
The Oxford sending host has no PTR record in the DNS. This is a contravention of ICTC Regulations.
Solution
Contact your local IT staff and get your host registered.
RLY-OPN: Open relay not permitted
Explanation
You are attempting to use our MTA as an open relay.
Solution
Use the MTA appropriate for your IP address or the recipient domain.
RPT-ALU: Recipient unknown
Explanation
The recipient is unknown at Oxford.
Solution
Check that you are using the correct address. Search for alumni email addresses on the Oxford Alumni Email website (members only).
RPT-BAN: Recipient blacklisted
Explanation
The recipient is blacklisted.
Solution
Contact us for details.
RPT-CAL: Callout verification failed
Explanation
The downstream MTA will not accept the recipient address. Any error message given by that MTA is included in our error message.
Solution
Check with the recipient as to his/her correct address.
RPT-CHR: Recipient local-part contains a banned character
Explanation
The recipient local-part contains one of of the following banned characters @ ! % / | "
Solution
Use a recipient local-part without a banned character.
RPT-FAL: Recipient is unrouteable
Explanation
The recipient email is not able to be routed by the Oxmail relays.
Solution
Verify that the email address is typed correctly.
RPT-OBS: Recipient domain is obsolete
Explanation
The recipient domain is no longer in use.
Solution
Use the suggested new address or our contact search pages
RPT-UNK: Recipient unknown
Explanation
The recipient is unknown at Oxford.
Solution
Check that you are using the correct address. Search for email addresses on our contact search pages.
SND-BAN: Sender address blacklisted
Explanation
The sender address is blacklisted.
Solution
Please contact help@it.ox.ac.uk for further details.
SND-VFY: Sender domain verification failed
Explanation
The sender domain is not correctly registered in the DNS.
Solution
Make sure that the sender domain is correctly registered in the DNS and that the authoritative DNS servers are accessible.
1. My message was rejected because it contains a "Badmacro". How can I send it?
You've tried to send a message with, say, a Microsoft Word or Excel attachment and received an error message similar to
This message contains malware (Sanesecurity.Badmacro.Doc.creobj.byt.UNOFFICIAL)
The part to look out for is Sanesecurity.Badmacro.Doc.
Although your attachment may be legitimate, it contains elements in common with dangerous malware such as Dridex which has caused serious financial loss to the University in the past. After reviewing these incidents, the Information Security team told us to stop delivering messages with this type of attachment.
In order to send you attachment, you could:
- encrypt your message/attachment so that the malware scanner can't see it.
- use a service designed for transferring files such as Oxfile.
As an analogy, imagine you are a researcher wanting to send a radioactive sample to another university. You can't use the normal postal service to transport such dangerous (albeit legal) cargo so must make alternative arrangements such as using a specialist courier.
2. Does Oxmail offer TLS-only connections?
No, but it does support opportunistic TLS. This means that it will send/receive over TLS if the other end supports it, else uses a non-encrypted connection. If you want to ensure that your mail server only sends/receives to/from Oxmail over TLS, make sure your mail server only offers TLS connections.
Bear in mind that STARTTLS uses hop-by-hop encryption so every hop gets to see your message in plaintext. If you care about the confidentiality of your message, you may wish to take IT Services Information Security's advice and encrypt the entire email content using dedicated technologies such as PGP or S/MIME.
Get support
Local IT support provide your first line of on-the-spot help
Common requests and fault reports can be logged using self-service
The central Service Desk is available 24x7 on +44 1865 6 12345
If you do not have an SSO account you can use this form to contact the Service Desk
