To enhance security for our users, the Physics Department’s e-mail server performs various tasks on incoming messages, some of which might modify message headers or text.
Message rejecting and “grey listing”
At the time our mail server is receiving an e-mail message, it may reject the message completely for various reasons. If this is the case, the sender should receive a rejection notice stating that the message was rejected. We reject email outright for the following reasons:
We may also, in certain circumstances, use a temporary rejection method known as “grey listing.” Grey listing is a technique that uses the behaviour of a standards-compliant mail server to temporarily delay the acceptance of mail. When the sending mail server initially contacts our mail server to deliver a message, the details of the message are recorded, and we then tell the sending mail server that the message is temporarily rejected. A normal mail server will place temporarily rejected messages into a retry queue and, after an appropriate delay, attempt to resend the message to the mail exchange, which we would then accept and deliver as normal. The underlying principle here is that spammers use “mail cannons” to send as much mail as they can, as quickly as they can, and so will not implement a retry queue.
Firewalling
If an IP address or range of IP addresses is causing us major problems (denial of service), we will firewall (block) that address or range of addresses. In this case, the e-mail sender should eventually get a “Delivery Notification” stating that the e-mail can not be delivered.
Throttling and Delaying
If an IP address connects to us repeatedly at too frequent a rate, has too many simultaneous open connections to us, or causes too many errors during a connection or time interval, we will throttle it (slow down our acceptance of the connections, and/or slow down the processing of the connection) to help prevent a negative performance impact or denial of service to our servers. In most cases, the messages will still be delivered, just at a slower pace than normal. If the message delivery is delayed excessively, the sender should normally get a “Delivery Notification” stating that the e-mail can not be delivered and will be retried later.
Message Filtering
If a message is known to be fraudulent, harmful, or otherwise bogus beyond all redemption (for example, if it contains a recognized virus, or matches a known spam or phishing message), we will filter it; it will not be delivered to the user’s mailbox, although in the case of a virus, the user will be notified of the filtered message.
You can review all filtered messages, if you suspect that a legitimate message was unjustly filtered; visit the spam database to view all messages to your account that we have filtered in the last 30 days. If you spot a message that you believe to be legitimate, you can use the spam database interface to flag the message and to request that we deliver it to you.
Subject-line Tagging
We have an extensive anti-virus, anti-malware, anti-fraud, and anti-spam filtering system on our mail servers that filters out a large portion of the bogus mail sent to our systems. However, for a variety of reasons, we cannot always reliably detect all malicious mail. Therefore, numerous such messages are still delivered for one reason or another.
If a message looks suspicious to our server, but it cannot tell with certainty that it is harmful or bogus, then the message will be delivered, but with a server-added tag (or tags) at the beginning of the subject line. Thus, you might see one or more of the following prepended to a subject line:
In some cases, there might be additional information added to the message (either in the message body itself, or as an extra attachment) to alert you as to what was done, or how to retrieve quarantined content.
If you encounter a tagged message, be careful in dealing with it. If you receive a tagged message that you know for certain to be “clean” (i.e., it should not have been tagged), please forward the entire message, including all headers, to abuse@physics.utexas.edu with a subject line making it clear that you are reporting a mis-tagged message. (The webmail portal has a built-in facility for this.) We will inspect the message and work to revise the filtering rules, to hopefully prevent similar messages from being erroneously tagged in the future.
Header Massaging
Many problems, including intentional security exploits as well as accidental system outages, are the result of malformed message headers (and email clients that do not robustly handle such errors). “Massaging” is the process of making changes to the formatting or syntax of a message, either to correct problems (erroneously formed headers, etc.), to protect against malicious messages, or to work around errors in common e-mail applications.
Our servers perform a number of “massaging” operations on e-mail messages as they pass through our system:
With the exception of filename truncation, none of the above changes will be noticeable to the end user, as they simply bring the message into compliance with Internet standards or prevent malicious shell code attacks. While filename truncation will result in a visible change to the user, the step is nonetheless necessary, as an overly long name might otherwise crash an email application that was not prepared to handle such a long name.
Message Defanging
E-mail “defanging” is another way to protect e-mail users and servers from malicious e-mail messages. It attempts to “take the bite out of” malicious messages such as viruses, “Trojan horses,” shell scripts, buffer overflow exploits, etc. This is accomplished by altering the message in one or more ways:
While most messages do not need to be “defanged,” it is performed when necessary, in order to prevent the spread of malicious or infected material, as well as to mark messages that might be harboring harmful content of some sort.
In most cases, the defanging process will not cause any problems. However, some messages might unexpectedly have “DEFANGED_” text added in places (such as to neutralize potentially harmful links or scripts in a message). Also, you will not be able to verify clear-text signed messages (e.g. with PGP), because the contents of the text will have been changed.
Phishing Notices
Starting in September 2010, we added “phishing” (links to fraudulent sites masquerading as legitimate mail) detection to the mail server. While it is known to cause a fair amount of false-positive hits, it is felt that the benefit outweighs the false positives. If you have an issue with the phishing detection, you may opt-out of it by contacting us via e-mail at help@physics.utexas.edu and asking to be opted out of the phishing detection.
Phishing attacks use e-mail which looks like a genuine e-mail message from your bank, school, employer, etc. but which contains a link to click on that will take you to the attacker’s web site, where you will then be asked to type in personal information such as your account number, login information, or credit card details. A phishing site typically uses a design copied from a legitimate bank, school, etc., in order to make it appear that you are visiting an actual, legitimate institution.
These attacks can be spotted because the real address of the link in the message is not the same as the text that appears to be the link. For example, the text that you see in the email might claim that the link goes to UT’s web site, while the actual URL encoded in the message is linking instead to some other server.
Unfortunately, sometimes legitimate e-mail will also have this same type of link mismatch, which is why there is a fairly high false positive hit. However, the false positives at least make you think about the issue, make you more aware of the threat, and hence are a good security reminder.
When a suspected phishing link is found in an html message, it will be replaced by a message saying “Possible fraud attempt from … claiming to be …” (where the “…” will be replaced by the actual links from the message). We also check for known phishing attacks, in which case the text will read “Definite fraud in the website at … Do not trust this website: …” (where, again, the “…” will be replaced buy the actual links from the message).