Summary:
 The best way to handle attachments in e-mail to
 a list of recipients is to Just Say No.
 The next best way is to build and save profiles
 of all subscribed users, based on what kind of
 mail client or Internet service they are using.

Rambling Discussion:

Attachments in general are a bad idea for a list
of recipients, where you don't know what kinds
of e-mail clients they use nor what kinds of
operating system or other tools they have
available.

If these are just "reports" that can be formatted
as plain text in the body of the message, that
will be your best answer.  Even a WebTV.com or
MyMailStation.com user can view that!

In other words, it's guaranteed that if you have an
arbitrary variety of recipient configurations, plain
text is the only format that will be accessible to
all of them.  Have you considered this, or is your
data inherently binary?

If you must have a binary file (such as Word, rich
text or graphics), the only reasonable ways to send
it are as an attachment which some users won't be
able to accept; or as a link to a web site from
which some users can download.  (There are methods
like uuencode, but folks that could use these would
have more modern software too.)

I don't see how the kludge you described would
solve anything for people who can't read attachments.
But if there is some alternative method that will
work for them, then your design might help.

Joel Dudley's one-word reply is the closest way
to the solution you described:  procmail.  It will
allow you to route selected messages into a file
or through a program for appropriate processing.
That could be hacked out in Perl very quickly, or
even shell script if you're heroic.

BUT, maybe the following is a better solution.
This would use procmail also.

Assume there are several ways to deliver content,
and each can be described simply.  Set up a
structure like this:

1. Start with a default profile for each NEW
 user.  The defaults for users on Webmail.com
 or MyMailStation.com or CompuServe or whatever
 may be based on a set of rules based on your
 experience with other users on those domains,
 and/or based on selected SMTP headers.

2. With each message you send out, include
 a note to the effect, "If you want our product
 delivered in a different format, please send
 e-mail to help@thedomain.com with "help" in
 the subject line.

3. On receiving a "help" request, send out a
 message with a menu, recommending that they
 retain this message so they don't need to send
 for it again.  This menu message will offer a
 series of delivery formats with associated
 keywords.  Tell them to send an e-mail with
 "format" in the subject line followed by a
 list of format keywords, with the most
 preferred formats first.

4. On receiving a "format" request, you can change
 profile information based on their e-mail address,
 so that they will receive future deliveries in the
 appropriate format.  They would need a feedback
 message reflecting their choices and warning if the
 choices will restrict what content they can receive.
 At delivery time, if a user's profile restricts them
 from receiving the content, they should receive a
 carefully worded explanation of which format(s)
 would allow receipt and a reminder about the "help"
 request.

Good luck,

Vic

-- 

Let me be a part of the solution:
 http://www.newearth.org/~victor/resume.html
   -- or --
 http://members.cox.net/vodhner/