((This should be of interest to anyone who submits changes to the system by email))

The way we are presently sending attachments often can alter the included changes sets.  At least it makes good code look ugly, and can sometimes introduce bugs.  This happens because the changes sets in email messages often get line wrapped as they are being transmitted.

Paul's FilePackage refactoring offers a concrete example.  The FilePackage changes showed up on my machine with extra line breaks in the code, including within the stamp: string of most methods and within otherwise unchanged lines of code.

In this case the code will still run, though it looks odd.  In some other cases, like in an earlier MD5 change set, the line break happened in the middle of an important string and caused a failure in the executing code (though nicely caught because of a self-test in the code).

This seems to happen when a file attachment is included "inline" or when the change set is copied manually into the body of the message (as in this case).  That makes it easy to read (a good thing!) but it can be difficult/impossible to notice when the attachment has been damaged in transit.

Proposal: It may be best to send mail attachments as "base 64" MIME attachment
	Content-Type: application/octet-stream; name="xx.cs"
and then include a good description of the purpose of the attachment in the body of the message.

Mike