lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ot] SPAM/Worm problem (was: Accounts department)


From: David R. Linn
Subject: Re: [ot] SPAM/Worm problem (was: Accounts department)
Date: Sun, 29 Feb 2004 15:48:57 -0600 (CST)

HN=Han-Wen Nienhuys
NB=Nick Busigin
MK=Matthias Kilian

MK> For that worm problem: IMHO, the list owners should ASAP
MK>
MK> a) make the list closed post (only subscribed members may post to the list),
MK> b) if that worms come from a subscribed member, kick that member,
MK> c) reject every mail containing attachments other than .ly or .png.

HN> IMO only option C) is viable - and it will need a longer whitelist.

NB> Why not (a) and (c)?

MK> Hmm. If (c) works, we don't need (a), and open lists are more
MK> userfriendly.
MK> 
MK> For Han-Wen's remark: instead of whitelisting contents, one could also
MK> blacklist potentially dangerous attachements (name extensions .zip,
MK> .exe, .html, .bat, .com, .scr, .pif, all kind of MS Office documents,
MK> and corresponding content types).


Some observations on several of the ideas presented in this thread:

* I just received a Bagle.C message apparently from me (well, from my
address@hidden self) on the closed-post development list.  This happened
despite the fact that the list is closed-for-posting and I work on an
UltraSPARC machine where Microsoft software does not run.

Moral: (a) doesn't help and (b) is likely to punish the innocent.

* The filtering capabilities in Mailman v2.1.2, the MLM software that
handles the public lists at GNU.ORG, does not support whitelisting or
blacklisting by filename suffix.  The only filtering provided is based
on MIME content type.  For what it's worth, the content information
for a Bagle.C attachment looks something like

>> Content-Type: application/octet-stream; name="bdbdcdcbdbd.zip"
>> Content-Transfer-Encoding: base64
>> Content-Disposition: attachment; filename="cacbcbabbb.zip"

* The specific suggestion to block ZIP files will close the current
pathway by which some requests for help are sent.  The standard response
to a user whose message has been blocked because it is too large is to
suggest that she or he ZIP the file demonstrating the problem and send
it as an attachment.  Are we, as a group, ready to say to someone needing
help "You need to reduce your problem to one that will fit into XXX bytes"?

* At least in *my* mind, "mailing list manager" does not mean "mailing
list owner".  I just (try to) implement, within the bounds of the tech
available, what Han-wen and Jan think should happen.  Thus, when Han-wen
speaks here, an "owner" is speaking.

         David
-- 
David R. Linn - address@hidden - mailing list manager for the GNU Music project

         





reply via email to

[Prev in Thread] Current Thread [Next in Thread]