Proposed Change to ITU-SG16 Mail List Procedures
Dear ITU-SG16 Experts: I have noticed a dramatic increase in SPAM on the ITU-SG16 mail list. As administrator of the list, I would like to hear about a proposed change that will decrease the amount of SPAM and other mail messages including potentially harmful email (viruses, etc.). I can set LISTSERV to require the sender of a message to acknowledge the message before LISTSERV will send it. So to send a message, you would send it in the usual way but before it gets sent to the mail list, LISTSERV will send you a message. If you respond to the message, you authorize LISTSERV to send the message. Since most SPAM is spoofed, the "sender" will not acknowledge LISTSERV and the message will not get sent. I would appreciate hearing if there are any concerns with this method before I implement it. I will follow-up this email later to announce what action I have taken to this ITU-SG16 list. Thank you, Greg Meyer Intel Corporation email: greg.w.meyer@intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Dear Greg, Many thanks for your taking care of this valuable mailing list. At 18:16 -0700 01/09/25, Meyer, Greg W wrote:
[...] I can set LISTSERV to require the sender of a message to acknowledge the message before LISTSERV will send it. So to send a message, you would send it in the usual way but before it gets sent to the mail list, LISTSERV will send you a message. If you respond to the message, you authorize LISTSERV to send the message. Since most SPAM is spoofed, the "sender" will not acknowledge LISTSERV and the message will not get sent.
I would appreciate hearing if there are any concerns with this method before I implement it.
I agree to this measure. One human factor related question is how quick the LISTSERV query would be. Presumably very prompt. There may ba cases where a message is posted, but the the query is forgot if it comes sometime later. In any case, I understand the posting is becoming a two stage process. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo@giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Dear colleagues, I sympathise with Greg, and agree that measures should be taken to control SPAM. We have heard of three options, a) block sending messages at the server level (rob.c, sorry, don't know your real name) b) require subscription to the list for acceptance of message posting (M.Euchner) c) two-step submission process (G.Meyer) I would request that a) not be implemented. I have been in a situation before that I did not have access to a "clean" SMTP server and used one of the servers that spammers also use ... actually, the legitimate use of the open-door policy prevalent in the beginning of the Internet. This scenario happens quite frequently, so it is an option which I would favor to leave open. On a more general respect, control of spam will be good only as long as the ban list is maintained -- we will still get spam messages in the wake of new spam smtp servers before they are added to the ban lists. Option b) was the "obvious" solution that first came to my mind (I manage a few lists in this fashion), but has the drawback that Mr.Okubo mentioned (that many colleagues from Japan would have to resubscribe), and also that if you post a message from a machine with a declared email address that is different from the one you are subscribed to, the posting will be rejected even though you are subscribed with a different email address (there are ways around it, but it is always a hassle). Of course, the other disadvantage is that someone will have to perform as a list subscription moderator (which could be anyone, not necessarily someone from Intel, I presume). Option c) has the disadvantage of being a two-step process, but it sounds quite ingenious. As mentioned by Mr.Okubo, provided that the response time between the "proposed posting" and receipt of the confirmation message is short (say within a few minutes under normal operating conditions), then I think it is a good compromise solution. Even more so if the confirmation process involves only hitting the reply button. Finally, option c) is way more user-friendly than working around posting from different email addresses in b), or not being able to post messages at all in a). So, I support that we give Greg's proposal a try. Best regards, Simão
----- Original Message ----- From: "Simao Campos-Neto" <simao.campos@LABS.COMSAT.COM> To: <ITU-SG16@mailbag.cps.INTEL.COM> Sent: Wednesday, September 26, 2001 1:42 PM Subject: Re: Proposed Change to ITU-SG16 Mail List Procedures
Dear colleagues,
I sympathise with Greg, and agree that measures should be taken to control SPAM.
We have heard of three options, a) block sending messages at the server level (rob.c, sorry, don't know your real name) <SNIP> I would request that a) not be implemented. I have been in a situation before that I did not have access to a "clean" SMTP server and used one of the servers that spammers also use ...
This would be the most effective option
actually, the legitimate use of the open-door policy prevalent in the beginning of the Internet. This scenario happens quite frequently, so it is an option which I would favor to leave open.
Well its now really not best current practice, but the wider debate is not relevant, you don't have to use RSS (that aims at open relays), just use RBL which is a list of confirmed spam sources.
On a more general respect, control of spam will be good only as long as the ban list is maintained
RBL is very well maintained and updated by the minute.
-- we will still get spam messages in the wake of new spam smtp servers before they are added to the ban lists.
No option (save for human moderation) will get all "spam messages" however the above one will get alot. In my experience it gets about 50% of what i consider to be spam.
Best regards, Simão
regards, rob.c ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
I vote that we keep things the way they are. Like everyone else, I get spam through various means all the time, and I hadn't noticed getting any more via this reflector. IOW, patching up this one hole will not substantially decrease my overall email vulnerability, and the solutions sound a lot worse than the problem. If the concensus is to do _something_, I'd vote for the subscribers-only filter. The mailing-list software we use at Packetizer allows one to subscribe multiple From addresses but have mail sent to only one address. For example, I can subscribe plong@ipdialog.com and plong@packetizer.com so that I can send from either email account but only have mail sent to plong@packetizer.com. Paul Long ipDialog, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (5)
-
Meyer, Greg W -
OKUBO Sakae -
Paul Long -
rob.c -
Simao Campos-Neto