Mail relay

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 EMS service which 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.

Expand All

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.

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.

Expand All

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 on a deny list.

Solution

Check to make sure that the IP of your sending mail server is not listed by any of the DNS deny lists 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 on a deny list.

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 the following banned characters @ ! % / | "

Solution

Use a recipient local-part without a banned character.

RPT-FAL: Recipient is unroutable

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 on a deny list.

Solution

Please contact the Service Desk 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 sharing files such as OneDrive.

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


If you cannot find the solution you need here then we have other ways to get IT support

Get IT support