Email FAQs

You can find information at this gape.

The individual steps are described on a separate page.

After termination of employment or studies, the TU Graz account will be deactivated and the associated email account will be deleted and also forwardings etc. will be removed.
For employees this happens on the day of leaving, for students generally either on December 15^th or on May 15^th, but before that you will be warned by email and informed which services are no longer usable.

Only if your name changes.

You can retrieve the emails via webmail (students/alumni) or OWA (staff) or you use any other IMAP-enabled email client that you configure with the email settings. The staff server is an Exchange server, which means you can also use Exchange-enabled clients here (Outlook can be used as both an Exchange and IMAP client, both have advantages and disadvantages).

If you try to connect via TUGRAZonline and you cannot get to your emails via the link "SBOX-Webmail" or "TU Graz - E-Mail", first try if you can log in directly to webmail or OWA. If this works, then only TUGRAZonline has a problem, the email server and the webmail client are not affected.
If you can't log in directly via webmail (or OWA), please check our newsgroup or RSS feed to see if any problems have been reported there. Otherwise, please report it to the support team, who will then clarify whether only webmail (or OWA) or the IMAP or Exchange server itself is affected.

For students and alumni, this is done in the "Filter" section of the webmail client; staff members do it via Outlook or OWA.

This is not an e-mail problem - the e-mail password corresponds (principle single credentials) to the TU Graz password.

Have you perhaps accessed with a mobile client (smartphone)?
There, the default settings are often such that the emails are

• either they are moved from the server to the cell phone anyway - they are then only available on the cell phone (until you delete them there, then they are completely lost and cannot be restored)
• or you delete them only on the cell phone, but the next time you synchronize, the client will tell the server that these emails have to be deleted.

Each user has only a certain disk space for emails and also only emails up to a certain size are accepted (values for limits).
The current space usage is visible e. g. in webmail in the line below the main navigation:

Especially the space that sent emails consume in the sent-mail (or Sent etc.) folder is always forgotten!

In addition, it is often not taken into account that the default settings of many email clients are different, which means that some folders exist several times, e. g. drafts/Drafts, trash/Trash/Deleted Messages, sent/Sent/Sent Messages, Spam/Junk/Junk-E-Mail … To prevent this, every new application that is used must first be configured correctly!

Care should also be taken to use the correct archive folder for archiving emails. i If you use a self-created folder in the INBOX, then this rather increases the space consumption in the INBOX!

When cleaning up, these must then all be subscribed to - it is better to configure all clients the same.

When deleting emails, you must also consider whether the emails are thereby

• really deleted immediately
• only moved to the trash (Trash, trash or Papierkorb - Attention: these folders can have different names in the preferences of different clients - so if you access them with different clients, there can be several of them!)
• or only marked as deleted at all.

When using webmail, the folder sent-mail may have to be subscribed first (via the menu item "Folder") and can (depending on the settings) also be renamed automatically periodically (e. g. sent-mail-MM-YYYY).

Emails marked as deleted are not really deleted until you then call "delete permanently" or "compress folder", depending on the client, or have configured this for logging out (even after this, emails can still be reconstructed by the postmasters for a certain time).

Also, it can take up to 30 minutes for the mailgates to be "informed" by the sbox that the user has made room (the corresponding job runs every full and every half hour). Accounts that have been "over quota" for a longer period of time have to be manually unlocked by the postmasters.

As mentioned before, this is due to your settings or your client - you have to delete the emails immediately, there is no room left for moving them to the trash.

But with the client "webmail" this is not possible, here you proceed as follows:

1. Log in to webmail.
2. Try to empty the trash folder (if the icon is not displayed, switch to the "Delete and move messages" section and have it displayed).
3. If that doesn't work anymore, move emails from your inbox to the archive, now you have space in the inbox again and you can delete emails and empty the trash.
4. After that you can - if desired - move emails from the archive back to the Inbox again.

If the archive is also already full, you must use another email client that can handle immediate deletion (e. g. Thunderbird).

To make sure that moving or deleting emails is done immediately (and not only when closing Thunderbird), you have to enable the auto-expunge option manually. This is easily done by editing the configuration and setting mail.imap.expunge_option to 1 and mail.imap.expunge_after_delete to True.

In principle, every good email client should have several settings for deleting emails, e. g.

• delete immediately
• mark as deleted
• move to trash

so if you delete emails immediately, that's actually your problem (there is no backup except for disaster recovery), nevertheless it can happen of course that even with a safe deletion method you delete important messages by mistake after all, so emails on server side are actually deleted only after a certain delay (90 days for Exchange server staff, 3 days for students). Students have to contact the postmasters, then emails can be reconstructed, Exchange users can do this themselves via Outlook or OWA (context menu "Recover deleted items").

