The issue here really isn't about whether what Sam's doing is right or wrong. I think we all agree that writing a MTA to RFC spec is the right thing to do. Unfortunately, the Internet has always been rule by majority, and in the case of those of us who work at companies, schools, etc where we're not the boss, the flexibility to turn off this type of check to gain "compatibility" may be necessary.

Many of us have bosses or customers that have received many email messages from the likes of Sears.Com, Kmart.Com, etc. that has long worked on sendmail. In trying to find a sendmail replacement, we find this great MTA in courier. It has all the features we wanted and then some. However, upon a successful switch, we find that all these users are receiving mails from well known "brands" that are malformatted. I've even had a user that contacted Sears.Com and was told that the developer for the email server is WRONG. Do we really expect everyone to understand RFCs and 7-bit vs 8-bit MIME headers?

If I may make a suggestion... Right now, an email message is consider "corrupted" because it uses 8-bit encoding for MIME headers instead of 7-bit. However, for the most part, Courier can probably handle this message. So instead of putting the whole message in an attachment, can't we do the following:

1. Email comes in with malformatted headers 2. Take all the MIME body parts in the original message, create a new message including the orginal MIME body part. Append/prepend the message with our error message. 3. Attach the original message, untouched. 4. Attach the rfcerrheader in a different attachment 5. Deliver the message

Albeit, this doubles the disk space use for each malformatted message. However, users who doesn't really care about the RFC stuff can just read their message. We still deliver RFC compliant messages, and the error message is still there.

Comments?

-Tony