|
Tech Tip (LISTSERV) – Issue 1 – 2008
Q: Why is it better to send links to large attachments through LISTSERV rather than the attachments themselves?
Answer by John Harlan
Vice President, Computer Services, L-Soft
One of the many extremely convenient features of LISTSERV has long been its ability to include attachments in electronic mailings. It is undeniably very handy to be able to send a file – a word processing document, a spreadsheet, a photograph, a sound file, or a PDF file – along with an email message to a group of recipients.
It certainly adds impact to an email message to your circle of family and friends ("I've just seen space aliens!") when you are able to attach your own digital photo of the smiling, waving space people and a sound file of your interview with them. Nothing makes something real like solid documentation.
Back at the office, it can also be extremely convenient to send a draft report and perhaps a supporting spreadsheet to your colleagues, in advance of a meeting.
Both examples represent reasonable uses of LISTSERV's attachment capability because both assume a relatively small recipient audience (in the latter example, usually all within a single organization's email system, and each with a probable need for possession of their own copy of your documents), and the sending of reasonably small documents not likely to exceed local mail system thresholds for message or attachment size, or user mailbox storage quotas.
Many email senders, however, choose to send general documents of all sizes – smaller ones such as flyers and brochures, as well as larger ones, such as newsletters – as attachments, usually as a PDF file. Often the information being sent as a PDF is already accessible on the sender's website, or could easily be placed there.
Is it possible to send your latest full-color brochure or newsletter as a PDF attachment to all of your recipients worldwide? "Yes," you're thinking, "I've been doing that forever." And you are correct: It is possible to send it. "Have most of your recipients actually been receiving it successfully (in a timely manner, without exceeding their mailbox storage quota, etc.)?" is the more relevant question. There is also the consideration of whether the attempted delivery has caused collateral damage along the way.
Having the capability to send large attachments to large numbers of recipients does not obligate anyone to use that capability – especially when there are so many good reasons not to do so.
First and foremost is recipient preference: Your recipients do not necessarily want to receive an actual attachment if they can access the document online via a link in your email message. Anecdotal evidence suggests many recipients actually prefer a link they can easily bookmark for convenient future reference. If they decide that they want their own copy of the document, the bookmarked link gives them that option; they can download at will.
Attachments can prove problematic for recipients for a variety of reasons:
- They may not be accepted for delivery at all by some email systems (as a matter of site security configuration), or their delivery acceptance may be conditional based on file size or type.
- They may run afoul of inbound Simple Mail Transfer Protocol (SMTP) servers, or mail filtering and virus scanning applications in the receiving email system's infrastructure.
- Their delivery, if accepted, may be delayed due to the above.
- Even if accepted for delivery by the recipient's mail system, they may themselves exceed the individual recipient's email storage quota, or contribute substantially to exceeding the quota, thus complicating life for the recipient.
These are a few of the possible issues for the recipient. Senders may encounter their own set of problems by including large attachments, such as triggering blocklisting by the intended recipient systems or by independent anti-spam monitoring services.
Aside from the immediate, logistical challenges presented by sending large attachments to large numbers of recipients, in this time of heightened awareness of resource conservation and efficiency, it should be noted that sending attachments uses more bandwidth – at both ends (sender and recipient) as well as everywhere in between – than sending links.
Another reason to send links rather than attachments involves electronic mailing management and assessment solutions, such as L-Soft's LISTSERV Maestro. LISTSERV Maestro makes it possible to track how many recipients follow the links included in an email message. Not only is the risk of possible delivery problems and recipient displeasure caused by sending big attachments eliminated, the link being sent instead can provide quantifiable result data: How many recipients accessed the document, how often, and (if desired), who they were.
How can control be exercised over attachments processed through a LISTSERV server?
At the server level, L-Soft gives LISTSERV administrators a site configuration keyword, FILEMAXL=, which determines the "maximum acceptable size, in lines, of an incoming non-mail file" accepted by LISTSERV. "Non-mail" files include other non-message traffic such as LISTSERV command communications, with the result that such files need to be allowed; this value should never be set to 0. Beyond a minimal size permitting such traffic, however, this setting becomes the control point for attachment size. (To locate this keyword from the LISTSERV 15.5 web interface, select "Server Administration" from the toolbar, select "Site Administration" from the pull down menu, select "Site Administration" a second time, select the "Optimization" tab, and scroll down to "FILEMAXL.")
The default value of FILEMAXL is 500000 lines. For calculation purposes, L-Soft Computer Services uses this in-house rule of thumb: 1 MB = approximately 16,000 lines, averaging 65 bytes per line, or 13,000 lines, averaging 80 bytes per line. LISTSERV's default setting works out somewhere between 31.3 MB (at 65 bytes per line) and 38.5 MB (at 80 bytes per line).
The LISTSERV default setting is generous – possibly to a fault – and for our in-house hosting services, L-Soft has recently begun experimenting with lowering the FILEMAXL setting to 150000 (9.4 MB at 65 bytes per line, to 11.5 MB at 80 bytes per line) on selected ListPlex nodes where extremely large attachments have been especially problematic.
L-Soft's object in adjusting this setting for our hosting customers is not to prevent their use of attachments, but to allow attachments in a way that is still useful, but protects both sender and recipient from the problems described above, and is more Internet-friendly of L-Soft as a major opt-in / double opt-in hosting service provider.
At the list level, L-Soft gives list owners the ATTACHMENTS= and SIZELIM= list configuration keywords, specifying (respectively) whether (and if so, what type of) attachments are allowed to be sent through the list, and the size limitation for messages (including their attachments) sent through the list. Like FILEMAXL, the SIZELIM= value can be specified in number of lines (see rule of thumb calculation guidelines above); SIZELIM= can also be specified in kilobytes (K) or megabytes (M).
From the LISTSERV 15.5 web interface, select "List Management" from the toolbar, select "List Configuration" from the pull down menu, select "List Configuration Wizard," and select the "Access Control" tab for the ATTACHMENTS= keyword or the "List Maintenance" tab for the SIZELIM= keyword.
As always, L-Soft's world-class support, training and consulting staff are available to assist you with the particulars of LISTSERV configuration for attachment use. Please contact your L-Soft sales representative at sales@lsoft.com, or L-Soft customer support at support@lsoft.com for details.
| 