These two folders are created for you by the system:

• announce is a folder into which the postmasters (and only they) can put info for all users - so you should not unsubscribe from this folder if, for example, you want to receive info from ZID about the system (shutdowns, etc.).
• archive is a folder on a separate file system, which gives you additional mailspace - you should move older e-mails from the inbox to the archive, because e-mail delivery only checks if there is enough space in the inbox, not if you have space in general.
  If you delete your subfolder in the archive folder by mistake, you can create it again via the tile "Account Status" in TUGRAZonline - but the data will be lost.

There are several possible solutions for this:

• Use a SMTP server without limit. ^*
• Split the data and send it in several emails.
• Put the data on the FTP server and send only the link.
• Use Bigmail (works similar to the ftp solution).
• Use ACOnet's file sender.
• Use a filehoster like WeTransfer (also works similar to Bigmail), Thunderbird supports it automatically ^*

* This will not work for email sender addresses of TU Graz because of SPF.

Since Webmail (and other email clients) process attachments in a special way (they are generally base64 encoded), emails with attachments are enlarged by about 35 % (digital signatures and encryption may increase the size even more). Therefore Webmail accepts emails only up to a size of 16 MB, so that the email is not then rejected by the SMTP gateway. With other email clients we cannot say exactly by how much the email will be enlarged, but you should not be surprised if emails with attachments smaller than the maximum size are not accepted (as a guideline: 15 MB) - as a web-based alternative for larger emails bigmail.TUGraz.at is offered, a further increase of the limit is no longer planned!

A known problem is that some clients do not display attachments that are sent with appointment invitations, or the attachments may be deleted when updates are made to the appointments, which means that they no longer appear even in clients that display them.
You should therefore not attach any documents to the appointment invitations, but store them in the TU Graz cloud, for example, and only send the link to the documents with the appointment invitation.

If you receive the following message as part of an email, it means that the sender has attached a file with one of the file types classified as dangerous:

A potentially dangerous attachment (batch file, script file, etc.)
was received with this email and has been discarded.
It was replaced with this message for your security.

IT support and postmasters also do not have access to the removed 
attachments, so please abstain from asking if they can be restored 
(they can not).

To savely exchange files, please consider using our cloudservice at 
https://cloud.tugraz.at.

For more information please visit:
https://tu4u.tugraz.at/go/blocked

Postmaster at TU Graz

File name: …
Matched content: …

An info like

[Attachment stripped: Original attachment type: "application/pdf", name: "….pdf"]

You can change this setting in Webmail:
⚙ → Preferences → Mail.
On this page, click on "Sent Mail" and then there are several options available under "When saving sent mail, should we save attachment data?".

There are several answers for this:

1. Most likely your address is in the Bcc, in which case you won't be able to see that because most email servers trim that away.
2. One of the original recipients (To, Cc or Bcc) has set up an automatic forwarding to your address, you won't see that either, but you may be able to tell from the header of the email that the email was sent to another server previously.
3. Someone is actively forwarding this e-mail to you - some e-mail clients know 2 types of such forwardings: with modification of the original message (e. g. in webmail by forwarding) and without modification of the original message (in webmail with redirecting), then you are not in the recipient line.
4. One of the addresses is an alias list and your address is part of this alias list.

There may be several reasons for this, including:

1. If the email should come via a mailing list, then there may be problems with SPF: If it is defined for the sender's domain what the allowed SMTP servers are, then such emails will not arrive at recipients who evaluate this.
   The solution is then to reconfigure the mailing list so that the sender is only in the reply address.
2. You may have chosen an email address on the Exchange server, but are not actively using it. However, our systems also know this address on the Exchange server that you are not actively using and show it in the address book, for example, or emails to distribution addresses in which you are listed may be delivered to this address.
   Solution:
   If you decide not to use a mailbox set up on the Exchange server after all, then set up a forwarding from this address to your preferred TU address via OWA. For data protection reasons, you should not set up forwarding to external addresses!
3. You have enabled forwarding to another address (without local copy).
   Solution:
   Check automatic forwarding/filter via webmail or OWA and deactivate if necessary.
   You should not set up forwarding to external addresses anyway for data protection reasons!
4. You have added this sender - possibly unintentionally (when using webmail with Firefox under Linux e. g. via the key combination Alt+B, Firefox and MacOS with Alt+C or generally with right-click and X) - to your exclusion list.
   In the "traditional view" in webmail, the Delete and Exclude List items are right next to each other, so many users have already copied email addresses to the Exclude List instead of deleting the email. Solution:
   Check the exclusion list in webmail, because in this case the sender will not receive any notification, because the email was accepted by the server after all!
