Re: Guidance for spam-control on IETF mailing lists
I tend to agree with Mr. Touch, "Spam is definned by content". However, the content complying with "SPAM" comes from a small list of people. People, who are, in general, not signed up for the IETF mailings. By placing a guard on the incoming lists, restricting incoming mail to those individuals/organizations/corporations/etc. that recieve messages sent to the IETF lists, Then, by moderating the lists to these users who comply with the morals of the IETF, we can eliminate spam to a near virtual zero. This is one simple, but effective method of controlling spam. My opinion: this, and a combination of filters, would eliminate SPAM. Cheers, Don McMorris, Chief Network Operator, Ospitare Intl. --- James M Galvin <[EMAIL PROTECTED]> wrote: > > On Sat, 16 Mar 2002, Joe Touch wrote: > > The main issue here is about the rule for the > filter. We all want less > spam. The difference is: > > - to me, spam is defined by content > > - to you, spam is defined by user > and assumes a correlation between user and > content > > I almost agree with your distinction but I want to > make one clarification. > > To me, it's not that spam is defined by user, it's > that non-spam is > defined by user. > > What this means from an implementation point of view > is that non-spam is > almost trivial to configure and then more or less > runs itself, or at > least distributes the management to the subscribers. > Thus the > cost-benefit ratio for this particular spam control > mechanism is > negligible from the point of view of the *volunteer* > list host. > > We have to remember that the bulk of IETF mailing > lists are hosted and > managed by volunteers. All mechanisms other than > correlation by user > have a labor intensive component. Such mechanisms > are not excluded but > they are impractical for volunteers. > > While I agree that "user ease" is of paramount > concern, I do not believe > it is a priority concern considering how the IETF as > an organization > "manages" its mailing lists. Now, if you want to > talk about > centralizing the management of the IETF lists, then > the priority concern > issues can be different. > > Jim > __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/
Re: Guidance for spam-control on IETF mailing lists
> From: "John Stracke" <[EMAIL PROTECTED]> > ... > >In fact if you look at the various forms > >of legislation around the world > > Law has nothing to do with right and wrong. If I can't look at a piece of > spam and determine whether or not it infringes the law, then there is > something wrong with the law. That may be true in general, but it might be interesting to look at how existing laws might apply to examples of spam. I'm certainly not a lawyer, but I suspect that the unsolicited bulk commercial advertising email or "spam" that Mr. Kenres's organization sent me (and perhaps other contributors to this mailing list) in October, 2001, violates the California and Colorado laws. Of course, even if I'm right about that, the Hong Kong location of his organization and the passage of time makes the issue moot in any practical sense. To see if you received Mr. Kenres's spam, check the first two entries at http://groups.google.com/groups?q=%22ima.%2Bcom%22+group%3Anews.admin.net-abuse.sightings Notice for one thing that it lacks the required (and yes, stupid) "ADV:" Subject line tag. There are links to many laws at http://www.spamlaws.com/ Vernon Schryver[EMAIL PROTECTED]
Re: Guidance for spam-control on IETF mailing lists
> From: Bruce Campbell <[EMAIL PROTECTED]> > To: Vernon Schryver <[EMAIL PROTECTED]> > cc: [EMAIL PROTECTED] > > Why are your, Eric Brunner-Williams's, Robert Elz's, and my messages > > present in the archive for the IETF list at > > http://www.ietf.org/mail-archive/ietf/index.html > > while Mr. Kehres's are absent? > > A large mailing list (such as [EMAIL PROTECTED]) is not a FIFO. Delivery of > one message may get blocked while a later message gets delivered (and in > this instance to the web archive) first. Anyone who has been around for more than a few months is quite familiar with such hassles. > In this instance, given the extremely short time span between the messages > (please note carefully the GMT offset of the messages in question), it > should not be perceived as a problem. If you were referring to > non-arrival of messages after a significant amount of time (a day or more, > again carefully noting the GMT offsets), then that is a problem. Those whose addresses are like mine and are near the end of the alphabet are accustomed to receiving copies of messages from IETF and other reflectors after things have settled for everyone else. I did not intend to ask about the order of messages. If you check headers of the messages I asked about, you'll see that most of a day did in fact elapse between the time you might infer that that I and my filters received the copies (plural) of the messages (also plural) and my question. You can see that my responses to Mr. Kehres's messages are in early part of the "Mar 17 2002" list while his are in the "Mar 18 2002" list. You can also see that my question and Harald's answer appeared in the archive before Mr. Kehres's messages. I guess I was confused by the multiple copies I saw of Mr. Kehres's messages. I would have sworn that one copy of each of his message came via the reflector for this list. Evidently I was wrong, and the copies of his messages in this list were delayed for moderation. I could not justify writing this response to the IETF list except: 1. Bruce Campbell's confusion as well as my own about what happened in this case shows that the moderation is not entirely transparent. I don't think that's objectionable, but others might. 2. to acknowledge the apparent accuracy of Harald Tveit Alvestrand's response, "I suspect that the moderator is taking the weekend off." 3. to offer this as an example of what some people see as terrible side effects to such moderation or filtering. I think it's ok as long as I know about it and so don't get confused by it. 4. if I were in charge, I'd be using the DCC and arranging the count filtering to reject all messages with target counts >1. This would have a side effect of ending much cross-posting as well as many "courtesy copies." I think that would be good, but those who enjoy many copies of messages (e.g. CFPs) might disagree. 5. I try hard to trim individual addresses from my responses precisely to avoid such confusion. That does slow down discussions, but I think the otherwise common confusion is worse than the slowness. Vernon Schryver[EMAIL PROTECTED]
Re: Guidance for spam-control on IETF mailing lists
On Mon, 18 Mar 2002, Vernon Schryver wrote: > Why are your, Eric Brunner-Williams's, Robert Elz's, and my messages > present in the archive for the IETF list at > http://www.ietf.org/mail-archive/ietf/index.html > while Mr. Kehres's are absent? A large mailing list (such as [EMAIL PROTECTED]) is not a FIFO. Delivery of one message may get blocked while a later message gets delivered (and in this instance to the web archive) first. In this instance, given the extremely short time span between the messages (please note carefully the GMT offset of the messages in question), it should not be perceived as a problem. If you were referring to non-arrival of messages after a significant amount of time (a day or more, again carefully noting the GMT offsets), then that is a problem. Regards, -- Bruce CampbellRIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations
Re: Guidance for spam-control on IETF mailing lists
>The behavour that bulk emailers exhibit is substiantly different from >happened in this case. The key point, though, is that there is no way for the recipients to tell the difference. From my point of view, when I get customized spam (the sort with my name & address on it, rather than BCC:ing everybody), all I know is that it was sent by someone running a simple fill-in-the-blanks program. I do not know, or care, whether that program was run in software or wetware; and I do not know, or care, whether that message went to 10 people or 10 million. Either way, the harm to me is the same. >In fact if you look at the various forms >of legislation around the world Law has nothing to do with right and wrong. If I can't look at a piece of spam and determine whether or not it infringes the law, then there is something wrong with the law. /===\ |John Stracke|Principal Engineer| |[EMAIL PROTECTED] |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===| |"What we have here is a failure to assimilate." --Cool Hand| |Locutius | \===/
Re: Guidance for spam-control on IETF mailing lists
I have forwarded the question to the secretariat. I suspect that the moderator is taking the weekend off. Harald --On 18. mars 2002 07:50 -0700 Vernon Schryver <[EMAIL PROTECTED]> wrote: > Why are your, Eric Brunner-Williams's, Robert Elz's, and my messages > present in the archive for the IETF list at > http://www.ietf.org/mail-archive/ietf/index.html > while Mr. Kehres's are absent? >
Re: Guidance for spam-control on IETF mailing lists
On Sun, 17 Mar 2002 12:04:37 +1100, grenville armitage said: > Since cross-posters always (!) read each mailing list's charter before sending, > it is intriguing to consider that said posters probably also stumbled across > the list's subscription method. This would presumably move the act of > subscription from the realm of "obscure knowledge" and into the realm > of "duh". Unless of course, it's a cross-poster like me, that has an annoying tendency to hit the 'Reply All' button, not realizing that some of the addresses in the CC: list are mailing lists I'm not on (Hi, Poised subscribers! ;) Let's look at this message as an example: If I hit "reply", it goes only to Grenville. If I hit "reply all", it goes to Grenville, ietf, and poised - and I get to do some hand-trimming if I remember to do so before hitting 'send'. Yes, I *know* about all those "followups-to:" headers, but (a) they're not an actual standards-track last I looked, and (b) there wasn't one in the message I'm replying to anyhow. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg07842/pgp0.pgp Description: PGP signature
Re: Guidance for spam-control on IETF mailing lists
> > > > The behavour that bulk emailers exhibit is substiantly different from > > happened in this case. I've outlined in detail what our people had done - > > if you look at the bulk mailers and their practices it is not difficult to > > determine many key differences. In fact if you look at the various forms > > of legislation around the world, including in the US at the moment, they > > take into consideration issues pertaining to the authenticity of the > > messages (forged headers), theft of service (unauthorized use of third party > > systems) and similar issues. Going by memory, some also take into > > consideration the harassment factor, or how many times a single message is > > bombarded against an unsuspecting individual, however sadly, from what I can > > read, the current proposed US federal legislation into this does not go this > > far. Amen to that - the US legislation makes SPAM the problem of the end-user or recipient and that is just plain wrong. The legislation needs to be amended or turned upside down so that the last person responsible for the spam is the person it is sent to. Not the first. >> In short the legislation is trying to go after the bulk mailers > > without killing the Internet as a medium for electronic commerce. I have a different view - The legislation currently in force gives them (Bulk Mailers) a method of existing at least once for each identity they coin and they can send out a major spamming and then just dry up and blow away - I can see it now. Spam from Domain 102115.com today and tomorrow from domain 102116.com and so on. Ad infinitum. There is no end - each one with a new life period of from a day to a week or so. That being what it takes to get them caught. The only thing at the Domain Level that will stop these types of domain based SPAM is to get into it at the InterNIC level and to: 1)Link the inter-registrar "domain systems" together tighter such that rule sets can be propagated within a single 24 hours. Say once an hour, which potentially limits any Spammers exisitence to potentially as little as a single hour or so. 2)Create a set of mechanisms wherein the DNS services of a SPAMMING operator can be suspended as part of this regular rolling of services and take to the level such that any such domain is to be shutdown immediately pending receipt of good contact data from their owners. 3)Create a process whereby all domains registered to any set of Domain Managers can be identified. This will help when domains that have to real way to contact their owners are found and you need to find any others they have registered. These steps will make Spam much more livable - > > This is my understanding as well. Perhaps than Vernon is suggesting > that such legislation does not go far enough, and is advocating a form > of censorship? > Under the current legislation the real issue is that the email facilities are essentially provided "as is" by the Email service providers. Most ISP's don't want to or are not capable of being responsible for making sure that the email that their systems deliver or propagate onward is of a non-intrusive nature or not. The problem is that we as the subscribers to this wind up footing the bill for it, both in actual data services and in time. If we make SPAM the ISP's problem and create a formal set of email routing/response rules, I assure the problem will get addressed. There are effective ways to do active filtration and for the US perhaps the thing to do is to nationalize the boarders and declare what can and cant cross them protocol and content wise. The Homeland Security Office could likely do this unilaterally. This would give law enforcement a method of reacting that is stronger than what they have now and will force the ISP's to evolve smarter and more efficient email systems. Todd Glassey
Re: Guidance for spam-control on IETF mailing lists
the weakness of using mailman's "suspend delivery" for submit-only addresses is that the guy will get a monthly reminder of his password. I find that if I as administrator use this feature for allowing people to post, they tend to unsubscribe themselves at the start of the month, rather defeating the system. So far, I've stuck with using the permitted-posters field, and haven't encountered the length limit yet. Harald --On 16. mars 2002 14:16 -0500 "Patrick R. McManus" <[EMAIL PROTECTED]> wrote: > I subscribe to a couple of different lists that (ab)use mailman's > "temporarily disable delivery" attribute for this purpose. > > Someone with N addresses they'd like to post from simply subscribes to > the list from all of them and sets the disable delivery flag on N-1 of > them. Mailman seems to define temporary as "until I unset this attribute". > > No admin intervention required.
Re: Guidance for spam-control on IETF mailing lists
Tim and all, Tim Kehres wrote: > From: "Vernon Schryver" <[EMAIL PROTECTED]> > > > > With respect to the second above issue - I am very aware of what > happend - > > > some of our people sent single directed messages (unsolicited) to > parties > > > they thought might be interested in what we do. They were single, short > > > messages, sent from real people on a one on one basis. They were sent > with > > > valid headers, through our servers, and only one short message was ever > sent > > > to anyone. We don't deal with unsolicited bulk advertising. > > > > > > I just have not had the time or energies as of late to set the records > > > straight. > > > > The "straight record" of the messages archived by Google is that they were > > unsolicited, more than one and substantially identical, and therefore > > "spam" or "UBE" by the definition held my most informed people. > > They were indeed mostly identical, as is common when trying to make initial > contact with new groups of people. They were however never sent more than > once to a specific individual, regardless of wether or not the recipient > replied. You make a key point that it seems Vernon neglected to mention in his response above. > > > > In addition, because promoted or advocated a commercial product, they > > were "UCE" or spam by the second most common definition. > > Are you suggesting that if the content were different, say promoting a > personal sex site, that they would have been acceptable? Somehow I suspect > that this is an ineffective metric by which to measure content. I would also have to wonder by Vernon's stated second most common definition, whatever that really means, would apply to IETF, ISOC, Church affiliations, ICANN or other non-commercial and charitable orgs send out that I receive from time to time are also UCE? I think not. > > > > The motives claimed by the senders are irrelevant. Whether the > > unsolicited bulk mail is sent one at a time or with a single SMTP > > transaction is irrelevant. Whether the headers are valid or you steal > > service from third parties instead of only your spam targets is also > > irrelevant. I and most informed people think that the contents of > > the messages are irrelevant except to determine whether they are > > substantially identical. > > The behavour that bulk emailers exhibit is substiantly different from > happened in this case. I've outlined in detail what our people had done - > if you look at the bulk mailers and their practices it is not difficult to > determine many key differences. In fact if you look at the various forms > of legislation around the world, including in the US at the moment, they > take into consideration issues pertaining to the authenticity of the > messages (forged headers), theft of service (unauthorized use of third party > systems) and similar issues. Going by memory, some also take into > consideration the harassment factor, or how many times a single message is > bombarded against an unsuspecting individual, however sadly, from what I can > read, the current proposed US federal legislation into this does not go this > far. In short the legislation is trying to go after the bulk mailers > without killing the Internet as a medium for electronic commerce. This is my understanding as well. Perhaps than Vernon is suggesting that such legislation does not go far enough, and is advocating a form of censorship? > > > One common thread of all the legislation that I've been able to get > reference to is the preservation of the right to be able to responsibly use > the Internet for business purposes. Please don't think that I'm trying to > make a case for the mass mailers here - I am not. Under your model, it > would be improper (or even illegal) for an individual or organization of any > type to make first contact via email - regardless of how it is being done, > and for what purpose. This is what I disagree with - there should be > reasonable ways in which people / organizations can continue to use this > medium to establish communications. Very much agreed! > > > If we shut down our ability to expand our horizions by shutting out all but > our established friends and business associates, the Internet will become a > very boring place to live in. Yes something like a "Friend of the IETF" social club or garden club... > Somehow a proper balance has to be > established, which should start with a solid and unchanging definition of > what spam is. I've heard your definition of spam, and countless others over > the years (I've even participated in some of the anti-spam groups a while > back), and the only consistent thread of all this was that nobody could > agree on the most basic issue of a commn definition. It's hard to make > much real progress in this area when you're going after a moving target. > And yes, the definition of what spam is, really *is* a moving target, > regardless of how firmly any of us believe in o
Re: Guidance for spam-control on IETF mailing lists
From: "Vernon Schryver" <[EMAIL PROTECTED]> > > With respect to the second above issue - I am very aware of what happend - > > some of our people sent single directed messages (unsolicited) to parties > > they thought might be interested in what we do. They were single, short > > messages, sent from real people on a one on one basis. They were sent with > > valid headers, through our servers, and only one short message was ever sent > > to anyone. We don't deal with unsolicited bulk advertising. > > > > I just have not had the time or energies as of late to set the records > > straight. > > The "straight record" of the messages archived by Google is that they were > unsolicited, more than one and substantially identical, and therefore > "spam" or "UBE" by the definition held my most informed people. They were indeed mostly identical, as is common when trying to make initial contact with new groups of people. They were however never sent more than once to a specific individual, regardless of wether or not the recipient replied. > In addition, because promoted or advocated a commercial product, they > were "UCE" or spam by the second most common definition. Are you suggesting that if the content were different, say promoting a personal sex site, that they would have been acceptable? Somehow I suspect that this is an ineffective metric by which to measure content. > The motives claimed by the senders are irrelevant. Whether the > unsolicited bulk mail is sent one at a time or with a single SMTP > transaction is irrelevant. Whether the headers are valid or you steal > service from third parties instead of only your spam targets is also > irrelevant. I and most informed people think that the contents of > the messages are irrelevant except to determine whether they are > substantially identical. The behavour that bulk emailers exhibit is substiantly different from happened in this case. I've outlined in detail what our people had done - if you look at the bulk mailers and their practices it is not difficult to determine many key differences. In fact if you look at the various forms of legislation around the world, including in the US at the moment, they take into consideration issues pertaining to the authenticity of the messages (forged headers), theft of service (unauthorized use of third party systems) and similar issues. Going by memory, some also take into consideration the harassment factor, or how many times a single message is bombarded against an unsuspecting individual, however sadly, from what I can read, the current proposed US federal legislation into this does not go this far. In short the legislation is trying to go after the bulk mailers without killing the Internet as a medium for electronic commerce. One common thread of all the legislation that I've been able to get reference to is the preservation of the right to be able to responsibly use the Internet for business purposes. Please don't think that I'm trying to make a case for the mass mailers here - I am not. Under your model, it would be improper (or even illegal) for an individual or organization of any type to make first contact via email - regardless of how it is being done, and for what purpose. This is what I disagree with - there should be reasonable ways in which people / organizations can continue to use this medium to establish communications. If we shut down our ability to expand our horizions by shutting out all but our established friends and business associates, the Internet will become a very boring place to live in. Somehow a proper balance has to be established, which should start with a solid and unchanging definition of what spam is. I've heard your definition of spam, and countless others over the years (I've even participated in some of the anti-spam groups a while back), and the only consistent thread of all this was that nobody could agree on the most basic issue of a commn definition. It's hard to make much real progress in this area when you're going after a moving target. And yes, the definition of what spam is, really *is* a moving target, regardless of how firmly any of us believe in our own particular interpretations. I believe that this is an important issue that needs to be discussed, however I also suspect that it is not in the context of the charter of either of these lists. As I stated in an earlier message in this thread, if anyone can point this off to a more appropriate forum, I'll be happy to shift my replies there. Best Regards, -- Tim
Re: Guidance for spam-control on IETF mailing lists
Keith Moore wrote: [..] > 1. it's unreasonable to expect occasional commentators to subscribe to a list >before sending traffic there. #include "we_all_dug_our_heels_in_over_this_topic_12_months_ago.h" > (it's completely reasonable to expect them to >read the charter, and any drafts they are commenting on, but not to jump >through extra hoops and to flood their mailboxes with unwanted traffic) I think we've already established that send-only addresses are possible. This removes the issues of being flooded by incoming mails from a list to which you're cross-posting. > 2. it's unreasonable to expect those who post from one address and subscribe >to the list using a different address, to have to know a secret handshake >that puts their posting address on the whitelist. Why on earth would the handshake be secret? > A simple fix for #2 is to put the instructions for getting on the whitelist > on the WG's charter page, and on any other announcements for the list. Precisely. cheers, gja -- Grenville Armitage http://gja.space4me.com
Re: Guidance for spam-control on IETF mailing lists
> Defining "spam" as any unsolicited and undesirable mail not only > makes it impossible for strangers to sent you mail but trivializes > the offense and makes it harder to penalize the real spammers. Taken to an extreme (very close to it for some definitions), it makes it difficult to differentiate legit email from spam, as it is impossible for a sender to before hand know the disposition of a given recipient at any point in time. Hey, at the rate we're going with defining everything under the sun as spam, my kids can start to lable my rambling in this way... :-) :-) > > | One of our > > | staff when sending a message to a customer asking if we could be of any > > | assistance in their deployment of our software > > > > if the customer didn't ask for help, that could be regarded as spam. > > It would be pretty rare for anyone to complain much about something like > > that though. This customer was in the process of trying to configure one of our systems - I fail to see how our proactively trying to assist should be taken in a negative light. It is however illustrative of how many people use the label of spam to describe almost anything that might upset them in the conect of email these days. This helps nobody, as the definition becomes so loose that its impossible to combat any more. > Another way that an individual can determine that a message is bulk > is by asking Google. For example, > http://groups.google.com/groups?q=+%22ima.%2Bcom%22+group%3Anews.admin.net-a buse.sightings > finds some reported spam. I hope that Mr. Kehres's employer is > not International Messaging Associates Ltd, because they appear to be > sending unvarnished unsolicited bulk advertising such as > http://groups.google.com/groups?selm=200110250552.AAA03935%40localhost.radpa rker.com > I hope that particular example was not the message in question, because > there are special reasons that make me confident that it was unsolicited > bulk advertising. Two issues here - first, no the message in question above is not the same as above. With respect to the second above issue - I am very aware of what happend - some of our people sent single directed messages (unsolicited) to parties they thought might be interested in what we do. They were single, short messages, sent from real people on a one on one basis. They were sent with valid headers, through our servers, and only one short message was ever sent to anyone. We don't deal with unsolicited bulk advertising. I just have not had the time or energies as of late to set the records straight. Best Regards, -- Tim
Re: Guidance for spam-control on IETF mailing lists
Date:Sun, 17 Mar 2002 21:24:50 +0800 From:"Tim Kehres" <[EMAIL PROTECTED]> Message-ID: <10e401c1cdb7$3ce5ffe0$[EMAIL PROTECTED]> | Traditional metrics for defining spam | (header forging, indiscriminate mass mailings, use of third party relays, | etc.) don't seem to be understood by many these days, That's because they're not the definition of spam - they're tools used by spammers to avoid retribution. They're often useful as a quick test of what is (or might be) spam, but they're certainly not requirements. | A previous posting asking to be removed due to the amount of spam received | (defined by this recipient as being content not interesting to them, That is almost the definition of spam - though unsolicited needs to be added, so ... | despite their membership on the list) if the messages were on topic for the list, then that's not spam, just a bad subscription choice. If they weren't, that's different. Some people require spam be bulk mail (sent to lots of recipients) - personally I see no sense in that, there's no easy way for any individual recipient to tell if they got the only copy of the message, or just one copy of a million sent to different addresses. So: | One of our | staff when sending a message to a customer asking if we could be of any | assistance in their deployment of our software if the customer didn't ask for help, that could be regarded as spam. It would be pretty rare for anyone to complain much about something like that though. kre
Re: Guidance for spam-control on IETF mailing lists
Jeff, > I don't think that I have seen any spam on this or the [EMAIL PROTECTED] > Mailing lists in quite a long time. Ad I can only recall two incidences > where I have seen any spam on either list. So I guess I am wondering > why there seems to be a perceived problem with spam on these > Mailing lists??? I've not noticed any spam on either of these lists either. On the other hand, I have noticed a tendancy of people to start to label arbitrary email as spam that otherwise would not be. Traditional metrics for defining spam (header forging, indiscriminate mass mailings, use of third party relays, etc.) don't seem to be understood by many these days, including the trade press. A previous posting asking to be removed due to the amount of spam received (defined by this recipient as being content not interesting to them, despite their membership on the list) is indicative of this problem. One of our staff when sending a message to a customer asking if we could be of any assistance in their deployment of our software resulted in our being reported to a spam organization simply due to an honest mistake in the saluation, and the customer being upset that we got their name wrong. The problem appears to be growing rather than being isolated to a few. I suspect that this is not the appropriate forum for a continued discussion of this issue, so if anyone can recommend a better list, please do let me know. Thanks and Best Regards, -- Tim
Re: Guidance for spam-control on IETF mailing lists
> Since cross-posters always (!) read each mailing list's charter before sending, > it is intriguing to consider that said posters probably also stumbled across > the list's subscription method. This would presumably move the act of > subscription from the realm of "obscure knowledge" and into the realm > of "duh". there are two pieces to this: 1. it's unreasonable to expect occasional commentators to subscribe to a list before sending traffic there. (it's completely reasonable to expect them to read the charter, and any drafts they are commenting on, but not to jump through extra hoops and to flood their mailboxes with unwanted traffic) 2. it's unreasonable to expect those who post from one address and subscribe to the list using a different address, to have to know a secret handshake that puts their posting address on the whitelist. A simple fix for #2 is to put the instructions for getting on the whitelist on the WG's charter page, and on any other announcements for the list. Keith
Re: Guidance for spam-control on IETF mailing lists
> From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> > To: Tim Kehres <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], IETF general mailing list <[EMAIL PROTECTED]> > ... > For the IETF list, it is because it is being run in the mode recommended > (subscribers only + large whitelist). > We started doing that a couple of months ago. > If you haven't noticed, it must be doing the right thing! Why are your, Eric Brunner-Williams's, Robert Elz's, and my messages present in the archive for the IETF list at http://www.ietf.org/mail-archive/ietf/index.html while Mr. Kehres's are absent? Vernon Schryver[EMAIL PROTECTED]
Re: Guidance for spam-control on IETF mailing lists
--On 17. mars 2002 21:24 +0800 Tim Kehres <[EMAIL PROTECTED]> wrote: >> I don't think that I have seen any spam on this or the [EMAIL PROTECTED] >> Mailing lists in quite a long time. Ad I can only recall two incidences >> where I have seen any spam on either list. So I guess I am wondering >> why there seems to be a perceived problem with spam on these >> Mailing lists??? > > I've not noticed any spam on either of these lists either For the IETF list, it is because it is being run in the mode recommended (subscribers only + large whitelist). We started doing that a couple of months ago. If you haven't noticed, it must be doing the right thing! Harald
Re: Guidance for spam-control on IETF mailing lists
Oh goodie! We get to chat about the other IAB -- Internet Advertizing Bureau. (http://www.iab.net) Reading Mr. Kehres back-to-front. Is in-list spam in-scope for poisson? Yup. Is there a venue for general spam? Yup (April's got it). Would adopting an opt-in regime in the US improve things? Yup. (spam TTL >= 3) Is everything a horrible muddle so nothing is clearly worth depricating? Noo, but that is a nice try. Cheers, Eric (ex-engage, where cookies were baked, users tracked, and marketing made)
Re: Guidance for spam-control on IETF mailing lists
On Sat, 16 Mar 2002, Joe Touch wrote: The main issue here is about the rule for the filter. We all want less spam. The difference is: - to me, spam is defined by content - to you, spam is defined by user and assumes a correlation between user and content I almost agree with your distinction but I want to make one clarification. To me, it's not that spam is defined by user, it's that non-spam is defined by user. What this means from an implementation point of view is that non-spam is almost trivial to configure and then more or less runs itself, or at least distributes the management to the subscribers. Thus the cost-benefit ratio for this particular spam control mechanism is negligible from the point of view of the *volunteer* list host. We have to remember that the bulk of IETF mailing lists are hosted and managed by volunteers. All mechanisms other than correlation by user have a labor intensive component. Such mechanisms are not excluded but they are impractical for volunteers. While I agree that "user ease" is of paramount concern, I do not believe it is a priority concern considering how the IETF as an organization "manages" its mailing lists. Now, if you want to talk about centralizing the management of the IETF lists, then the priority concern issues can be different. Jim
Re: Guidance for spam-control on IETF mailing lists
> From: "Tim Kehres" <[EMAIL PROTECTED]> > ... > http://groups.google.com/groups?selm=200110250552.AAA03935%40localhost.radpa > rker.com > > I hope that particular example was not the message in question, because > > there are special reasons that make me confident that it was unsolicited > > bulk advertising. > > Two issues here - first, no the message in question above is not the same as > above. > > With respect to the second above issue - I am very aware of what happend - > some of our people sent single directed messages (unsolicited) to parties > they thought might be interested in what we do. They were single, short > messages, sent from real people on a one on one basis. They were sent with > valid headers, through our servers, and only one short message was ever sent > to anyone. We don't deal with unsolicited bulk advertising. > > I just have not had the time or energies as of late to set the records > straight. The "straight record" of the messages archived by Google is that they were unsolicited, more than one and substantially identical, and therefore "spam" or "UBE" by the definition held my most informed people. In addition, because promoted or advocated a commercial product, they were "UCE" or spam by the second most common definition. The motives claimed by the senders are irrelevant. Whether the unsolicited bulk mail is sent one at a time or with a single SMTP transaction is irrelevant. Whether the headers are valid or you steal service from third parties instead of only your spam targets is also irrelevant. I and most informed people think that the contents of the messages are irrelevant except to determine whether they are substantially identical. Whether International Messaging Associates Ltd should have been disconnected by UUnet or the local Hong Kong reseller is not a matter for public consideration, although the sorry history of spam from UUNet and Hong Kong makes the apparently result unsurprising. However, it is certain that such messages are sufficient to get you long term entries in blacklists around the world. Now that I've check my own logs and blacklists, I have discovered that ima.com is in my blacklist because I received a substantially identical messaeg from [EMAIL PROTECTED] on Oct 23, 2001. Ima.com will remain in my blacklist until someone here has a reason to receive mail from ima.com, which given Mr. Kehres's words is unlikely to be soon. That Mr. Kehres is the technical contact for ima.com suggests that contrary to implications I take from his words, he probably knows all of this as well or better than I do. Vernon Schryver[EMAIL PROTECTED]
Re: Guidance for spam-control on IETF mailing lists
Date:Sun, 17 Mar 2002 23:58:31 +0700 From:Robert Elz <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | This isn't really relevant, but it certainly changes whether a crime | is being committed. Actually, I didn't read your words closely enough - what you wrote was quite correct there, I just misinterpreted. It still isn't relevant... kre
Re: Guidance for spam-control on IETF mailing lists
Date:Sun, 17 Mar 2002 09:24:32 -0700 (MST) From:Vernon Schryver <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | That you cannot tell whether someone climbing through a window in a | neighbor's house is a burglar or someone who lost their keys does not | change whether a crime is being committed or whether you ought to call | the police. This isn't really relevant, but it certainly changes whether a crime is being committed. On the assumption that I don't know however, it is still reasonable (good) to inform the police so it can be investigated. | Similarly, a responsible ISP can | often determine by various means whether spam has been sent, starting | with complaints alleging spam. Though you think you're disagreeing with me, you aren't. You say that if enough people complain about a message being spam, it is. But for any to complain, they have to treat it as spam. To them it is simply an unwanted unsolicited message. That's what they receive, that's what causes them to complain, that's what makes it spam. | Defining "spam" as any unsolicited and undesirable mail not only | makes it impossible for strangers to sent you mail but trivializes | the offense and makes it harder to penalize the real spammers. Not at all, the penalty just needs to be multiplied by the number of offences. Make it a $1 fine for each unwanted unsolicited message sent. Then if I send you a message explaining my views of the world, and you don't want it, I may have to fork out $1 as compensation. That's a risk that I should be willing to undertake - how much of a risk it will be will depend upon how accurately I can judge what you will be offended by enough to complain about. And of course, there has to be someone willing to bother collecting a penalty that small. What you regard as a "real spammer" on the other hand, who sends 10 or 1000 or something messages is going to face a penalty worth collecting. kre
Re: Guidance for spam-control on IETF mailing lists
Some have said that one or the other of these two lists have not passed any spam lately. I don't recall any spam from [EMAIL PROTECTED] lately, but I have 6 recent samples of unambigous spam (e.g. stock pump-and-dump) that came through odin.ietf.org (132.151.1.176). It seems some spammers are using that machine as as an open relay. > From: Robert Elz <[EMAIL PROTECTED]> > To: "Tim Kehres" <[EMAIL PROTECTED]> > cc: [EMAIL PROTECTED], "IETF general mailing list" <[EMAIL PROTECTED]> > ... >Some people require spam be bulk mail (sent to lots of recipients) - personally > I see no sense in that, there's no easy way for any individual recipient to > tell if they got the only copy of the message, or just one copy of a million > sent to different addresses. That you cannot tell whether someone climbing through a window in a neighbor's house is a burglar or someone who lost their keys does not change whether a crime is being committed or whether you ought to call the police. However, the police can investigate and often discover whether a crime has been committed. Similarly, a responsible ISP can often determine by various means whether spam has been sent, starting with complaints alleging spam. Defining "spam" as any unsolicited and undesirable mail not only makes it impossible for strangers to sent you mail but trivializes the offense and makes it harder to penalize the real spammers. An individual can often determine whether a message is bulk. For one example, if the message has been sent to other users of a common network of Distributed Checksum Clearinghouses, then the counts for the message's checksums will show that it is bulk. See http://www.rhyolite.com/anti-spam/dcc/ Judging by various indirect means including the obvious spam among the trials submitted to http://www.rhyolite.com/cgi-bin/dccproc-demo about 80% of spam is currently detected as such by the public DCC servers. (People often submit obvious non-spam to that demo, presumably to look for false positives.) > ... > | One of our > | staff when sending a message to a customer asking if we could be of any > | assistance in their deployment of our software > > if the customer didn't ask for help, that could be regarded as spam. > It would be pretty rare for anyone to complain much about something like > that though. Another way that an individual can determine that a message is bulk is by asking Google. For example, http://groups.google.com/groups?q=+%22ima.%2Bcom%22+group%3Anews.admin.net-abuse.sightings finds some reported spam. I hope that Mr. Kehres's employer is not International Messaging Associates Ltd, because they appear to be sending unvarnished unsolicited bulk advertising such as http://groups.google.com/groups?selm=200110250552.AAA03935%40localhost.radparker.com I hope that particular example was not the message in question, because there are special reasons that make me confident that it was unsolicited bulk advertising. Vernon Schryver[EMAIL PROTECTED]
Re: Guidance for spam-control on IETF mailing lists
Patrick R. McManus wrote: > [Joe Touch: Sat, Mar 16, 2002 at 02:03:22PM -0800] > >>Patrick R. McManus wrote: ... >>>The e2e-interest blacklist is new. It appears to be a reaction to the >>>embarrassing amount of spam that that list has redistributed over the >>>last couple of years >>> >>It's a little over a year since we converted from full-open to >>spam-limited. >> > > I guess I'm referring to the recent blacklist changes I remember you > writing about.. They stuck in my head because there was a big flurry > of messages about a February spam on that list. Yeah - because Mailman's filter field is limited, and it took a little time to determine how to combine procmail's capability with Mailman at our site. > http://www.postel.org/pipermail/end2end-interest/2002-February/001760.html > http://www.postel.org/pipermail/end2end-interest/2002-March/001902.html > > Indeed I only see 2 spam in feb's archive - not exactly an > overwhelmingly large number, We didn't have enough of a problem then to warrant dealing with it. March was a different issue. > Nonetheless, the necessary recent adjustment alone > is clear evidence the system needs constant administrative attention The filter switch was prompted by the event of March's flurry; the spam filter went from nonexistant (actually, only filtering certain kinds of prohibited posts, rather than spam per se), to existant (using a procmail keyword list that has been in use for other lists for several years, without substantial tweaking). The blacklist you refer to involved the yahoogroups.com list; this was needed because the list WAS subscribed to our list, and DID NOT contain any typical spam key words. This is a fall-through that breaks both our default assumptions, so simply is always going to require attention. > Additionally, I just checked the February archives of three other must > be registered to post mailing lists I'm on and they had 0 spams for > that period. They might have had filters. We didn't then. Or had 'user only' posts, in which case what you did not see were the users who had trouble posting or decided not to bother due to the complexity. I.e., this information can't be used to form a substantive conclusion. >>I believe that spam should be filtered out because of WHAT it is, not >>because of WHO it comes from. > > And frankly, that's going to constantly mean you live on the > censorship line. We both do; pity you do not yet see that. (vs. registration) ... > Under this scenario if you crossposted to a new IETF list (say in > response to a last call) you'd get back (more or less) immediately a > message that says "Hey, you're new to this list and I need to verify > that all new people aren't really spammers before I can post your > message. Are you really a person? If so you can reply to this message > with authcode XYZA in the body I looked at that solution too. It works, but again raises the bar higher for posters than I think is reasonable for an open list. There are times when I want to let people post, even if they don't have a valid reply mailing list. All I care about is content. >>I support a >>system that allows spam if the user subscribes (an issue you have not >>yet addressed). > > I assume that's a typo and you mean you don't support a system that > allows spam if the user subscribes. (At least that's consistent with > your message). Typo. I mean "you support...". I.e., you cannot handle spam from real users. Yes, yahoogroups.com 'registered' as a user. I can unsubscribe it, but automatic subscription is too easy to be useful as a deterrent. >> - to you, spam is defined by user >> and assumes a correlation between user and content > > I think this is a little unfair. It implies that some people have less > right to post than others because they are suspected spammers. When > the issue isn't about people at all, it's about forged From:'s and > automated spam bots (i.e. addresses, not users). There are users who still send spam (antivirus messages from automated scanners and vacation messages come to mind). I'm not saying they shouldn't post, but their spam shouldn't make it through. > Anybody that will > verify that they really are able to interpret responses sent back to > the address they post from should be allowed to post - heck, even > anonymous remailers are supported this way. Yes, but they will post their antiviruses and vacation info as well too. Again, the only way to filter spam is to filter spam. > I think you're implying a scenario where user X sends 9 on topic > messages and for the 10th one sends a "CHEAP LASER TONER REFILLS" > missive before returning to his thoughtful analysis. That just doesn't > happen often[1]. It was, in fact, the reason we even installed filters (for antivirus in particular) about a year ago (before we put in spam filters. FWIW, before you bother to use the current spam rate as a metric, I only put a test one in so far. the full one
Re: Guidance for spam-control on IETF mailing lists
Keith and all, I don't think that I have seen any spam on this or the [EMAIL PROTECTED] Mailing lists in quite a long time. Ad I can only recall two incidences where I have seen any spam on either list. So I guess I am wondering why there seems to be a perceived problem with spam on these Mailing lists??? Keith Moore wrote: > > And if I'm going to read a list, I'd > > much rather it be well run than just easy to post to. I define well > > run as _both_ spam-free and lacking in moderation delays. > > I define "well run" as having a high signal-to-noise ratio, > low moderation delay, a well-defined moderation policy that > evaluates messages visibly and impartially without considering > who authored them, and a low barrier to successful posting > of relevant content - even by non-subscribers. > > Expecting contributors to explicitly add their addresses to > a whitelist using obscure knowledge that is specific to > a particular list or software or moderator, and completely > unrelated to the knowledge required to contribute to the list, > imposes an unacceptably high barrier. > > But if we somehow made this process uniform from one list to > another, spammers would just add themselves to the whitelist. > > Keith > > p.s. though it is intriguing to consider - what if the instructions > for commenting on a draft were embedded somewhere within that > draft, so people would actually have to read it before commenting? Regards, -- Jeffrey A. Williams Spokesman for INEGroup - (Over 121k members/stakeholdes strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail [EMAIL PROTECTED] Contact Number: 972-244-3801 or 214-244-4827 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
Re: Guidance for spam-control on IETF mailing lists
[Joe Touch: Sat, Mar 16, 2002 at 02:03:22PM -0800] > Patrick R. McManus wrote: > I just have a different optimization you're optimizing for the 1 writer instead of the N readers. > > >The e2e-interest blacklist is new. It appears to be a reaction to the > >embarrassing amount of spam that that list has redistributed over the > >last couple of years > > It's a little over a year since we converted from full-open to > spam-limited. I guess I'm referring to the recent blacklist changes I remember you writing about.. They stuck in my head because there was a big flurry of messages about a February spam on that list. http://www.postel.org/pipermail/end2end-interest/2002-February/001760.html http://www.postel.org/pipermail/end2end-interest/2002-March/001902.html Indeed I only see 2 spam in feb's archive - not exactly an overwhelmingly large number, you are correct and I should have been more up to date. Nonetheless, the necessary recent adjustment alone is clear evidence the system needs constant administrative attention which in my mind is always a losing proposition because its a centralized function dealing with a very distributed problem. Additionally, I just checked the February archives of three other must be registered to post mailing lists I'm on and they had 0 spams for that period. I know the system isn't perfect, but in the current climate its very very good and it doesn't need to be adminstratively baby sat for filter updates. I'm certainly not trying to make this about the e2e list, its just that we both used it as an example - and apparently we both think it proves our own point ;) (and of course, ever opening one's mouth in a discussion driven by spam will surely be an action later regretted.) > I believe that spam should be filtered out because of WHAT it is, not > because of WHO it comes from. And frankly, that's going to constantly mean you live on the censorship line. You're evaluating content. yech. By just delaying posts instead of deleting them its certainly *not* censorship, but the two bowls of soup share the same stock. I actually believe that spam is defined by its content as well, but as a pragmatic matter filtering should not be. Actual spam infractions by real people-operated email addresses are so rare that we can deal with those on a one-off basis after they've managed to propagate their garbage once. There's no need for prior restraint based on WHAT - especially if you can easily make sure that all participants are real people beforehand. I think objections as to how hard user managed post-only address are, are vastly overstated. If someone can signup for the list once, then they can certainly signup with delivery-off a second time to support a post-only address. (especially if the bounced-message-from-non-member message gives instructions on this.) Alternative mechanisms (of which I've never seen) that allow you to submit additional post-only addresses with your subscription would be even better. Comparisons to broken vacation and virus-detection setups just aren't germane. > >At some point a legitimate submission will be snagged as a false > >positive by that system. > > My original post had details on this - like the IETF suggestion, our > list puts spam in a folder for moderator confirmation. False positives > are corrected there. of course. Nothing gets deleted. However, its been voiced several times (and I'll voice it again) that a real conversation is impinged when some people (direct to:'s and cc:'s) get the messages at substantially different rates than others (list recipients).. in a content based system where a false positive can happen at an unanticipated moment I could see this being even worse (murphy's law and all). the difference is hardly life and death of course. > I do believe that non-subscribers have just as much reason and > permission to post to these (mine and the IETF) lists. as do I. I draw a distinction between subscribers and registereds. In my mind subscribees get copies of all the list posts. So non-subscribers have every right to post, but registration (if only to verify that you're a human being) is necessary. The person can send one verification mail that says join with delivery off. I agree that there doesn't need to be a rule that requires at least one delivery address. Mailman supports this now. It might be even better if the bounce-because-you're-not-registered mail also triggered and an implicit "subscribe the sender as post-only" request that the sender only needed to verify to automatically 'approve' the stalled post and get put on the post-only list. Under this scenario if you crossposted to a new IETF list (say in response to a last call) you'd get back (more or less) immediately a message that says "Hey, you're new to this list and I need to verify that all new people aren't really spammers before I can post your message. Are you really a person? If so you can reply to this message with authcode XYZA in the body. This
Re: Guidance for spam-control on IETF mailing lists
Keith Moore wrote: [..] > Expecting contributors to explicitly add their addresses to > a whitelist using obscure knowledge that is specific to > a particular list or software or moderator, [..] > p.s. though it is intriguing to consider - what if the instructions > for commenting on a draft were embedded somewhere within that > draft, so people would actually have to read it before commenting? Since cross-posters always (!) read each mailing list's charter before sending, it is intriguing to consider that said posters probably also stumbled across the list's subscription method. This would presumably move the act of subscription from the realm of "obscure knowledge" and into the realm of "duh". cheers, gja
Re: Guidance for spam-control on IETF mailing lists
Evil[1] is always the manipulator of good ideas. Evil[1] will fill the greater good, if we do not act now. by act now I do not want a whitelist that is "publicly" maintained. -Wonko the Sane [1]=U.C.E. At 07:11 PM 3/16/02 -0500, Keith Moore wrote: >> And if I'm going to read a list, I'd >> much rather it be well run than just easy to post to. I define well >> run as _both_ spam-free and lacking in moderation delays. > >I define "well run" as having a high signal-to-noise ratio, >low moderation delay, a well-defined moderation policy that >evaluates messages visibly and impartially without considering >who authored them, and a low barrier to successful posting >of relevant content - even by non-subscribers. > >Expecting contributors to explicitly add their addresses to >a whitelist using obscure knowledge that is specific to >a particular list or software or moderator, and completely >unrelated to the knowledge required to contribute to the list, >imposes an unacceptably high barrier. > >But if we somehow made this process uniform from one list to >another, spammers would just add themselves to the whitelist. > >Keith > >p.s. though it is intriguing to consider - what if the instructions >for commenting on a draft were embedded somewhere within that >draft, so people would actually have to read it before commenting? > >
Re: Guidance for spam-control on IETF mailing lists
Joe Touch wrote: [..] > Lists for open discussion should [not] require such hoops for participation, > esp. when there are plenty of reasonable, sufficiently correlated > identifiers than "not a list member" to identify spam. Could you post some pointers to studies of the efficacy of these correlated identifiers when applied to content-filtering? It might help calm things down on this thread cheers, gja
Re: Guidance for spam-control on IETF mailing lists
> And if I'm going to read a list, I'd > much rather it be well run than just easy to post to. I define well > run as _both_ spam-free and lacking in moderation delays. I define "well run" as having a high signal-to-noise ratio, low moderation delay, a well-defined moderation policy that evaluates messages visibly and impartially without considering who authored them, and a low barrier to successful posting of relevant content - even by non-subscribers. Expecting contributors to explicitly add their addresses to a whitelist using obscure knowledge that is specific to a particular list or software or moderator, and completely unrelated to the knowledge required to contribute to the list, imposes an unacceptably high barrier. But if we somehow made this process uniform from one list to another, spammers would just add themselves to the whitelist. Keith p.s. though it is intriguing to consider - what if the instructions for commenting on a draft were embedded somewhere within that draft, so people would actually have to read it before commenting?
Re: Guidance for spam-control on IETF mailing lists
> I don't want to approve senders. I want to approve posts. Some senders > send approved posts as well as non-approved posts. Some formats are not > approved (BCC, CC'd in long lists, etc.) > > I don't want to filter on sender; I want to filter on spam content, so I > filter on spam content. Using non-spam info (sender) to infer spam > content is needlessly indirect. it's a tradeoff. one solution delays all messages and introduces a greater risk that the moderator will exercise too much control over content. the other solution delays first posts more than others and risks some spam getting through. I prefer the latter compromise. however, I don't think this should be carved in stone for all WG lists for all time. I do think there need to be clearly established limits on how zealous a moderator can be in filtering messages, visibility for the moderator's actions, etc. Keith
Re: Guidance for spam-control on IETF mailing lists
[Joe Touch: Sat, Mar 16, 2002 at 11:21:28AM -0800] > >Someone with N addresses they'd like to post from simply subscribes to > >the list from all of them and sets the disable delivery flag on N-1 of > >them. Mailman seems to define temporary as "until I unset this attribute". > > > >No admin intervention required. > > Yes. But lots of user intervention required. > > Lists for open discussion should require such hoops for participation, > esp. when there are plenty of reasonable, sufficiently correlated > identifiers than "not a list member" to identify spam. Actually I think whitelists, even self-service whitelists, are much more effective than blacklists. And if I'm going to read a list, I'd much rather it be well run than just easy to post to. I define well run as _both_ spam-free and lacking in moderation delays. I'm willing to go through a little hassle to keep the system running well. Sometimes the integrity of the system is simply more important than my personal convenience. I think you're defining the calculus of list policy wholly in terms of the poster and not at all in terms of the large numbers of readers. blacklists always drift over time. They require an astonishing amount of energy to keep current - otherwise their rates of both false positives and negatives keep inching up. The e2e-interest blacklist is new. It appears to be a reaction to the embarrassing amount of spam that that list has redistributed over the last couple of years. Clearly, the brand new system is not a useful datapoint yet, but the totally unregulated nature of the list whose results dictated the need for the new policy is a strong indictment against pure open lists in the current climate. At some point a legitimate submission will be snagged as a false positive by that system. The submitter is powerless to correct it. Given a system where the "also-post-from" list is under the sender's control (as was just illustrated with mailman) the user can take initiative and fix the problem. And false positives will happen. A recent ha-ha example from one of the linux development lists was discussion regarding the SCSI driver for the aic7700 series of chips. That driver is known (for obvious reasons) as the aic7XXX driver. Someone's nanny software flagged those messages as porn ads. To me, the obvious corollary to approved whitelists are phone/internet credit card purchases. Most vendors will only ship to approved addresses. Generally this is your billing address. However, if you call most credit card companies they will add additional "approved to ship to" (aka post only) addresses to your card. As a credit card user this doesn't strike me as particularly onerous to help maintain the integrity (and ultimately the utility) of the system. If a list bounces my crosspost, but also gives me an option to "confirm you're a person not a program even if you don't want to receive copies of list traffic" I think that's a perfectly reasonable thing to ask before echoing my (deep and profound) thoughts to a couple thousand other people. Plus, becaause its user and not administrative driven, it scales well. -Patrick
Re: Guidance for spam-control on IETF mailing lists
[James M Galvin: Fri, Mar 15, 2002 at 08:40:44PM -0500] > > On Fri, 15 Mar 2002, Joe Touch wrote: > > > These are destination-only addresses, used for forwarding. I tried this > with Mailman (presumably a "modern" application?), to which I had > subscribed [EMAIL PROTECTED]; it held it for approval. My options as > moderator are: approve, reject, defer, or discard. No option for 'add to > list of approved senders' - that requires more steps, for ME (not under > the control of the sender). There are no options for the user to be able > to add or control aliases. > > Or is Mailman not modern? > > Mailman is modern. Like its counterparts you can have an "authorized to > submit but do not receive" functionality. I believe the issue you're > raising is that mailman, like its counterparts, does not have an > integrated means to manage the exception list. > I subscribe to a couple of different lists that (ab)use mailman's "temporarily disable delivery" attribute for this purpose. Someone with N addresses they'd like to post from simply subscribes to the list from all of them and sets the disable delivery flag on N-1 of them. Mailman seems to define temporary as "until I unset this attribute". No admin intervention required. -Patrick
Re: Guidance for spam-control on IETF mailing lists
Keith Moore wrote: >>Lists for open discussion should require such hoops for participation, >>esp. when there are plenty of reasonable, sufficiently correlated >>identifiers than "not a list member" to identify spam. >> > > assuming you meant "should not require" I'm very much in agreement. Oops - typed too fast for Netscape. Yes, should NOT require. > especially when it's trivial to fix things so that the process used > by a moderator to approve a message also adds the sender of that > message to the "allowed posters" list. I don't want to approve senders. I want to approve posts. Some senders send approved posts as well as non-approved posts. Some formats are not approved (BCC, CC'd in long lists, etc.) I don't want to filter on sender; I want to filter on spam content, so I filter on spam content. Using non-spam info (sender) to infer spam content is needlessly indirect. Joe
Re: Guidance for spam-control on IETF mailing lists
Patrick R. McManus wrote: > [Joe Touch: Sat, Mar 16, 2002 at 11:21:28AM -0800] >>Lists for open discussion should require such hoops for participation, >>esp. when there are plenty of reasonable, sufficiently correlated >>identifiers than "not a list member" to identify spam. ... > I think you're defining the calculus of list policy wholly in terms of > the poster and not at all in terms of the large numbers of readers. I just have a different optimization > The e2e-interest blacklist is new. It appears to be a reaction to the > embarrassing amount of spam that that list has redistributed over the > last couple of years It's a little over a year since we converted from full-open to spam-limited. The transition was motivated largely by poorly configured automated virus detection software, which implosion-spammed the list too frequently. Since this was the result of user (mis)configuration, I'm not as willing as you to make configuration management a user-participation event. > Clearly, the brand new system is not a useful datapoint yet, (if you had checked our website, you would know it wasn't brand new.) > but the totally unregulated nature of the list whose > results dictated the need for the new policy is a strong indictment > against pure open lists in the current climate. There I at least agree- pure open (no spam filter, no user filter) was insufficient. I believe that spam should be filtered out because of WHAT it is, not because of WHO it comes from. > At some point a legitimate submission will be snagged as a false > positive by that system. My original post had details on this - like the IETF suggestion, our list puts spam in a folder for moderator confirmation. False positives are corrected there. --- I do believe that non-subscribers have just as much reason and permission to post to these (mine and the IETF) lists. I support a system that allows spam if the user subscribes (an issue you have not yet addressed). The main issue here is about the rule for the filter. We all want less spam. The difference is: - to me, spam is defined by content - to you, spam is defined by user and assumes a correlation between user and content Joe
Re: Guidance for spam-control on IETF mailing lists
> Lists for open discussion should require such hoops for participation, > esp. when there are plenty of reasonable, sufficiently correlated > identifiers than "not a list member" to identify spam. assuming you meant "should not require" I'm very much in agreement. especially when it's trivial to fix things so that the process used by a moderator to approve a message also adds the sender of that message to the "allowed posters" list. Keith
Re: Guidance for spam-control on IETF mailing lists
Patrick R. McManus wrote: > [James M Galvin: Fri, Mar 15, 2002 at 08:40:44PM -0500] > >>On Fri, 15 Mar 2002, Joe Touch wrote: >> >> >>These are destination-only addresses, used for forwarding. I tried this >>with Mailman (presumably a "modern" application?), to which I had >>subscribed [EMAIL PROTECTED]; it held it for approval. My options as >>moderator are: approve, reject, defer, or discard. No option for 'add to >>list of approved senders' - that requires more steps, for ME (not under >>the control of the sender). There are no options for the user to be able >>to add or control aliases. >> >>Or is Mailman not modern? >> >>Mailman is modern. Like its counterparts you can have an "authorized to >>submit but do not receive" functionality. I believe the issue you're >>raising is that mailman, like its counterparts, does not have an >>integrated means to manage the exception list. >> >> > > I subscribe to a couple of different lists that (ab)use mailman's > "temporarily disable delivery" attribute for this purpose. > > Someone with N addresses they'd like to post from simply subscribes to > the list from all of them and sets the disable delivery flag on N-1 of > them. Mailman seems to define temporary as "until I unset this attribute". > > No admin intervention required. Yes. But lots of user intervention required. Lists for open discussion should require such hoops for participation, esp. when there are plenty of reasonable, sufficiently correlated identifiers than "not a list member" to identify spam. Joe
Re: Guidance for spam-control on IETF mailing lists
On Fri, 15 Mar 2002, James M Galvin wrote: > That is not to say that you can not "automatically" manage the exception > list. You just have to set it up. LISTSERV (and my service) has a > NOMAIL feature. I believe with all of majordomo, mailman, and Lyris you > can setup a "list" to be your exception list and then you configure the > real list to also look there when checking "permissions". Thus you use > ordinary subscribe and unsubscribe commands to manage the exception > "list". It's not integrated in that it requires the maintainer to set > it up, but once set up it will work. > > > In any case the penalty for getting > > it wrong is delay, not censorship (at least in the case of the IETF > > guidelines). > > Nope - the penalty is WORK for the moderator too. > > Agreed, but the work is once per email address if you add every > exception to the "authorized" list as you discover them. Once things > settle down there shouldn't be very much work. > > Jim there is also a work around for majordomo lists - if you "re-purpose" the .intro file - see: http://darkwing.uoregon.edu/~llynch/majordomo/secondary.html this is easier to manage than a second list, although this is passive for list members unless you announce it via the info file -- I just add secondary addresses as they occur -- users who want to declare a secondary would need to send email to owner-listname. - lel
Re: Guidance for spam-control on IETF mailing lists
In article <[EMAIL PROTECTED]> you write: >And how is this different than requiring a poster to use the correct >originating email address in the first place? My message is arriving in your mailbox, and at this mailing-list's exploder, with ``the correct originating email address''. Said address has no discernable mapping to the address of the mail-to-news gateway which is subscribed to this list on my behalf. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
Re: Guidance for spam-control on IETF mailing lists
> With that in mind, when a mechanism that delays submissions from > non-subscribers is first employed, some number of people will "trip" > over it. They usually whine about it but once the rules are explained > to them they realize they do have a responsibility to pay attention to > how they use their email. If by "paying attention to how they use their email" you mean that the author should pick his From address on a per-message basis, so that he uses the subscription address for that list, I emphatically disagree. If nothing else this presumes that the author wants to see personal replies to the messages he sends to the list to go to the same mailbox as other traffic that comes from the list. This is not a reasonable assumption. I'm all for reducing the amount of spam on WG lists as long as the filters don't impair genuine contributions. But I'm fed up with WG lists that expect me to remove my shoes, kneel, bow in the direction of Mae West, and precisely utter some strange incantation, just so that I can get past that list admin's parochial idea of the responsible way to send mail. And I've seen too many cases where the purpose of these meaningless hoops seemed to be to exclude useful contributions from outsiders merely because they didn't know the secret handshake. Keith
Re: Guidance for spam-control on IETF mailing lists
On Friday, March 15, 2002, at 09:53 AM, Keith Moore wrote: > > I dunno. I've received several complaints from people who've received > spam with my address in the From field. I don't know if I'm being > singled out by a spammer [...] You are not. I've seen this tactic used by spammers to circumvent access control on other lists to which I subscribe. In the last month, I've seen it used on three different totally unrelated lists. -- j h woodyatt <[EMAIL PROTECTED]>
Re: Guidance for spam-control on IETF mailing lists
James M Galvin wrote: > On Fri, 15 Mar 2002, Joe Touch wrote: > > A nontrivial number of users utilize employer-independent email > destinations, such as *@ieee.org, *acm.org, etc. > > I'm not willing to write-off that as ignorance of how email works. > > Sorry, you lost me here. I thought the point was that people do have > those email addresses. All I'm suggesting is that they should originate > their email from those addresses Many current mail ports (SMTP) won't allow users to 'spoof' their source email address. They prohibit mail entering their system UNLESS it is either TO or FROM their known list of users. That's why this all fails. > and believe if they know enough to have > such addresses then they know enough to do that. Knowing enough to do it isn't the same as being able to do it. > These are destination-only addresses, used for forwarding. I tried this > with Mailman (presumably a "modern" application?), to which I had > subscribed [EMAIL PROTECTED]; it held it for approval. My options as > moderator are: approve, reject, defer, or discard. No option for 'add to > list of approved senders' - that requires more steps, for ME (not under > the control of the sender). There are no options for the user to be able > to add or control aliases. > > Or is Mailman not modern? > > Mailman is modern. Like its counterparts you can have an "authorized to > submit but do not receive" functionality. I believe the issue you're > raising is that mailman, like its counterparts, does not have an > integrated means to manage the exception list. > > That is not to say that you can not "automatically" manage the exception > list. You just have to set it up. LISTSERV (and my service) has a > NOMAIL feature. I believe with all of majordomo, mailman, and Lyris you > can setup a "list" to be your exception list and then you configure the > real list to also look there when checking "permissions". Yes. How do entries get added there? Why don't I have to check that? It's hard enough to get users to manage their own entries; requiring users to subscribe every alias to this 'permission list' is overkill. > > In any case the penalty for getting > > it wrong is delay, not censorship (at least in the case of the IETF > > guidelines). > > Nope - the penalty is WORK for the moderator too. > > Agreed, but the work is once per email address if you add every > exception to the "authorized" list as you discover them. I run what most would consider moderate to small lists of 1500. That is simply too much work. Joe
Re: Guidance for spam-control on IETF mailing lists
On Fri, 15 Mar 2002, Joe Touch wrote: A nontrivial number of users utilize employer-independent email destinations, such as *@ieee.org, *acm.org, etc. I'm not willing to write-off that as ignorance of how email works. Sorry, you lost me here. I thought the point was that people do have those email addresses. All I'm suggesting is that they should originate their email from those addresses and believe if they know enough to have such addresses then they know enough to do that. How did "ignorance" get factored in? These are destination-only addresses, used for forwarding. I tried this with Mailman (presumably a "modern" application?), to which I had subscribed [EMAIL PROTECTED]; it held it for approval. My options as moderator are: approve, reject, defer, or discard. No option for 'add to list of approved senders' - that requires more steps, for ME (not under the control of the sender). There are no options for the user to be able to add or control aliases. Or is Mailman not modern? Mailman is modern. Like its counterparts you can have an "authorized to submit but do not receive" functionality. I believe the issue you're raising is that mailman, like its counterparts, does not have an integrated means to manage the exception list. That is not to say that you can not "automatically" manage the exception list. You just have to set it up. LISTSERV (and my service) has a NOMAIL feature. I believe with all of majordomo, mailman, and Lyris you can setup a "list" to be your exception list and then you configure the real list to also look there when checking "permissions". Thus you use ordinary subscribe and unsubscribe commands to manage the exception "list". It's not integrated in that it requires the maintainer to set it up, but once set up it will work. > In any case the penalty for getting > it wrong is delay, not censorship (at least in the case of the IETF > guidelines). Nope - the penalty is WORK for the moderator too. Agreed, but the work is once per email address if you add every exception to the "authorized" list as you discover them. Once things settle down there shouldn't be very much work. Jim -- James M. Galvin <[EMAIL PROTECTED]>
Re: Guidance for spam-control on IETF mailing lists
On Fri, 15 Mar 2002, Joe Touch wrote: I considered some of the solutions the IETF is recommending, and rejected the "closed list" requirement because we (and I believe many IETF mailing lists) have too many members that have preferred delivery addresses that aren't correlated to their source address. While empathetic to the issue I'm not as sympathetic as you. In general, people who have multiple email addresses and actually *use* multiple email addresses know a little something about how email works. This is a necessity since I would assert it is not possible to effectively *use* multiple email addresses without keeping track of which email address is for what purpose. With that in mind, when a mechanism that delays submissions from non-subscribers is first employed, some number of people will "trip" over it. They usually whine about it but once the rules are explained to them they realize they do have a responsibility to pay attention to how they use their email. Once they "get it" the "issue" passes and everything runs smoothly. If needed, people can have multiple email addresses authorized to submit messages. All modern list applications support this feature. It's a one time configuration step for a list owner and then, once again, the "issue" passes and everything runs smoothly. I disagree that it is onerous to require an originator to pay attention to how they originate their email. In any case the penalty for getting it wrong is delay, not censorship (at least in the case of the IETF guidelines). The benefits of employing such a mechanism far outweigh the consequences, in my opinion. On the other side, cross-posting is the canonical example of what can quickly become an overwhelming job for the "spam monitor" when such a mechanism is employed. There is no easy solution to this problem, if in fact it really is a problem. One could argue it shouldn't be, i.e., a discussion may start on more than one list but at least in the IETF if it is a substantive discussion it should find itself *a* home. List owners can make this so if they choose regardless. Of course the IETF could deal with this issue itself quite simply by centralizing the management of all its lists, since then it would have access to a complete set of subscribers from all lists. Of course, that solution has its own set of issues. Responding to your other comments: re #1) just because a post comes from a subscriber doesn't ensure it is not spam (assume 'spam' is a car advertisement, e.g., not a quality assessment of a participant's post :-). True, but the majority of "real spam" comes from effectively anonymous sources. Also, a mailing list is quite good at policing itself (especially in the IETF), so when a known person spams they are quickly chastised. re #2) potential spam should be just that (as indicated), but one-day turnaround is too much work. posters should avoid using spam trigger words (e.g., this option needs viagra) And how is this different than requiring a poster to use the correct originating email address in the first place? And how are they to know what that triggers words are on a per list basis? re #5) checking the list of known addresses needlessly endorses a single solution. as shown above, there are others, and it should be up to the list maintainer to decide what to use I disagree that the endorsement is "needless." We need to make it clear what mechanisms are permitted. This mechanism is not required but it is, in my opinion, the most straightforward to setup and manage. Simplicity and ease of use are tantamount. Also, the guidance does not exclude other mechanisms. If what you have works I say go with it. Jim -- James M. Galvin <[EMAIL PROTECTED]>
Re: Guidance for spam-control on IETF mailing lists
Keith Moore wrote: >>>Will not the spammers soon learn to send their spams with >>>one of these addresses as bogus sender? >>> >>You overestimate the spammers :-). Most probably have no idea what IETF >>is or that they're spamming an IETF list. >> > > I dunno. I've received several complaints from people who've received > spam with my address in the From field. I don't know if I'm being > singled out by a spammer (maybe he got angry at my "I support the death > penalty for spammers" bumper sticker?), or if spammers are starting > to forge addresses in general. > > But if history is any indication, spammers should not be underestimated. > They have proven quite capable of learning how to circumvent various > kinds of filtering. We recently had a similar problem on the end2end-interest list, and a few other lists I manage. Regarding the above, one possibility is that any email address that appears on a web page may, at any time, be used either as source or destination by a spammer. I considered some of the solutions the IETF is recommending, and rejected the "closed list" requirement because we (and I believe many IETF mailing lists) have too many members that have preferred delivery addresses that aren't correlated to their source address. What we are doing is: - use procmail to filter mail using well-known weighted-keyword lists, it adds a "X-Possible-Reject:" header (when the weight is exceeded) mail with this header is then held in a spam file which is verified periodically by the moderator (errors are resent to the list and routed around procmail) using my own set of filters, it adds a "X-Holdforapproval:" header when indicated mail with this header is held in mailman... - we use mailman for processing posts mail with "X-Holdforapproval:" is held The reasons: 1) "closed list" (poster must be subscribed) is not viable for users with uncorrelated delivery and post addresses, and discourages non-member posts (which is restrictive for open dialogue, IMO). 2) procmail has more powerful filters than mailman (or most other maillist systems I've seen) There are details to tying any two systems together; in this case, they relate to userid/groupid coordination, /etc/aliases, etc. As with any solution, this doesn't satisfy all subscribers. It does, IMO, a) maximize convenience to posters (not requiring subscription to post, encouraging open dialogue) b) minimize pain to subscribers (avoiding multiple subscriptions or post-from-subscribed-address problems) c) minimize maintenance effort by the moderator (avoiding maintaining lists of alternate posters or approved posters) This is not the only viable solution to this problem. I do disagree with the IESG's policy on the following three items: re #1) just because a post comes from a subscriber doesn't ensure it is not spam (assume 'spam' is a car advertisement, e.g., not a quality assessment of a participant's post :-). re #2) potential spam should be just that (as indicated), but one-day turnaround is too much work. posters should avoid using spam trigger words (e.g., this option needs viagra) re #5) checking the list of known addresses needlessly endorses a single solution. as shown above, there are others, and it should be up to the list maintainer to decide what to use Joe
Re: Guidance for spam-control on IETF mailing lists
> > Will not the spammers soon learn to send their spams with > > one of these addresses as bogus sender? > > You overestimate the spammers :-). Most probably have no idea what IETF > is or that they're spamming an IETF list. I dunno. I've received several complaints from people who've received spam with my address in the From field. I don't know if I'm being singled out by a spammer (maybe he got angry at my "I support the death penalty for spammers" bumper sticker?), or if spammers are starting to forge addresses in general. But if history is any indication, spammers should not be underestimated. They have proven quite capable of learning how to circumvent various kinds of filtering. Keith
Re: Guidance for spam-control on IETF mailing lists
On Fri, 15 Mar 2002, Jacob Palme wrote: > At 10:03 -0500 02-03-14, The IESG wrote: > > The level of spam on IETF mailing lists has now reached the > > level that we encourage the use of operational controls as > > described in: > > > > http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt > > > > In particular, list managers are encouraged to employ the > > use of automatic mechanisms that immediately distribute > > messages submitted by subscribers and other known email > > addresses while directing all other messages to a human > > reviewer for rejection or approval. > > > 5) Mailing lists that check the sender's address as part of the > > determinate of what might be spam must also support a list of "known > > email addresses" whose submissions are automatically approved > > without human intervention. The list of "known email addresses" must > > include at least the following addresses: > > > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > Will not the spammers soon learn to send their spams with > one of these addresses as bogus sender? You overestimate the spammers :-). Most probably have no idea what IETF is or that they're spamming an IETF list. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords