Email at UiO

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

Our automated mailscanning system is intended to stop spam and malware. These are the most common error messages related to spamscanning and antivirus:

• 550 Potentially harmful attachment blocked by UiO: Heuristics.OLE2.ContainsMacros
• 550 Potentially harmful attachment blocked by UiO
• 550 Banned sender address
• 550 Banned sender domain

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 2821, Simple Mail Transfer Protocol (SMTP)
• RFC 2822, 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

550 Potentially harmful attachment blocked by UiO: Heuristics.OLE2.ContainsMacros

The message you tried to send contains an Office document with macros. Because documents with macros are used to spread ransomware (viruses that encrypt content on a computer and require a ransom to be paid before unlocking it), they are blocked from entering or leaving UiO's e-mail system. These documents can be sent internally, but not to mailing lists.

To be able to send the document, you can turn off macros. Ordinary Office documents are not blocked. If the macros are a necessary part of the document, you can either add it to a password protected zip-file or use a file sharing service, such as filesender.uio.no

550 Potentially harmful attachment blocked by UiO

Several attachment types are blocked in and out of UiO. See full list (explanations in Norwegian only).

550 Banned sender address

UiO or one of its partners has received reports of spam sent from the address, and the address was blocked.

If you think this is a mistake, contact postmaster-kontakt@usit.uio.no, and we will reconsider the ban.

550 Banned sender domain

UiO or one of its partners has received reports of spam sent from several addresses on the domain, and the entire domain was blocked.

If you think this is a mistake, contact postmaster-kontakt@usit.uio.no, and we will reconsider the ban.

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 2821, 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 2821, 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 2821, 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 2821, section 4.1.1 states:

The argument field 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 2821 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 2821 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
/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.