Email at UiO

Possible reasons why your e-mail was rejected by our e-mail server

At the University of Oslo, we believe in adhering to standards. We also believe in enforcing standards to improve the quality of communication for our users. We therefore require hosts connecting to us to follow the Internet standards for e-mail:

• RFC 5321, Simple Mail Transfer Protocol (SMTP)
• RFC 5322, Internet Message Format

There are of course more e-mail related standards, but these are generally of less concern to e-mail servers (MTAs).

The areas we check can roughly be divided into four:

• Invalid HELO or EHLO
• Invalid message headers
• Invalid synchronization
• Hosts blacklisted due to network abuse
• Misdirected bounce message

Invalid usage of HELO/EHLO in the SMTP dialogue

If you get an error message saying "Improper HELO/EHLO", it is due to the connecting computer not complying with the SMTP standard. More specifically, it had an invalid argument to the HELO-command. There are several ways of getting this wrong.

Missing HELO/EHLO

RFC 5321, section 4.1.1.1 states:

a client MUST issue HELO or EHLO before starting a mail transaction.

A mail transaction is started by the command MAIL FROM.

IP address without brackets

RFC 5321, section 4.1.3 states:

[an address literal] uses four small decimal integers separated by dots and enclosed by brackets [...]

This means that «HELO 65.246.255.51» is illegal, the correct syntax is «HELO [65.246.255.51]».

IP belongs to University of Oslo

The IP provided is within the IP ranges assigned to the University of Oslo. The argument to HELO/EHLO should identify the sender, not the recipient.

Bad IP address literal

RFC 5321, section 4.1.3 states:

For IPv6 [...] the form consists of a standardized "tag" that identifies the address syntax, a colon, and the address itself [...]

You get this error message whenever the address literal, i.e., whatever is within the brackets, neither can be parsed as an IPv4 nor as an IPv6 address. Examples of illegal values include «[129.340.10.9]» (340 is larger than 255) and «[2001:700:100:64::1] (missing "IPv6:" prefix).

Not fully qualified domain name

RFC 5321, section 4.1.1.1 states:

The argument clause contains the fully-qualified domain name of the SMTP client [...]

This means that «HELO mail» is illegal, the correct command is «HELO mail.example.com».

Illegal characters

The only characters SMTP allows in host names are normal letters (a-z, A-Z), numbers (0-9), period (".") and hyphen ("-"). Although a common misconfiguration, underscore ("_") is not among the allowed characters.

Invalid address format in the message headers

This error message indicates that the address specification in your message did not comply with the current standard for e-mail messages. The most common errors include illegal characters in addresses, or insufficient quoting of comments in addresses. While it is impossible to specify all the different valid addresses, the following table illustrates a few common mistakes.

Synchronization issues in the SMTP dialogue

For hosts listed in some DNSBLs (DNS Blackhole Lists), we delay sending the SMTP banner for five seconds after the connection is established. Some people, mostly spammers, use broken software and start transmitting before we send the banner. If this happens, we terminate the connection. RFC 5321 specifies a minimum timeout value of 5 minutes for the initial banner.

Also, for these hosts we delay for 80 seconds before confirming each recipient of a message. This should not be a problem for well-behaved clients, but might serve a problem for spammers. RFC 5321 specifies a minimum 5 minute timeout for this as well.

Hosts blacklisted due to network abuse

A host which take part in network abuse, or allow third parties to take advantage of it for such abuse, may find itself on one or more blacklists. When such a host tries to send e-mail to the University of Oslo, they will receive this message:

Blocked. Send questions to postmaster@uio.no or read
https://www.uio.no/tjenester/it/e-post-kalender/e-post/mer-om/problems.html#dnsbl
Found in [DNSBL name] [(additional message)] 

This message means that your host was listed in the DNSBL referred to in [DNSBL name] and we refuse to accept it. If you believe you've been misclassified and don't belong in the DNSBL, please contact the administrator for that particular DNSBL.

Additionally, <postmaster@uio.no> is interested to hear about such misclassifications; even though we can't fix the DNSBL in question, the rate of such problems helps us evaluate which DNSBLs to use.

Bounce messages sent to addresses which aren't used outbound

This rule currently only checks to see if the recipient of a bounce is the submission address of any of our mailing lists. All messages sent by the list management software to the subscribers of the list (example@uio.no) will have the owner-address (example-owner@uio.no) as the sender address on the envelope. As a consequence, all bounces will go to the administrator address rather than the list itself. Any bounces to the list address must be due to either a configuration error on the remote server, or due to spam or viruses using that list address in the envelope of the forged e-mail.

Mandatory orginator field (sender)

A mail message must contain a From-header, and if it contains multiple adresses there must also be a Sender-header. There can also be an optional Reply-To-header. Please see section 3.6 and 3.6.1 in RFC 5322.