[AG-TECH] Wireless mobile AG clients
bknowles at mail.utexas.edu
Tue Dec 9 17:25:23 CST 2008
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,
> 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.
> 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
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
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
More information about the ag-tech