I've been supporting and administering email for 18 years, and never had a valid reason to block text attachments. Here are some issues that I can think of, that aren't exclusive to TXT attachments alone, but rather regard attachments in general
The only two issues I've come across is this unicode bug but it's theoretically possible that other applications that have issues parsing and/or displaying unicode.
MIME-type vs file extension
Attachments in SMTP include not only a file extension
.txt but also a MIME-Type and a corresponding encoding (as mentioned above). Should any of these "metadata" not match up (vbscript with a mime of Text, or vice versa) it's possible to get unexpected results from a client.
Issues may include
- File attachment icons appearing like a TXT file in the client, but are really an EXE
- Clients (or services) improperly handling the attachment, potentially executing it
- A variation of the above that causes the client (outlook / thunderbird, etc) to download an image, or verify a DKIM signature, losing the anonymity of the client.
Since the most common client in an Exchange 2013 environment is Outlook, I'll focus on that, even though most of the issues here have been thoroughly looked at and is no longer an issue (as long as you're on a current and patched build).
Outlook Preview Pane Risk
The Outlook preview pane uses a special, locked down version of IE. Given that IE could execute "text" data as if it were HTML/XSS or any other active content, this could pose as a security risk. (Outlook vulnerabilities as the preview pane has happened in the past)
WebReady Exchange Server Risk
A similar attachment to HTML parser is installed on the Exchange server itself called WebReady, and it converts attachments into HTML for Outlook Web Access clients. This has already been an issue in the past, causing vulnerabilities and executable code to run in the context of the Exchange Server itself. Read more about this security feature here.
In my opinion, before your admin blocks TXT attachments they should consider disabling Webready and address the lower hanging fruit first:
- Improved authentication for end users (smartcard etc)
- AV/AS on the server, and gateway
- SMTP security including DMARC, DKIM, SPF, and Opportunistic / Secure TLS where possible
- Content scanning
- On demand portal encryption, SMIME or PGP encryption
If they are disabling attachments as a form of information management, to prevent the disclosure (or liability of receiving ) data, then they should consider alternate controls.
If they are disabling TXT attachments for security / encryption reasons and want all data encrypted, know that some encryption software sends the encrypted payload or public to the clients using TXT data. Conversely, banning this activity is easy since there is a string in the file that can be scanned for.
Just for clarification, by "blocking" do you mean classifying it as a Level 1 or Level 2 attachment in Outlook?