[AG-TECH] Wireless mobile AG clients

[Brad Knowles]

R. P. C. Rodgers wrote:

> Ouch! I do apologize, to you adn to fellow members of the list.  I'm 
> still relatively new to thunderbird, and did not notice that the
> mega-attachments were still present.  You had a right to be cross with
> Ben, and then again with me.

I wouldn't exactly say I was cross, or at least that wasn't the impression I 
meant to leave.  I did want to stress the potential importance of the issue, 
however.

> Of course, it is a statistical certainty that people working at speed on
> a variety of platforms are going to make mistakes like this on (rare,
> one would hope) occasion.

Indeed.

>                            A better solution to this problem would be to
> configure the mail list software to prevent large attachments from being 
> forwarded to the list.  The original sender could be advised 
> (automatically) to deposit the large file(s) on a HTTP or FTP server, and
> employ the appropriate URL within their message.

AG is using the latest version of Mailman (2.1.11), and Mailman is one of 
the most common and full-featured open-source mailing list management 
systems available.  I've been involved in supporting the Mailman project, 
and acting as the primary active postmaster for python.org for a number of 
years.

Unfortunately, while Mailman does give you easy options to use for 
configuring a maximum message size you will allow for messages that are 
posted, as well as lots of options for stripping attachments, converting 
HTML to plain text, etc..., it doesn't have any options for automatically 
depositing files on other HTTP or FTP servers and including the URL in the 
message.  You'd need to use another program (like FileChute) to do that for you.


With Mailman 2.1.11, we did add the option to "scrub" non-digest messages, 
so that any attachments will be removed from the messages as they are 
submitted, and replaced with URLs to where those attachments can be found on 
the Mailman list server.  However, this option means that the list owners 
now have to provide large amounts of disk space for those attachments, which 
may be an issue for those sites that run mailing list servers that are not 
directly accessible to the Internet.

Moreover, if you're going to store those attachments centrally, are you 
going to trust the MIME type and extension that were on the original 
attachment (and therefore make it trivially easy for people to pass around 
viruses that pose as .SCR screensaver programs), or are you going to store 
them in a safer binary format that the user will have to post-process with 
the correct file type, once they've downloaded it?  There's a legal 
liability issue here to be concerned about, which you don't have to deal 
with if you only strip attachments as opposed to scrubbing them and then 
storing them centrally.

> As an email user since ~1980, I can assure you that no number of cross 
> messages to senders will fix this problem.

You've got me beat by a few years.  I've only been using e-mail since ~1984, 
but I have been a professional Unix system administrator since 1989, and 
I've been specializing in e-mail systems administration since ~1992, 
including two years as the Sr. Internet Mail Administrator for AOL.


The issue of individuals sending large messages/attachments to mailing lists 
is one that I am sensitive to, since I've seen the e-mail system for an 
entire ISP get shut down by a single moron in the sales department of that 
ISP who decides he has to send out a ~50MB PowerPoint attachment to all the 
300+ employees in the company, and that instantaneous load of 15GB of 
traffic is larger than the sum total of spool space on the mail server, thus 
resulting in crashing the server used to support all million+ customers in 
the country.

It took me several hours to fix that system.  And the next day, we had a 
proper mailing list to handle the "all@" e-mail address that they had been 
using, and that mailing list had very strict limits in terms of maximum 
message size that would be accepted.

But that didn't help the million+ customers who had been shut out of getting 
into their e-mail for several hours the day before.

-- 
Brad Knowles <bknowles at mail.utexas.edu>
The University of Texas at Austin, Information Technology Services, ITS-Unix