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