Email Delivery at KIT

sprungmarken_marker_13005

Email servers at KIT

There are two official mail servers (SMTP) at the KIT for sending e-mails: smtp.kit.edu and smarthost.kit.edu

User with the usual end devices (desktop, laptop, mobile phone) should usually use smtp.kit.edu; our Autoconfig mechanisms also configure only smtp.kit.edu. For detailed usage instructions, see Using the KIT Mailbox.

smarthost.kit.edu is for the rest such as servers, multifunction office devices, applicances / blackboxes as well as components such as RAID controllers. These devices are often characterized by highly restricted configuration possibilities. smarthost.kit.edu  is therefore accessible from the KIT network without restriction and registration on port 25. STARTTLS is optionally supported.

Please make sure that the sender's address and (if possible) the recipient's address can receive e-mail. Otherwise undeliverable messages will be deleted after 7 days.

Note for users of external mailserver: Port 25 is blocked from the KIT network to the outside to prevent the recurring mail from the SPAM to the outside. Most operators of external SMTP servers additionally offer Message Submission (Port 587 with STARTTLS) or SMTPS (Port 465 with TLS).

If you have any questions, please do not hesitate to contact mailhost-team∂scc.kit.edu.

E-Mail Signature at KIT

All Employees of KIT should use a uniform email signature. An apropriate template is served in the KIT intranet.

You'll find the german and english templates for KIT email signatures in the KIT intranet under  https://intranet.kit.edu/signatur.php

Rate Limiting on the KIT Mail Servers

Motivation

Compromised KIT accounts are regularly misused for mass sending of SPAM or phishing emails. In these cases, the mail servers of the KIT are temporally flagged on so-called blacklists as known senders of SPAM. This may result that external mail providers using these lists will decline to accept mails from the black-listed KIT servers. Some examples in the past for such external providers have been Yahoo, Gmail and Hotmail.

Implemented Countermeasures

To alleviate this problem, rate limiting has been activated on the outgoing mail servers of the KIT. The rate limiting ensures that a sender can only send a certain amount of emails in a given time slot. If this threshold is exceeded, the outgoing mail servers will still accept the remaining emails from the sender, but they will be handled with a certain delay.

In the past the rate limit was very low. This limit had to be adjusted to react to an increasing number of necessary exceptions. Therefore the limit for each sender has been increased to 3000 mails per 5 minutes.

Furthermore the number of bounces generated by non-deliverable emails are now closely monitored. With these limits the SCC is able to detect and block SPAM waves originating from compromised KIT accounts. This prevents that the outgoing mail servers of the KIT get listed on blacklists, which increases the availability and functionality of the mail service of the KIT.

The mail servers are closely monitored to adjust the rate limits if necessary or to determine if a sender should be added to the SCC-whitelist for mass email sender. Further information is available from the mail-host team mailhost-team∂scc.kit.edu.

@sysmail.kit.edu

This allows system administrators sending of (system) emails, when he/she is logged in with his/her KIT account (ab1234).

Functionality: email to ab1234∂sysmail.kit.edu goes after KIT-AD lookup of ab1234 to firstname.lastname∂kit.edu.

 

Office files

Sending Office files (e.g. .docx, .xlsx) is permitted.

Sending Office files that potentially contain macros or macro-like content (.doc, .docm, .xls, .xlsm) or are in RTF format (.rtf) pose a significant security risk. Therefore, sending them to KIT-internal or external recipients is actively prevented. The sender receives a Non-Delivery Report with the following error message:

[EN] Office files containing macros are not allowed on this server. Please use another distribution channel or encryption.

If such files must be sent for organizational reasons and there is no alternative, such e-mails must be S/MIME encrypted or another distribution channel must be used. More information can be found in this article.