5. You have created a filter/inbox rule that applies to this sender or email, which may move or delete these emails.
   Solution:
   Check the filters/inbox rules in webmail or OWA.
   Smartphone clients also sometimes move (already delivered) emails.
6. The email did not reach our email servers at all, but may have just been sent to our nolisting server.
   Solution:
   The sender has to ask his admin where the email was sent to. If this is mx0.tugraz.at, then the sender's server is misconfigured.
7. The email may not have been sent via an authorized server, in which case we refuse delivery. The sender (at least at the first attempt) will get a corresponding information.
   Solution:
   Send the email via an authorized server, you should ask your postmaster.
8. The reputation of the delivering server is so bad that our mail gateways refuse to accept the email. However, the sender will be notified in this case.
   Solution:
   Make your postmaster aware of the bad reputation of the server and he will take care of it.

However, you can also check yourself via a web interface whether and why emails to you have been rejected.

At Graz University of Technology, both incoming and outgoing anti-spam filters are used.
If an incoming email is classified as spam, then "[ SPAM? ]" is added to the subject, but the email is delivered anyway. If an outgoing email is classified as spam, then the email is rejected (reason: TU Graz could otherwise end up on blocklists), the sender must then change the content of the email or wrap the text and send it as an attachment, in the case of forwarding this option is often not available.

With Exchange servers it happens again and again that (e. g. after an update) the TLD of the server is changed to "local", "lan" etc., but these are test domains or domains for local applications and these may therefore not be used for production systems on the Internet according to RFC 2606!

But the delivering server will be informed about this and it should inform the sender, the administrators could then fix this in a few minutes.

Have you also checked if the email came back with an error code? You may have mistyped the email address or the recipient's server may not accept the spelling (web.de, for example, does not accept capital letters in the part before the @).

The points why an email was not delivered to us (see above) can of course also apply vice versa. You should (if the problem persists) contact the administrator of the other party's email server or send an email with the addressee's data and the time of sending to the postmasters.

At TU Graz, in order to send emails (if you do not use webmail or OWA), you have to either authenticate (and thus authorize) with your TU Graz account via SMTP or log in to the Exchange server via Outlook.

SMTP

Furthermore there are limits for the number of recipients, this limit depends on whether you are inside the TUGnet (via VPN) or outside.

Outlook

Solution:

• Write the name of the person in question in the To... line of Outlook.
• Select the automatic suggestion and delete it with [Del].
• Enter the email address again
• and send

The key combination "ctrl-L" for "@" on a German keyboard does not work, unless you disable the access keys (= shortcuts) in the webmail options

1. The search for students is only allowed for (selected) staff members due to data protection reasons.
2. For the search for staff members of TU Graz there is one database as source for all data: TUGRAZonline. Therefore the search for staff members in TUGRAZonline is the first wayi to find email addresses of the TU Graz, here staff members (authenticated) can also search for the addresses of students.
3. If TUGRAZonline is not available (e. g. during maintenance time), you can also search via the search server.
4. Within the TUGnet you can also enter the LDAP server directly in the email client.

In principle, receiving emails (IMAP or Exchange) and sending emails (SMTP) have relatively little to do with each other, i. e. if, for example, sending works, receiving does not automatically have to work as well and vice versa.

If there are problems with this, check the following list:

• Have you made the correct settings?
  Please read our key data for the email account and the Thunderbird sample configuration. At TU Graz you have to authenticate (and thus authorize) for both services (i. e. IMAP/Exchange and SMTP) with the TU Graz account.
• Has your TU Graz password changed?
  If yes: this must - if it was saved in the email client - be changed in the email settings (for the IMAP or Exchange as well as for the SMTP server)!
• Was an email you wanted to send classified as spam?
  We will tell you the reason in the error message - change the format of your email accordingly! TU Graz might otherwise end up on blocklists (also due to hacked/phished accounts) and we have to prevent that!
• You get an error message that an email has not arrived, but you have not sent this email at all?

URL filtering: Our Mailgate replaces links to suspicious pages in incoming emails in such a way that the address is still readable, but no longer directly callable - example:
The suspicious page was.auch.immer becomes BLOCKEDwas[.]auch[.]immerBLOCKED

Some email clients offer that you can recall emails that have already been sent. However, since it is completely uncertain whether this works (the message could have already been forwarded to another address or read or copied at the original address), this is useless.

We have put together a separate page for the most common error messages and their explanation.