I am the Exchange Admin (I know, I know, but I'm sneaking Linux in there slowly...) for a large consulting company. This is a transcript of an Email discussion with one of our regional managers, who absolutely demanded that we make our main Exchange SMTP relay server allow TNEF. We barred TNEF altogether last year after our CEO complained of not being able to send to certain companies. You see, TNEF does *NOT* gracefully degrade on other SMTP servers, some servers will *LOSE* the ENTIRE message or garble it, so there is lossage involved. I, with the backing of others who went through this ordeal, successfully defended our Internet standard MIME-only, no-RTF/TNEF-outbound-to-the-Internet stance. We now have RTF/TNEF contained to within our polluted internal Exchange system only.
Note: Names have been changed to protect both guilty and innocent...
-------------------
[My Boss],
Thanks for your response. The issues as outlined by [Me] have existed with email systems from the very beginning. Also from [Me]'s initial explanation it was an issue related to Lotus Notes. Since we are a confirmed Exchange Company and many of our customers are as well it makes sense to enable this feature.
This issue arose from customer issues in the New England region rather than internal desires.
We can certainly have this region perform a work around, however it sends a very bad message when every company they deal with has RTF enabled and we are the only exchange house that doesn't.
While I understand Senior Managements position, I do not think they are compelling reasons to continue blocking this functionality.
-----Original Message-----
From: [My Boss]
To: [Me]; [PITA]; [CIO]
Sent: 8/28/00 11:55 AM
Subject: RE: RTF Files
Couldn't a RTF file be sent as a attachment within a message, rather than the e-mail itself being formatted RTF?
[PITA], please understand our hesitating to change this. This issue created a great deal of attention of senior management ([CEO] and
[misc. upper mgmt guy]) until we blocked RTF formatted messages going out. No matter how well we communicated Outlook settings to correct it, the problem reoccurred almost daily.
-----Original Message-----
From: [Me]
Sent: Monday, August 28, 2000 10:47 AM
To: [PITA]; [My Boss]; [CIO]
Subject: RE: RTF Files
I am not in a position to implement policy changes, however, I will lay out the technical issues involved and let [CIO] and [My Boss] decide the outcome:
1. RTF allows you to send E-mail with enhanced text; from Q136204 in MS Knowledge base:
Rich-text format attributes include:
Font name
Font size
Character color
Bold
Italic
Underline
Strikethrough
Bulleted lists
Exchange Forms
Meeting Requests
Voting Buttons
2. RTF is a Microsoft proprietary Internet mail packaging format. Also from Q136204:
"To view rich-text attributes, the recipient must also use Microsoft Exchange or another messaging system that displays rich-text formatting.
Messaging systems that do not support rich-text formatting will display messages as plain text without special attributes or formatting....You
may want to disable rich-text formatting in messages sent to recipients whose e-mail systems do not decode and display these attributes."
3. Only MS Outlook and Eudora understand RTF, all other mail clients will receive no enhancements. In fact, many POP3 clients will lose attachments sent via RTF. Per Q181953:
"Most POP3 clients do not understand Rich Text Format (RTF) used by Microsoft transport-neutral encapsulation format (TNEF). Consequently, the sender must turn off the option "Always send to this recipient as RTF", in order for the POP3 client to see the attachments"
4. MS Outlook is configured by *default* to send RTF.
To resolve these very interoperability issues encountered last year while sending to non-MS clients and partners (A Notes-based company specifically), [CEO] and [Local Manager] decided to turn off RTF completely at the Internet gateway. There are three settings we can choose at the Exchange server:
a) Always send RTF
b) Let the user decide
c) Never send RTF (except to specified domains)
Right now, we are using choice c). If we are going to make a policy change, I strongly discourage choosing a) due to the problems
encountered previously. This leaves choice b) which means whatever Outlook is set to the Exchange server will use. The ramifications of
making this change are:
1. Since Outlook is configured by default to send RTF, messages to clients and partners who do not use Exchange may become mangled (blank message body) and lose attachments. This will result in lost user productivity and escalations to the helpdesk on both sides until the issue is resolved. A secondary effect is that our mail system will lose perceived reliability and functionality due to these problems.
2. All [OurCo.] employees will need to be educated on what RTF is and why you need to disable RTF on messages sent to non-MS recipients. Most employees don't know or care what kind of Email system the recipient is
on, and this will create an additional burden on employees to take this into consideration. What will most likely happen is that employees will
not make the effort, messages will be mangled, and only after a helpdesk call will the issue be resolved - and only for that particular recipient. This will happen over and over again.
For these reasons, this is why choice c) above - specifying certain Internet domains to always receive RTF - seems the most reasonable
option. As long as we identify which clients and partners are based on Microsoft, we can configure all mail sent to that domain instantly, eliminating any interoperability issues and user confusion.
I think it would help in making this decision if all parties understood the exact requirements the [region] region has for sending in Rich Text Format, in order to decide whether this benefit merits making changes which may negatively affect the [OurCo.] messaging system. I am assuming that the requirement your region has for using RTF is related to sending meeting requests and other Outlook forms-based messages to certain partners or clients on the Internet. In these cases, it is well known who these partners are, and an easy addition to the list of RTF-enabled domains. If there are other requirements that I am not aware of, please let us all know.
I propose the following resolution process:
1. [PITA] will provide [Region]'s requirements for RTF format, and a reasoning why this requires RTF enabled generally instead of on a domain-by-domain basis.
2. Based on these requirements, [CIO] and [My Boss] will decide whether we need to change the policy to send RTF by default, taking into consideration the end-user impacts discussed above.
If anyone has any questions in the meantime, please feel free to let me know.
Thanks,
[Me]
-----Original Message-----
From: [PITA]
Sent: Monday, August 28, 2000 8:39 AM
To: [Me]
Cc: [CIO]
Subject: RTF Files
I passed along your information to my client in the New England Region. He brings up some interesting points, best of which is that our business requires RTF files be passed generally and not on a deny / allow basis. Can you please tell me what I need to do to get this policy changed immediately. It is causing a great amount of discomfort for my customer.
-----------------------
It is interesting to note the actual reasoning for wanting TNEF turned on --- they were getting berated by contacts at other Exchange companies (starting with Microsoft!!!) for not knowing how to turn on RTF under Exchange! This is the kind of *sick* peer pressure that happens in companies that deal with mainly MS technologies, and have not yet discovered the joys of the OS G/L software and community. So, before slamming the author of the original post (or Slashdot for posting it), please consider the effect this standard has, and how I had to defend my right to ***maintain Internet standards for mail going to the Internet***!!!
I've had great success with a company called easydns.com. You register your domain name with them, and they pass it through to Network Solutions who bills you. The great thing is they provide your DNS services for you, so you don't have to run BIND. I need this because I want to run my own servers off my cable modem connection (which is not static IP) with a real domain name. If I reboot my machine and my IP changes, I can update it at the easydns.com website and it will propogate in as little as an hour (you have full control over your SOA values, and I put my TTL as low as an hour.)
It is also a good service for people who don't want to run BIND but also don't want to call their ISP tech supp each time they want an A record added or MX record changed. Check it out - it's $25 per year per domain, on top of the $35/year netsol charges.
On top of all this, easydns runs their site using Linux / PHP! They also have a very clean, easy to use interface with NO AD BANNERS! How can you not support a company like that!
[BTW I am not affiliated at all with them, I just like to promote goodness when I find it]
Slashdot Mirror
I am the Exchange Admin (I know, I know, but I'm sneaking Linux in there slowly...) for a large consulting company. This is a transcript of an Email discussion with one of our regional managers, who absolutely demanded that we make our main Exchange SMTP relay server allow TNEF. We barred TNEF altogether last year after our CEO complained of not being able to send to certain companies. You see, TNEF does *NOT* gracefully degrade on other SMTP servers, some servers will *LOSE* the ENTIRE message or garble it, so there is lossage involved. I, with the backing of others who went through this ordeal, successfully defended our Internet standard MIME-only, no-RTF/TNEF-outbound-to-the-Internet stance. We now have RTF/TNEF contained to within our polluted internal Exchange system only.
Note: Names have been changed to protect both guilty and innocent...
-------------------
[My Boss],
Thanks for your response. The issues as outlined by [Me] have existed with email systems from the very beginning. Also from [Me]'s initial explanation it was an issue related to Lotus Notes. Since we are a confirmed Exchange Company and many of our customers are as well it makes sense to enable this feature.
This issue arose from customer issues in the New England region rather than internal desires.
We can certainly have this region perform a work around, however it sends a very bad message when every company they deal with has RTF enabled and we are the only exchange house that doesn't.
While I understand Senior Managements position, I do not think they are compelling reasons to continue blocking this functionality.
-----Original Message-----
From: [My Boss]
To: [Me]; [PITA]; [CIO]
Sent: 8/28/00 11:55 AM
Subject: RE: RTF Files
Couldn't a RTF file be sent as a attachment within a message, rather than the e-mail itself being formatted RTF?
[PITA], please understand our hesitating to change this. This issue created a great deal of attention of senior management ([CEO] and
[misc. upper mgmt guy]) until we blocked RTF formatted messages going out. No matter how well we communicated Outlook settings to correct it, the problem reoccurred almost daily.
-----Original Message-----
From: [Me]
Sent: Monday, August 28, 2000 10:47 AM
To: [PITA]; [My Boss]; [CIO]
Subject: RE: RTF Files
I am not in a position to implement policy changes, however, I will lay out the technical issues involved and let [CIO] and [My Boss] decide the outcome:
1. RTF allows you to send E-mail with enhanced text; from Q136204 in MS Knowledge base:
Rich-text format attributes include:
Font name
Font size
Character color
Bold
Italic
Underline
Strikethrough
Bulleted lists
Exchange Forms
Meeting Requests
Voting Buttons
2. RTF is a Microsoft proprietary Internet mail packaging format. Also from Q136204:
"To view rich-text attributes, the recipient must also use Microsoft Exchange or another messaging system that displays rich-text formatting.
Messaging systems that do not support rich-text formatting will display messages as plain text without special attributes or formatting....You
may want to disable rich-text formatting in messages sent to recipients whose e-mail systems do not decode and display these attributes."
3. Only MS Outlook and Eudora understand RTF, all other mail clients will receive no enhancements. In fact, many POP3 clients will lose attachments sent via RTF. Per Q181953:
"Most POP3 clients do not understand Rich Text Format (RTF) used by Microsoft transport-neutral encapsulation format (TNEF). Consequently, the sender must turn off the option "Always send to this recipient as RTF", in order for the POP3 client to see the attachments"
4. MS Outlook is configured by *default* to send RTF.
To resolve these very interoperability issues encountered last year while sending to non-MS clients and partners (A Notes-based company specifically), [CEO] and [Local Manager] decided to turn off RTF completely at the Internet gateway. There are three settings we can choose at the Exchange server:
a) Always send RTF
b) Let the user decide
c) Never send RTF (except to specified domains)
Right now, we are using choice c). If we are going to make a policy change, I strongly discourage choosing a) due to the problems
encountered previously. This leaves choice b) which means whatever Outlook is set to the Exchange server will use. The ramifications of
making this change are:
1. Since Outlook is configured by default to send RTF, messages to clients and partners who do not use Exchange may become mangled (blank message body) and lose attachments. This will result in lost user productivity and escalations to the helpdesk on both sides until the issue is resolved. A secondary effect is that our mail system will lose perceived reliability and functionality due to these problems.
2. All [OurCo.] employees will need to be educated on what RTF is and why you need to disable RTF on messages sent to non-MS recipients. Most employees don't know or care what kind of Email system the recipient is
on, and this will create an additional burden on employees to take this into consideration. What will most likely happen is that employees will
not make the effort, messages will be mangled, and only after a helpdesk call will the issue be resolved - and only for that particular recipient. This will happen over and over again.
For these reasons, this is why choice c) above - specifying certain Internet domains to always receive RTF - seems the most reasonable
option. As long as we identify which clients and partners are based on Microsoft, we can configure all mail sent to that domain instantly, eliminating any interoperability issues and user confusion.
I think it would help in making this decision if all parties understood the exact requirements the [region] region has for sending in Rich Text Format, in order to decide whether this benefit merits making changes which may negatively affect the [OurCo.] messaging system. I am assuming that the requirement your region has for using RTF is related to sending meeting requests and other Outlook forms-based messages to certain partners or clients on the Internet. In these cases, it is well known who these partners are, and an easy addition to the list of RTF-enabled domains. If there are other requirements that I am not aware of, please let us all know.
I propose the following resolution process:
1. [PITA] will provide [Region]'s requirements for RTF format, and a reasoning why this requires RTF enabled generally instead of on a domain-by-domain basis.
2. Based on these requirements, [CIO] and [My Boss] will decide whether we need to change the policy to send RTF by default, taking into consideration the end-user impacts discussed above.
If anyone has any questions in the meantime, please feel free to let me know.
Thanks,
[Me]
-----Original Message-----
From: [PITA]
Sent: Monday, August 28, 2000 8:39 AM
To: [Me]
Cc: [CIO]
Subject: RTF Files
I passed along your information to my client in the New England Region. He brings up some interesting points, best of which is that our business requires RTF files be passed generally and not on a deny / allow basis. Can you please tell me what I need to do to get this policy changed immediately. It is causing a great amount of discomfort for my customer.
-----------------------
It is interesting to note the actual reasoning for wanting TNEF turned on --- they were getting berated by contacts at other Exchange companies (starting with Microsoft!!!) for not knowing how to turn on RTF under Exchange! This is the kind of *sick* peer pressure that happens in companies that deal with mainly MS technologies, and have not yet discovered the joys of the OS G/L software and community. So, before slamming the author of the original post (or Slashdot for posting it), please consider the effect this standard has, and how I had to defend my right to ***maintain Internet standards for mail going to the Internet***!!!
I've had great success with a company called easydns.com. You register your domain name with them, and they pass it through to Network Solutions who bills you. The great thing is they provide your DNS services for you, so you don't have to run BIND. I need this because I want to run my own servers off my cable modem connection (which is not static IP) with a real domain name. If I reboot my machine and my IP changes, I can update it at the easydns.com website and it will propogate in as little as an hour (you have full control over your SOA values, and I put my TTL as low as an hour.)
It is also a good service for people who don't want to run BIND but also don't want to call their ISP tech supp each time they want an A record added or MX record changed. Check it out - it's $25 per year per domain, on top of the $35/year netsol charges.
On top of all this, easydns runs their site using Linux / PHP! They also have a very clean, easy to use interface with NO AD BANNERS! How can you not support a company like that!
[BTW I am not affiliated at all with them, I just like to promote goodness when I find it]