Of course, this approach fails miserably if there is the need to send a single, huge file - you're stuck to train your users better in this case.

There is a way around that too, but it requires some knowledge of the recipient's setup, and requires that the user be able to receive attachments with executable content types. (Still, many users can not receive zipfiles either, due to restrictions on attachment content types, so a fully general solution is not possible in any case.)

It works like this: you break the large file into chunks, give them sequential filenames, and send the chunks (possibly compressed, if much is to be gained by that). You also send a small custom executable that checks for the presense of all the chunks and, if they are all present, assembles them. If they're not all present, it displays a dialog that basically says, "wait, you don't have all the pieces yet, come back and run me again after you've received all the pieces". The executable can be very small in most cases, so it adds very little overhead. (If the user is on Windows, for instance, it can be a batch file and will probably not exceed a kilobyte unless there are a LOT of pieces to put together. If the user is on practically anything else, it could be a very short Perl script.)

Of course, this requires that the user trusts you enough to run your executable, and that the user's sysadmin trusts the user enough to let them receive executable email attachments. If either of these conditions fails, then you revert to training the user to assemble the pieces.

The larger problem is that all of these solutions assume the user knows how to open attachments. About a third of all users do NOT know how to open attachments. I have found that making the content available via http and putting the URI on a line by itself in the email message is frequently a better solution for this reason, and also because it's less likely to run into problems with filters, although, that still can happen sometimes, if the network admin _really_ doesn't trust the users; I know a guy who at work is behind a transparent proxy that only allows text/* and strips out Javascript, so if I had to get something to him there I'd probably encode it as Perl code, send or serve it as text/plain, and tell him how to run it from the command line -- he's on OS X, so Perl is present; if he were behind such a proxy _and_ on Windows, that would require even more cleverness to get around if need be.