Re: authenticated email
Theodore Ts'o wrote: Signed e-mail is useful for assuring that e-mail message sent at one point in time is the same as an e-mail message sent earlier. (Not necessarily just for list mail, but also for person-to-person mail.) ... For the specialized case of preventing SPAM, it's not necessarily necessary to do the full authenticated e-mail where we know the ... someone, your public key figureprint must either be on a list of acceptable senders, or you must submit some kind of mathematical evidence that you have spent 5-10 minutes of CPU time crunching on some particular problem. Agreed. CPU time falls under the same class of schemes as the address validity test that we already have for list e-mail; the spammer has to invest more time and money, and have a bigger risk of capture, the more we demand from unknown senders. On list enrollment, you could even demand that the same address be valid for some time, such as a day, through a delayed validation scheme. Hit and run spammers might not be able to use the same mail address for a very long time. Could we use the same for person-to-person e-mail? If I read the spam a day after it has been sent, will the spammer's mail agent still be there for an automatic ack that the address is valid? In general, I'm very much in favor of these types of mechanisms as opposed to a knee jerk "lets authenticate everyone and see if it helps" approaches ;-) (This doesn't mean that such mechanisms are ready to be deployed and problem free in all cases.) Yeah, some special provision would be needed for CPU-limited PDA's, but most PDA's that I've seen don't attempt to talk to the network directly; they generally go through some kind of mutually trusted gateway box that could do the CPU crunching for them. And speaking of problems, I do think the imparity between different devices is a real issue for the CPU time method. *Your* PDA may not talk to the network directly, but *my* phone runs IMAP, SMTP, SSH, SSL, HTTP, and streaming video from the net in addition to the usual office applications such as Doom and C64 emulator ;-) Given this, some people might argue that my phone can then afford the CPU crunching as well. Perhaps, but the problem is that while the capacity in the low-end increases, the same happens for the high-end as well. I'd claim that the relative speed difference stays constant over time. I don't have a good suggestion on how to resolve this, however. Perhaps the lowest common denominator is still a big enough deterrent? Note that help from a network entity is not likely solve this problem. Think about it: the average users are not going to install their own network helpers. They are going to rely ISPs' servers. So, we'd see SMTP servers that do the number crunching on behalf of the ISP's customers. Enter a spammer who claims to have a small device... --Jari
Re: authenticated email
--On onsdag, juni 04, 2003 13:02:11 +0200 Alexandru Petrescu <[EMAIL PROTECTED]> wrote: Harald Tveit Alvestrand wrote: I thought I'd try this is there any particular disadvantage or centralization of power implied in me signing this message with my PGP key? Is there an IETF PGP keyserver somewhere? nope. we have had a lot of PGP key signing parties at IETFs, but nothing "official". I generally use wwwkeys.eu.pgp.net when I look for keys, but there's nothing very magical about that. Did you store the key securely on the keyserver? Why should I? It's signed, so it's either there or not there - you can't fake it, just remove it. (And sometimes I wish the keyservers WOULD drop some keys - there's an old key of mine out there that I don't use any more) Which keyserver? Which port? The particular network I connect to is blocking most ports, so I can't retrieve your public key. It's attached below, too. Anything to increase the Kbytes-posting-stats :) On another hand, the same particular network recommends that its users use a particular MUA, which has built-in certs of certain CAs, which allows readers of this email to trust I am who I claim to be, "legally" (as if I showed an ID). If not, is there any particular reason that I shouldn't do this all the time? Will the government of the country you live in allow you to store your public key on a public PGP keyserver? (a particular government was _not_ allowing it as of 1997, and if things have changed since then I'm happy, but the "try and find out" way is high risk for me.) The Norwegian government does not care, so that's not a downside for me - but of course, your mileage may vary. Harald -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.2 (GNU/Linux) mQGiBDS6GscRBADSUKFMf4osMWUHpRqFUjqklLpq4tjL5gYFH5sjYFleu0XYWsB1 AI9ToSfKljxYkePRSXIMArb94RV2VHLmyEvU5VLgKgLT6Sw8mUyf5GJh2uC+fECq on8b5yFiuRo7Fut7b0sDvRv7/TPbQ7brKBboQK7H2IWKmBbjDIhKnkiElwCg/3nK JJNg8/V9G06BNg9At6WDWcUEALZuJx+y0wGqhIZvZExwekYZuVH1kWJ3gvq/r0U0 ESrsXQ4p4NAFfG+uWpGTyHDOS4xTvgQE6bAe1RNsIbevi4WeT00yYbUEnR6Ylqyr SYGBMLBacEjCenS4bQOCVhv25oZQS60FQXeHDRpsnLt4DsPNn0OuTyDT7xyPzNAy 5eTQA/4mktErIaqWNRwmto/Tx71J90EqCcOoQQQ2XbDlmRp29AK8O782AAp0HgW1 ebK4cuUOwHOwYWHyFqeCVhrVjfVUJu62iyg54QKgaIPU7RwiCAM03buBJz4fMo3B wHyP3uLn/ICxBoTGz/rPYJ1RktfvP7KIXJ1dct1u45wRy83dSLQuSGFyYWxkIFR2 ZWl0IEFsdmVzdHJhbmQgPEhhcmFsZEBBbHZlc3RyYW5kLm5vPohOBBARAgAOBAsD AQICGQEFAjfJgygACgkQOMj+2+WY0F5CNQCdGxcVXgFjHfvpoaRKltv8cSvS9iUA nRY9zfYjWEmBOZvMBADMHTFogPM7iEYEEBECAAYFAjyZbDMACgkQ4hFoDYCwek8h FQCg6guHn1DLmXzrJSeoltYkboVihnwAmgPUnRT4fSJ88/jKhjltI0gHUSxIiQCV AgUQPJlsNUQVcM1Ga0KJAQFDawP9EZ1J4lkNR+HAxa2RUvQcSEPCE/2B2P2QMABn vtCFFhlxseD/qyLk3Dz03WaOsVS/Qi0hV3U3XpoGW5b5IKLxtv2JSK4g3ciaxt10 dKlvkM2Mo3DqI4Jj/2UONV7Vm6Fy8ViX/z6jJx8dtSSf4o+wwSJXE3Lpw72xsy73 tfpqc/SIRgQQEQIABgUCPJlsNwAKCRDtOjnjk2dMQLHxAKDqK2VkXr9x1nwpGxe9 koRt8+JtjgCg+Zr/UYqOIARtu0p5YyWcxcdpa/GIRgQQEQIABgUCPJpH9AAKCRAs bbJ87KtMIKxuAKCNRMIhIAeJyKYnmxhE9r3NC0pekwCeNFlUJ3srLwqkWfz8I3fB 5ZDUA+SIXAQQAQEABgUCOe1THgAKCRAz8FU8F14BOQVBAf4q6b3VOsHx3tvkoE+p pOCJhWeVXdZYY8hF/kLdscIdl9XMANazGtnKpVaki540wdteBxQW1wREttYixGc7 kTrbiEYEEBECAAYFAjgq5qAACgkQNnstYOXbLtrJWQCfW0FT60pXiniou2988Iik VwRRfZQAn3WLmHD2rzbnv7alMqlP/HEn96GTiEYEEBECAAYFAjyZZw0ACgkQtfZN GkrRZbRadwCcCHUFBzyhMk7C90xaba7e+BU9zSwAoPzKZnbhL5nDxRwjZnzbvGA0 +gFNiEYEEBECAAYFAjgrCywACgkQwM9r9d5kYh6+qACffyf5IulmTj2nJBTWDdyI +dBl9XoAoM8ClQ/mos+a1FtzzQeuGc47Kwe7iEYEEBECAAYFAjgqZMYACgkQ1KVN SMW+c1jcRwCglJNF0koNr5LwQ1yR+ziiaKJmEH4AoJPboEhTT6s1RD3S/Qq8OuNl D+oqiEYEEBECAAYFAjgqSdwACgkQ3SDCJgQwZVbZBQCaAw4G2iUltXbBLytrb6Yq 21R/+GkAoOT58dXEIt7TMj6fU0aze5c+s967iEYEEBECAAYFAjyZamMACgkQ7O2h hlqBXB86yACg1Rjy1TaYF2MN9lsdg0LjLw0R5S4AoMUfZdSd2UaOpCYGFJORqFBL Z0RciQCUAwUQPJmFP/bvOLj4Q3BxAQF+YgP4zayJnWfWTmy2CNLGXwlF9gERBhNE qLmhsICzkUZcV/v+vZUowhRmiMIEQhqssSsymvn27Z89dDlv4GQ7Xvq9FbcQmmxZ agS14vUHnY+Z8za2XqloD/qB1OlqwlB7f93DXN8pUQEB7IMfYkcxVDHeF8KF0WXy s3jiAN6+ELSOH4hGBBARAgAGBQI8mh6cAAoJEPyNdnM8hiYPZIcAnA3k21raO2BN NgV7bPmA3asqHUgRAJ9gWOLF0tFKP7eV94Smvhe8g49wDYhGBBARAgAGBQI8mkhs AAoJEH5cypraYkBDcHIAn3m7rVrkU5J29QfUIYW1cPS5fKPFAJ4gae/C0bvj7w7r yKkI/3nS2jzZu4hGBBARAgAGBQI8mYH0AAoJEMl0JfuuS12SXX0AnA6xp1seY+o3 atEg8pGAaBEDC9SfAJ4k+aj2Um6qfEAyNoJEEOc6rO/hXYhGBBIRAgAGBQI9YXsh AAoJEEouP6ZaRCq0aE0An17m1RVs5UQR0D+t3rySmR4OivMUAJ0TEUC1b0NW57sf u+AGjRz1XtasmohGBBARAgAGBQI8rFkHAAoJEEbhbVTZrEgjAD4AoIVKZsLRVijc iv8tW12q/LyVku8hAKCVrQkL+2tekZVm3jiESFZDxpSP7rQuSGFyYWxkIFR2ZWl0 IEFsdmVzdHJhbmQgPGFsdmVzdHJhbmRAY2lzY28uY29tPohGBBARAgAGBQI8mkf7 AAoJECxtsnzsq0wgLMsAoJSizecoJ22KjP4ZZVNbjVNSoEpNAKDzaAIWmczroetX jyC/LzB88kYbD4hLBBARAgALBQI57VdYBAsDAQIACgkQOMj+2+WY0F4BEQCgyBri eNCNJPcW4zOTXS3Qrn7yXZ8AnRFwI7AcmnuLCRxpdbIBegdOtumliQCVAwUQPJmF R/bvOLj4Q3BxAQH6DAP8Dbsy5PabqJCwCHJK+FGMOsDuQjJ/xT/5EyJNoD+qToqA ufi3YXdzHwQiqzRDuk+5IH2C2CTfDQluz0fzVU51Tepg1ifHDpw9CutgtuKIMwtV 2xdVG2zt0HX1EJrYKn+j+2XERuWazpzg0tD5XGSDs3QTmXwFGH9+iEmxnIr8BdWI RgQQEQIABgUCPJpIcAAKCRB+XMqa2mJAQ9IrAJ4uekVx3BAE0QgLhgsLzmprBsRS pACgiBVx+frUbc+OwzatH0Qw4YHQZ5uIRgQQEQIAB
Re: authenticated email
On Wed, Jun 04, 2003 at 09:02:57AM +0300, Jari Arkko wrote:
>
> Without trust roots, webs of trust, or additional
> mailing list daemon features, signed e-mail doesn't
> really add anything, at least not now.
>
> Signed e-mail could help ensure that e-mail
> sent to a list comes from the same person
> as the one who subscribed to the list. But then
> again, the same feature could be implemented
> much simpler by some header which must stay
> constant from the same person and is stripped
> off by the list daemon when forwarding the mail
> to the subscribers.
Signed e-mail is useful for assuring that e-mail message sent at one
point in time is the same as an e-mail message sent earlier. (Not
necessarily just for list mail, but also for person-to-person mail.)
> So, its the same old question once again: how
> do we all enroll ourselves to the same trusted
> root or web of trust?
For the specialized case of preventing SPAM, it's not necessarily
necessary to do the full authenticated e-mail where we know the
identity/passport number/Al Quaeda cell designation of the sender.
(Such things are of interest to John Ashcroft and others of that ilk
pushing "Total Information Awareness", but it's not really needed if
the only requirement is to stop SPAM.)
So imagine a system where if you want to send private e-mail to
someone, your public key figureprint must either be on a list of
acceptable senders, or you must submit some kind of mathematical
evidence that you have spent 5-10 minutes of CPU time crunching on
some particular problem. After you do this, you get added to that
person's "good guys list", unless it turns out that you have sent spam
or something else annoying/abusive, at which point the user can remove
you from the trusted list, and the next time you want to send e-mail
to this person, you have to crunch for another 5-10 minutes of CPU
time.
Yeah, some special provision would be needed for CPU-limited PDA's,
but most PDA's that I've seen don't attempt to talk to the network
directly; they generally go through some kind of mutually trusted
gateway box that could do the CPU crunching for them. (Or you could
argue that since that initial contact simply won't be supported from
by CPU-limited PDA's if they don't have a mutually trusted third party
that can "pay" the hashcash for them.)
The point of this message is not to argue that this is the Right Way
to do things, but to point out that you don't necessarily have to
solve the authenticated e-mail problem ("I invoke PKI; your project is
doomed to long, slow, painful, lingering death") in order to solve the
SPAM problem.
- Ted
Re: authenticated email
Harald Tveit Alvestrand wrote: I thought I'd try this is there any particular disadvantage or centralization of power implied in me signing this message with my PGP key? Is there an IETF PGP keyserver somewhere? Did you store the key securely on the keyserver? Which keyserver? Which port? The particular network I connect to is blocking most ports, so I can't retrieve your public key. On another hand, the same particular network recommends that its users use a particular MUA, which has built-in certs of certain CAs, which allows readers of this email to trust I am who I claim to be, "legally" (as if I showed an ID). If not, is there any particular reason that I shouldn't do this all the time? Will the government of the country you live in allow you to store your public key on a public PGP keyserver? (a particular government was _not_ allowing it as of 1997, and if things have changed since then I'm happy, but the "try and find out" way is high risk for me.) Alex GBU smime.p7s Description: S/MIME Cryptographic Signature
Re: authenticated email
--On tirsdag, juni 03, 2003 16:02:52 -0700 Michael Thomas <[EMAIL PROTECTED]> wrote: It depends on what you mean by signing. Signing a message in and of itself ought not hurt anything modulo software bugs, etc. But the real question is what does the receiving program (MTA, MUA) do with that signature? At the very least it could verify the signature, but then what? If it doesn't verify do you drop it? (transitive trust comes into play, but most likely). Does it do anything beyond that? Let me ask something in return: do you think that just the act of signing mail -- with no trust roots implied -- could help? My sense is that it might in a sow-the-seeds kind of way for some later goodness (it's as you say not a solution). I too would be happy to hear downsides. well... if signing my email would help get rid of the nonconformant mailers on the path that do perverse stuff that breaks signatures, that certainly would be a benefit to the world verifying my own signature failed and here's why: Original: --==1875089384== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Copy: --==1875089384== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The difference matters not at all to anything but a signature verifier. sigh. Harald
Re: Engineering to deal with the social problem of spam
(I really wanted to stop this thread with my previous message, but...) On woensdag, jun 4, 2003, at 02:54 Europe/Amsterdam, Tony Hain wrote: Just adding authentication only solves a very small part of the problem: we can then accurately whitelist known senders. Two points: 1) besides white listing, the approach also provides irrefutable evidence to law enforcement about spam sources. Ok, there's some value in that if we build a good key infrastructure. Wouldn't say "irrefutable" even then, though. What I meant to say: we need more than authentication. A new interpersonal batch communication system certainly sounds like a good idea. The problem with email is that it is incredibly ill-suited for transferring larger files. A new protocol should be able to do much better in this area. However, this doesn't have much to do with spam issues and might make the whole thing much more complex. We can always make it more complex than necessary, but it is pointless to compare the complexity of a new system that does the job with a system that is proven to be open to abuse. SMTP shouldn't be used to transfer binary files. It leads to all kinds of problems: clogged mailboxes, wasted bandwidth (base64, aargghh!), you name it. A better batch interpersonal communication system would be able to send the message, but then negotiate what to do with the attachment. From some people you may want to always immediately receive the attachment, from others you may want to read the message first and then decide whether to inititate the transfer of the attachment. This would be very cool except that it breaks current email systems at a fairly fundamental level. Adding authentication on the other hand, can be done in a way that may not be compatible with current ESTMP, but it does (or at least: could) fit into the current email architecture without too much trouble. The trouble is that on the internet, you can go from house to house and try to break locks and nobody will stop you. In the real world, you wouldn't be able to do that for very long. Adopt draft-hain-ipv6-pi* as the standard addressing plan, provide automated intrusion detection reporting, and Internet prowlers wouldn't be able to attack for very long either. Only if someone cares enough to go to the place where the prowler deploys his activities. There was a time when this was a reasonable assumption; but this time is now in the past. So let's show some adaptability of our own and plug those SMTP holes. Or simply leave SMTP to the spammers and move on. Fine by me. Why look at individual messages? How much non-bulk mail can someone possibly need to send? 10 messages per hour? 100? 1000? @ 5kB/message on a 10MB/sec link, 2k/sec. And how exactly would those messages be "non-bulk"? I mean, I type fast, but even then it takes a second or so to even find the recipients for a message. That's why it's important to look at ALL mail rather than just copies of one message. Spammers by now know how to make messages look different even though they're essentially identical. Exactly how would you coorelate email across multiple accounts, on multiple service providers? We push this back to the source MTA. Then if the source MTA does a bad job, we revoke the MTA's "not-a-spammer" accreditation so only messages with whitelisted senders can get through. Alternatively, we can build a serial number system. An MTA must then add a serial number that starts from 0 every day or every week to every message. This way everyone who receives a message from this MTA knows how many messages the MTA has already transmitted this period. Obviously spammers will fake the serial number so we also build a system that makes it possible to check if a serial number wasn't used more than once afterwards. This shouldn't be much of a problem for spammers if they can set up a new MTA in five minutes, but if they (for instance) have to get three people in good standing to sign the new MTA's key in order to be able to start a new spam run, then it gets more troublesome for them. Someone's "home MTA" sould be able to simply rate limit the number of messages an individual user gets to inject into the global email distribution system. Then all we need is a system to differentiate between trusted MTAs and rogue ones run by spammers. Why would a spammer limit themselves to a single MTA, or account. Run VMware on a laptop, and there could easliy be 10 parallel rate-limited sessions going on. If the rates are low enough, each virtual system could automatically log into another account on another MTA, then come back when the timer goes off. At a limit of 1000 messages per hour per account, they need 1 account-hours to send out 10 million spam messages. Assuming it takes 64 hours (on the weekend) to get an account yanked for spamming that's 160 accounts. This is a good start. Add some additional stuff such as limiting the number of messages per hour based on the number of
Re: authenticated email
Michael Thomas wrote: It depends on what you mean by signing. Signing a message in and of itself ought not hurt anything modulo software bugs, etc. But the real question is what does the receiving program (MTA, MUA) do with that signature? At the very least it could verify the signature, but then what? If it doesn't verify do you drop it? (transitive trust comes into play, but most likely). Does it do anything beyond that? Let me ask something in return: do you think that just the act of signing mail -- with no trust roots implied -- could help? My sense is that it might in a sow-the-seeds kind of way for some later goodness (it's as you say not a solution). I too would be happy to hear downsides. Without trust roots, webs of trust, or additional mailing list daemon features, signed e-mail doesn't really add anything, at least not now. Signed e-mail could help ensure that e-mail sent to a list comes from the same person as the one who subscribed to the list. But then again, the same feature could be implemented much simpler by some header which must stay constant from the same person and is stripped off by the list daemon when forwarding the mail to the subscribers. More seriously, ensuring the sender's address is right is useless IMHO unless there's a policy for letting people to sign-up to a list. Spammers could get a new address and generate a key pair, sign up using them, send spam, and repeat with another address and key. So, its the same old question once again: how do we all enroll ourselves to the same trusted root or web of trust? Should the next PGP key signing party be held in the plenary, for everyone? Or maybe Harald stands in the IETF reception desk to look at people's passports and certifies keys? Hmm... maybe we could make PGP key mandatory in registration, and have the secretariat form a web of trust. At least we could trace every key to a credit card number... sounds pretty good but this wouldn't deal with the folks who don't come to the meetings. Maybe we could turn on mandatory PGP signing for all list e-mail for a year, and at the end of the year make a web of trust for the folks who sent e-mail that year. That wouldn't be perfect, but it would sure reduce the size of queue in front of Harald for the passport check ;-) --Jari
Re: IETF Standards Process
--On tirsdag, juni 03, 2003 17:28:55 -0400 Dean Anderson <[EMAIL PROTECTED]> wrote: You indicated that my criticism was incorrect regarding Mr. Klensin's understanding of the standards process in regards to the description of the current SMTP Standard. So, now I am confused, and would like to learn how to correctly evalute the status of IETF Standards. The following question seems simple enough: "What is the current standard level RFC describing the SMTP protocol?" formally, we have two standards-track specifications for the SMTP protocol. RFC 821 at Standard, and RFC 2821 at Proposed Standard. The intent is, I believe, that any RFC 2821 client will be RFC 821 compatible, but implementors who care should state which specification they claim conformance to. The "delete after 24 months" clause of RFC 2026 is inoperative in practice; the oldest Proposed Standard is RFC 698, published in 1975. I have no explanation for the error in RFC 3300; the RFCs in question were published by the RFC Editor without IETF review. The first such document to refer to RFC 2821 was RFC 2800. Harald
RE: This IETF discussion list
Michel Py writes: > Added to the pro-troll and pro-spammer list: [] Can we pretty please retire the Catherine Wheels from this list? Thank you. Mike
RE: This IETF discussion list
Added to the pro-troll and pro-spammer list: Richard Perlman. Michel. -Original Message- From: Richard Perlman [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 6:53 PM To: 'IETF Discussion' Cc: [EMAIL PROTECTED] Subject: Re: This IETF discussion list All: I have been loosely tracking the SPAM discussion and really had nothing significant to add. However, a related posting did catch my attention and interest, enough so to warrant a response. While I certainly am not interested in taking sides on the personal accusations that have been seen recently, I do have serious concerns about the message quoted below. I personally detest the daily deluge of unwanted unsolicited e-mails I receive. However, I would be even more upset to find that one's belief or support for or against any topic should be the criteria by which their contributions were judged. As despicable as I may find the concepts, opinions and thoughts of others, a world in which the expression of only those ideas that I found acceptable would be far worse. Having said that, I do want to be clear, that while I think there needs to be freedom for expression of ideas, that expression must be done in a way that encourages discussion and values the participation of everyone. There is no room for personal remarks and attacks in a conversation of ideas. Richard On 6/3/03 15:00, "Dean Anderson" <[EMAIL PROTECTED]> quoted: > == > Date: Fri, 30 May 2003 02:09:25 +0200 > From: "Tomson Eric (Yahoo.fr)" <[EMAIL PROTECTED]> > To: 'Eric A. Hall' <[EMAIL PROTECTED]>, 'John Stracke' > <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: RE: spam > > Guys, > > Dean Anderson obviously supports and defends SPAM. > No further conversation with him could lead to anything constructive. > Stop feeding the Troll, now. > > E.T.
Re: This IETF discussion list
All: I have been loosely tracking the SPAM discussion and really had nothing significant to add. However, a related posting did catch my attention and interest, enough so to warrant a response. While I certainly am not interested in taking sides on the personal accusations that have been seen recently, I do have serious concerns about the message quoted below. I personally detest the daily deluge of unwanted unsolicited e-mails I receive. However, I would be even more upset to find that one's belief or support for or against any topic should be the criteria by which their contributions were judged. As despicable as I may find the concepts, opinions and thoughts of others, a world in which the expression of only those ideas that I found acceptable would be far worse. Having said that, I do want to be clear, that while I think there needs to be freedom for expression of ideas, that expression must be done in a way that encourages discussion and values the participation of everyone. There is no room for personal remarks and attacks in a conversation of ideas. Richard On 6/3/03 15:00, "Dean Anderson" <[EMAIL PROTECTED]> quoted: > == > Date: Fri, 30 May 2003 02:09:25 +0200 > From: "Tomson Eric (Yahoo.fr)" <[EMAIL PROTECTED]> > To: 'Eric A. Hall' <[EMAIL PROTECTED]>, 'John Stracke' > <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: RE: spam > > Guys, > > Dean Anderson obviously supports and defends SPAM. > No further conversation with him could lead to anything constructive. > Stop feeding the Troll, now. > > E.T.
RE: Engineering to deal with the social problem of spam
Dave Crocker wrote: > ... > This does not mean we should do nothing. Nor does it mean > that there should be no technical interventions. > > It *does* mean that we need to treat this as an incremental > systems change process. > > It *does* mean that we will need multiple types of changes, > not just one cure-all. > > It *does* mean that we should approach those changes very > cautiously, even experimentally. I am with you up to here, with the comment that any modification to production services need to be approached incrementally, but new services can be radical as long as they are deployed in parallel. > > The place to start is with a modest, objective, > operationalizable definition of the thing we all agree needs > to be handled differently. We agree with the wording of this, but it looks like at this point we disagree about what should be changed. > So, let's not worry about the > all-encompassing definition of spam. > ... > In other words, the detail of the content > is irrelevant to me. It does not even need to be > soliciting.) > I agree completely with these points. At this point your thoughts appear to drop into the trap of trying to engineer a solution to the social problem, even though earlier you noted we don't know how to engineer solutions to complex social problems. > ... > For that matter, the number of addressees per message might > not be a useful attribute, as marketeers have become good at > tailoring content to individual recipients, thereby producing > one addressee per message. So "bulk" requires considering > behavior across multiple postings. Oh boy... And if they spread the individual messages across multiple relays, using multiple accounts, there is no chance to correlate postings. This shows that even by your own account of ignoring content, there is no technical way to stop even the simple case of unsolicited bulk mail. > > And that's why this is a research topic, no matter how > essential it is to to engineer some mechanisms sooner rather > than latter. Let's do the engineering and deployment, and > let's do it quickly, but let's appreciate that it is really research. We agree that engineering automated solutions to social problems is a research topic, and the IETF is not the place to do that work. Engineering tools that are useful to existing social management agencies is not research and something that the IETF can take on. Deployment of experimental technologies is necessary, and something that should begin ASAP. IMHO where we need to start is agreeing that the greater goal is reduction of spam, that we don't know of any way to automate the identification of billions of independent individual value decisions, that trying to do so at this point is a waste of time, and that existing social management agencies need tools to deal with the issue. I would like to see the outcome of a bof be identification of an approach to globally verifiable authenticated email. I have no doubt there will be many gaps in our current tool set (starting with a deployable PKI), and a truck load of operational guidelines to develop. This is something tangible we can do without extended research. If the research community comes up with a breakthrough and figures out another way to kill off spammers, authenticated email will still be useful as a replacement for the current legal requirements for fax. Tony
RE: The utilitiy of IP is at stake here
Anthony Atkielski wrote: > ... > I've always wondered why signatures of ink on paper are > binding, whereas digital signatures are not, even though > digital signatures are literally billions or trillions of > times more difficult to forge. > > E-mail can be easily forged, but then again, so can a fax. > So what's so special about fax? I really don't know, maybe one of the armature lawyers will enlighten us. My perception is that it is derived from the physical paper evidence, and that forging email is so simple for Joe-sixpack that everyone knows not to trust it. Tony
RE: Engineering to deal with the social problem of spam
Iljitsch van Beijnum wrote: > Just adding authentication only solves a very small part of the > problem: we can then accurately whitelist known senders. Two points: 1) besides white listing, the approach also provides irrefutable evidence to law enforcement about spam sources. 2) it is clear from the related threads that many would rather continue the lively exchange debating nirvana, rather than tackle the small parts of the problem that are technically achievable. > > A new interpersonal batch communication system certainly > sounds like a > good idea. The problem with email is that it is incredibly ill-suited > for transferring larger files. A new protocol should be able > to do much > better in this area. However, this doesn't have much to do with spam > issues and might make the whole thing much more complex. We can always make it more complex than necessary, but it is pointless to compare the complexity of a new system that does the job with a system that is proven to be open to abuse. > > > No one believes that a house lock keeps out all intruders, > and indeed > > some do get in. But we *do* believe that house locks reduce > the threat > > to a socially acceptable level. > > The trouble is that on the internet, you can go from house to > house and > try to break locks and nobody will stop you. In the real world, you > wouldn't be able to do that for very long. Adopt draft-hain-ipv6-pi* as the standard addressing plan, provide automated intrusion detection reporting, and Internet prowlers wouldn't be able to attack for very long either. > So let's show some adaptability of our own and plug those SMTP holes. Or simply leave SMTP to the spammers and move on. > Why look at individual messages? How much non-bulk mail can someone > possibly need to send? 10 messages per hour? 100? 1000? @ 5kB/message on a 10MB/sec link, 2k/sec. > That's why it's important to look at ALL mail rather than just copies > of one message. Spammers by now know how to make messages look > different even though they're essentially identical. Exactly how would you coorelate email across multiple accounts, on multiple service providers? > > Someone's "home MTA" sould be able to simply rate limit the number of > messages an individual user gets to inject into the global email > distribution system. Then all we need is a system to differentiate > between trusted MTAs and rogue ones run by spammers. Why would a spammer limit themselves to a single MTA, or account. Run VMware on a laptop, and there could easliy be 10 parallel rate-limited sessions going on. If the rates are low enough, each virtual system could automatically log into another account on another MTA, then come back when the timer goes off. Tony
Re: authenticated email
I have tried both s/mime and pgp, well in fact still trying to use pgp. The main problem is an implementation problem, where a bad and popular version of Outlook was crashing when trying to verify the signature. Now it all comes down to a global PKI, be it SSL/TLS or PGP. PGP has got it running at an individual user level with the www.keyservers.net but for TLS NO CA will deliver a certificate that can sign other certificates (corporate e-mail certificates). I think there are some attempt to do that... If you look back on this list you will see a thread called GLOBAL PKI where there was a lot of discussion at the time... For spamming having signed e-mail is good as you can trace back (traceability). But are you responsible when a virus on your computer sends signed e-mail with a virus attachment. At a SPAM meeting before INET2002 a company talked about certifying advert Well all the options are open, but going to have a mainstream digital signature is the goal... Cheers Franck On Wed, 2003-06-04 at 09:13, Harald Tveit Alvestrand wrote: I thought I'd try this is there any particular disadvantage or centralization of power implied in me signing this message with my PGP key? If not, is there any particular reason that I shouldn't do this all the time? It's not a solution, but is there a downside? Harald Alvestrand, wondering. -- Franck Martin <[EMAIL PROTECTED]> SOPAC
Re: authenticated email
Harald Tveit Alvestrand writes: > > > --On tirsdag, juni 03, 2003 09:20:24 -0700 Michael Thomas <[EMAIL PROTECTED]> > wrote: > > > I, like you, suspect that authenticated email may > > be helpful in the spam wars, but this must not be > > viewed in isolation. "Authentication" begs the > > question of identity, trust in assertion, > > ownership of identity, and the motivation and > > foibles of third parties who would likely be > > needed to scale this to anything that would be > > useful. > > > > In particular, the latter is almost without > > exception a "be careful for what you wish for" > > situation. Centralization of power for naming and > > thus participation would be a very convenient tool > > to exclude undesirables. Today that's spammers, > > but where are the checks and balances? What > > prevents less worthy causes? How do you prevent an > > unreasonable accrual of power made real by virtue > > of being the path of least resistance for the > > great unwashed masses? > > > > Unless these issues -- and many more -- can be > > finessed, the cure might be worse than the > > disease. > > I thought I'd try this > > is there any particular disadvantage or centralization of power implied in > me signing this message with my PGP key? > > If not, is there any particular reason that I shouldn't do this all the > time? > > It's not a solution, but is there a downside? It depends on what you mean by signing. Signing a message in and of itself ought not hurt anything modulo software bugs, etc. But the real question is what does the receiving program (MTA, MUA) do with that signature? At the very least it could verify the signature, but then what? If it doesn't verify do you drop it? (transitive trust comes into play, but most likely). Does it do anything beyond that? Let me ask something in return: do you think that just the act of signing mail -- with no trust roots implied -- could help? My sense is that it might in a sow-the-seeds kind of way for some later goodness (it's as you say not a solution). I too would be happy to hear downsides. Mike
Re: authenticated email
On Tue, Jun 03, 2003 at 11:13:24PM +0200, [EMAIL PROTECTED] said: [snip] > >Unless these issues -- and many more -- can be > >finessed, the cure might be worse than the > >disease. > > I thought I'd try this > > is there any particular disadvantage or centralization of power implied in > me signing this message with my PGP key? not unless you consider the network of keyservers unduly centralized ... > If not, is there any particular reason that I shouldn't do this all the > time? A small number of mail client/PGP combinations may not interoperate correctly with your particular mail client/PGP combination. However, that's certainly no different (and considerably less widespread) than Outlook or other clients sending all mail as HTML, which interoperates poorly with text-only clients. (dead horse there, I know) > It's not a solution, but is there a downside? None that I have seen yet (except I'm realizing that either my passphrase is too long, or the time period for which mutt caches it is too short). I'm sure others will have different opinions though. Also, the debate between PGP/MIME and the older plaintext signatures is a well-worn one. > Harald Alvestrand, wondering. -- Scott Francis || darkuncle (at) darkuncle (dot) net illum oportet crescere me autem minui pgp0.pgp Description: PGP signature
Re: This IETF discussion list
This message seems to be a violation of the IETF Code of Conduct (RFC 3184) sections 2.1 and 2.2: 1. IETF participants extend respect and courtesy to their colleagues at all times. IETF participants come from diverse origins and backgrounds and are equipped with multiple capabilities and ideals. Regardless of these individual differences, participants treat their colleagues with respect as persons--especially when it is difficult to agree with them. Seeing from another's point of view is often revealing, even when it fails to be compelling. 2. IETF participants develop and test ideas impartially, without finding fault with the colleague proposing the idea. We dispute ideas by using reasoned argument, rather than through intimidation or ad hominem attack. Or, said in a somewhat more IETF-like way: "Reduce the heat and increase the light" It is clearly not unreasonable to challenge someones claims, nor respectfully challenge their anecdotal experiences, but intimidation and ad hominem personal attacks are clearly inappropriate. I ask the IETF Chair to take the appropriate action. Dean Anderson President, Av8 Internet, Inc == Date: Fri, 30 May 2003 02:09:25 +0200 From: "Tomson Eric (Yahoo.fr)" <[EMAIL PROTECTED]> To: 'Eric A. Hall' <[EMAIL PROTECTED]>, 'John Stracke' <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: RE: spam Guys, Dean Anderson obviously supports and defends SPAM. No further conversation with him could lead to anything constructive. Stop feeding the Troll, now. E.T. On Sun, 1 Jun 2003, Tomson Eric (Yahoo.fr) wrote: > By example, the more messages from A*** A*** I read, the more I think he is > making statements of his own, without verification, without proof, without > experience... > > Maybe this is due to a low technical knowledge? Or to a lack of valuable, > proven information? (No offense. Just wondering...) > > Also remember J*** F*** and all his IPv8, IPv16,... stuff! Do such people > just troll "for the pleasure", or are they convinced of what they state? > > I find it amusing that we discuss about SPAM, while we are victims of a kind > of spamming! We are not even able to properly filter this list, and we think > about preventing SPAM worlwide! > > Back to my first question. I don't say I know the answer. I don't say I have > a solution. I'm just thinking, and sharing my thoughts with you all. > > Anyway, it must be difficult to be this list's moderator! :-/ > > > >
IETF Standards Process
You indicated that my criticism was incorrect regarding Mr. Klensin's understanding of the standards process in regards to the description of the current SMTP Standard. So, now I am confused, and would like to learn how to correctly evalute the status of IETF Standards. The following question seems simple enough: "What is the current standard level RFC describing the SMTP protocol?" I see that RFC Index lists RFC 821 as being obsoleted by RFC 2821. However, RFC 2821 status is "Proposed Standard", which is not a standard-level RFC, according to the Standards Process documented in RFC 2026. Indeed, RFC 2821 was dated April 2001. Section 6.2 of RFC 2026 indicates: When a standards-track specification has not reached the Internet Standard level but has remained at the same maturity level for twenty-four (24) months, and every twelve (12) months thereafter until the status is changed, the IESG shall review the viability of the standardization effort responsible for that specification and the usefulness of the technology. Following each such review, the IESG shall approve termination or continuation of the development effort, at the same time the IESG shall decide to maintain the specification at the same maturity level or to move it to Historic status. This decision shall be communicated to the IETF by electronic mail to the IETF Announce mailing list to allow the Internet community an opportunity to comment. This provision is not intended to threaten a legitimate and active Working Group effort, but rather to provide an administrative mechanism for terminating a moribund effort. I can find no reference that RFC2821 is a Standard, and it would seem that it has remained at the same maturity level for 24 months or longer. Thus, it seems to be appropriate that the IESG should review the viability of the standardization effort, and decide if the effort should be terminted or continued. I also see that I am not the first to criticize the RFC 2821 effort (http://cr.yp.to/smtp/klensin.html I see that RFC 3300 indicates that RFC 821 is currently listed at STD 10. How could RFC 821 be obsolete if it is STD 10? Is this an error by the RFC editor in the RFC Index? I also note that RFC 3300 indicates a status change on RFC 2821 to "proposed standard" by use of an asterisk. However the previous verions (RFC 3000) indicates that RFC 2821 was in state "proposed standard" then too. There seems to be no status change. Is this an error? What was the status change indicated in RFC 3300? So, does that mean that I am wrong that RFC 821/STD 10 is the current standard for SMTP? It seems to me that RFC 2026 supports my view, that the current SMTP Standard is RFC 821, though there are inconsistencies in the IETF process documentation that might suggest or lead one to conclude otherwise. I note that similar issues appear to exist with RFC 2554, but that is it dated March 1999. If these RFCs are not in fact Standard Level RFC's, it is inappropriate for persons associated with the IETF to describe them as such, and therefore this seems to be a violation of section 4 of RFC 3184, Code of Conduct, for having not read the RFCs. On the other hand, perhaps I have missed something or otherwise misunderstood those RFCs, and am myself in violation of section 4. I seek guidance on this issue. Thank you for your attention. Dean Anderson President, Av8 Internet, Inc
Re: authenticated email
--On tirsdag, juni 03, 2003 09:20:24 -0700 Michael Thomas <[EMAIL PROTECTED]> wrote: I, like you, suspect that authenticated email may be helpful in the spam wars, but this must not be viewed in isolation. "Authentication" begs the question of identity, trust in assertion, ownership of identity, and the motivation and foibles of third parties who would likely be needed to scale this to anything that would be useful. In particular, the latter is almost without exception a "be careful for what you wish for" situation. Centralization of power for naming and thus participation would be a very convenient tool to exclude undesirables. Today that's spammers, but where are the checks and balances? What prevents less worthy causes? How do you prevent an unreasonable accrual of power made real by virtue of being the path of least resistance for the great unwashed masses? Unless these issues -- and many more -- can be finessed, the cure might be worse than the disease. I thought I'd try this is there any particular disadvantage or centralization of power implied in me signing this message with my PGP key? If not, is there any particular reason that I shouldn't do this all the time? It's not a solution, but is there a downside? Harald Alvestrand, wondering. pgp0.pgp Description: PGP signature
Re: This IETF discussion list
--On søndag, juni 01, 2003 19:43:04 +0200 "Tomson Eric (Yahoo.fr)" <[EMAIL PROTECTED]> wrote: By example, the more messages from A*** A*** I read, the more I think he is making statements of his own, without verification, without proof, without experience... Maybe this is due to a low technical knowledge? Or to a lack of valuable, proven information? (No offense. Just wondering...) Also remember J*** F*** and all his IPv8, IPv16,... stuff! Do such people just troll "for the pleasure", or are they convinced of what they state? I find it amusing that we discuss about SPAM, while we are victims of a kind of spamming! We are not even able to properly filter this list, and we think about preventing SPAM worlwide! Back to my first question. I don't say I know the answer. I don't say I have a solution. I'm just thinking, and sharing my thoughts with you all. note that there's a document currently in Last Call that might be relevant: The IESG has received a request to consider A Practice for Revoking Posting Rights to IETF mailing lists as a BCP. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2003-6-13. Not much comment here so far. Anyway, it must be difficult to be this list's moderator! :-/ the current moderator thinks that it's a job that needs a little more attention than he's currently giving it, and considering alternatives :-)
Re: Engineering to deal with the social problem of spam
On Tue, 03 Jun 2003 18:06:19 +0200, Iljitsch van Beijnum said: > all the time, or people will simply ignore the naive validator. This > should work especially well if validation depends on some real-life > info: having to get a new (street) address or drivers license to be > able to do a spam run should have a nice discouraging effect. Street address validated how? It's the rare ISP that double-checks an account by snail-mailing information or calling the listed user's telephone number to confirm. Not that it would be a bad thing if all ISP's did this, but all it takes is a few that don't, and the scheme falls apart... pgp0.pgp Description: PGP signature
authenticated email
Tony Hain writes: > Are there other reasons for having authenticated, time-stamped email? I > am sure there are many, but the first I would like to see is the end to > the designation that a fax is acceptable legal evidence, while email is > not. Will an 'anti-spam' focused IETF wg provide that? Maybe by > accident, but not likely. Will an 'authenticated email' wg produce an > end to spam? Not initially, but like the lock, the result is a > technology that enables the social management sphere to accomplish the > greater goal. I, like you, suspect that authenticated email may be helpful in the spam wars, but this must not be viewed in isolation. "Authentication" begs the question of identity, trust in assertion, ownership of identity, and the motivation and foibles of third parties who would likely be needed to scale this to anything that would be useful. In particular, the latter is almost without exception a "be careful for what you wish for" situation. Centralization of power for naming and thus participation would be a very convenient tool to exclude undesirables. Today that's spammers, but where are the checks and balances? What prevents less worthy causes? How do you prevent an unreasonable accrual of power made real by virtue of being the path of least resistance for the great unwashed masses? Unless these issues -- and many more -- can be finessed, the cure might be worse than the disease. Mike
Re: automagically whitelisting legit mailing lists
on 6/3/2003 10:07 AM Dave Aronson wrote: > Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: > >> One way would be solicited == whitelisted. Remember that this is only >> necessary for bulk mail. So everyone would need to create a >> whitelist of all the mailinglists and newsletters they're subscribed >> to. > > This could be eased somewhat with something I was trying to get at > earlier. This is separate from the idea of fixing or replacing SMTP, > or other spamfighting, but what I envision is some standard format of > data about a mailing list. (MLML, for Mailing List Markup Language?) > Upon reading this in an email or on the web, the user can take some > sort of action (click, reply, etc.), whereby he would be subscribed, > and his MUA would whitelist the address the email would come from (or > some other such tag, but usually the From addy so as to enable PGP-type > authentication). Something like: First point is that whitelisting should be one of the optional "locks" which are enabled by architecture, rather than being core features of any service. Whitelists don't work for everybody (customer service desks, for example) so they need to be optional, and there are probably going to be a variety of whitelisting "applications" (such as what you describe in your detail) that embedding any of them would make it difficult to develop alternative whitelisting applications. For these kinds of reasons, it would be best to provide architecture (in particular, providing authenticated identity and end-to-end option encapsulation), and then people could use whatever mechanisms they want (including hashcash, e-postage, whitelist negotiation, whatever) within their own administrative space according to whatever works for them. Whitelisting and mailing-list automation services would be two different applications, I think, although they should be able to communicate with each other for the kind of reasons you cite. Anyway, the overall point is that we should separate the applications from the message-transfer network architecture and develop them in parallel, making sure that the architecture can provide what the applications need for successful deployment. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Engineering to deal with the social problem of spam
Ok, my last message on the subject on this list (at least for a while). On dinsdag, jun 3, 2003, at 16:56 Europe/Amsterdam, Dave Aronson wrote: Someone's "home MTA" sould be able to simply rate limit the number of messages an individual user gets to inject into the global email distribution system. Then all we need is a system to differentiate between trusted MTAs and rogue ones run by spammers. Then we're back to Square One (okay, maybe Three) with blacklists and whitelists. Obviously black/whitelisting the MTAs you know is a good start. The challenge is doing something useful when you first encounter a new MTA. This can be done by asking such an unknown MTA to present a certificate that is signed by one or more people or organizations you trust. This will make getting a new bona fide MTA up and running more difficult than it is now, but not to an unreasonable degree, IMO. Spammers on the other hand, will be unable to grab an address and start spamming immediately: they'll have to trick someone into validating their MTA. I'm sure they'll succeed in this from time to time, but not all the time, or people will simply ignore the naive validator. This should work especially well if validation depends on some real-life info: having to get a new (street) address or drivers license to be able to do a spam run should have a nice discouraging effect.
Re: Mailing list or bust (was Spam, nasty exchanges, and the like)
> Does anyone care to start a mailing list for > technical proposals? the ASRG list already exists and is suitable for this purpose, and many technical proposals have already been floated there. what we're doing here is educating people who can't be bothered to join that list. and I agree we've done enough of it here.
automagically whitelisting legit mailing lists
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: > One way would be solicited == whitelisted. Remember that this is only > necessary for bulk mail. So everyone would need to create a whitelist > of all the mailinglists and newsletters they're subscribed to. This could be eased somewhat with something I was trying to get at earlier. This is separate from the idea of fixing or replacing SMTP, or other spamfighting, but what I envision is some standard format of data about a mailing list. (MLML, for Mailing List Markup Language?) Upon reading this in an email or on the web, the user can take some sort of action (click, reply, etc.), whereby he would be subscribed, and his MUA would whitelist the address the email would come from (or some other such tag, but usually the From addy so as to enable PGP-type authentication). Something like: My mailing list of occasional jokes, stories, and other alleged humor. Ideally, this would set off a confirmation process. This introduces the possibility of whitelisting the addy that the confirmation request will come from, but if we establish a standard for transforming the listname and host to the various admin addies needed, those can be made optional. For instance, in the example above, I could have added owner="[EMAIL PROTECTED]", confirm="[EMAIL PROTECTED]", or both, or let them default to [EMAIL PROTECTED] and [EMAIL PROTECTED] Similarly, there could be explicit or implicit URLs for subscription control (defaulting to something like "http://www.lists.example.com/ddd-control/";, and including possibly that there are none for this list), and a standardized set of commands usable via email, and possibly a standard set of web-based controls. Of course, we would quickly see spam in this format, but that's a whole different question. A brief google doesn't turn up anything obviously relevant; anybody know of any work having been done in this area? -- David J. Aronson, Unemployed Software Engineer near Washington DC See http://destined.to/program/ for online resume, and other info
Re: Engineering to deal with the social problem of spam
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: > Someone's "home MTA" sould be able to simply rate limit the number > of messages an individual user gets to inject into the global email > distribution system. Then all we need is a system to differentiate > between trusted MTAs and rogue ones run by spammers. Then we're back to Square One (okay, maybe Three) with blacklists and whitelists. Not that throttling is itself a bad thing... I'd like to throttle some spammers ;-> -- David J. Aronson, Unemployed Software Engineer near Washington DC See http://destined.to/program/ for online resume, and other info
Re: Engineering to deal with the social problem of spam
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: > The trouble is that on the internet, you can go from house to house > and try to break locks and nobody will stop you. Actually, sometimes they will, or at least try to. Port scans can be detected, both inbound and out, and Things Can Be Done -- David J. Aronson, Unemployed Software Engineer near Washington DC See http://destined.to/program/ for online resume, and other info
Internet Voting and user participation systems - Research questionfrom Baptista
Hi all: I'm doing research on what is available with respect to web based (or email) interfaces that support political participation at the grass roots level (bottom up). This includes voting and organizational systems or user based communities. Please email me back private - especially if your getting this message in a newsgroup so i don't inadvertently miss it. cheers joe baptista Joe Baptista - only at www.baptista.god "Those are mercenaries. Most probably they will be treated as mercenaries, hirelings and as war criminals. ... For sure, international law does not apply to those" ... Muhammed Saeed al-Sahaf former Iraqi Information Minister
Re: Last warning: Please turn down the volume
Harald writes: > Since then, you have contributed approximately 40 > more messages to the list, or around 8 messages per > day, contributing more than a sixth of the > total list traffic in that interval. So? Try this: Count all the personal attacks and irrelevant posts on this list in the last 30 days, and rank participants by those. I think you may be surprised at the results. > This is the final (and public) warning. > Stop shouting. Actually, looking at your previous post, which was little more than a child's sandbox tirade against two other people on the list, I found it to be a superlative example of the pot calling the kettle black--and it did make me smile for that reason. It also further reinforced my impression that this list is a waste of time, because of the many kiddies who just cannot refrain from bickering, whining, censoring, and attacking each other, just as they seem to do on practically every other list, forum, and newsgroup on the Net. And when I see moderators jumping into the fray like overzealous and woefully underqualified kindergarten teachers, I pretty much am tempted to write the whole list off. So do what you want. I'm not profiting from this list, and it's pretty clear that a lot of people here aren't grown up enough to profit from my own contributions, so it makes no difference to me. Incidentally, with lists like this so disproportionately populated by angry young boys and their mental equivalents, it's easy to see why spammers are doing so well. I wonder sometimes why I waste my breath; but I suppose I'm an incurable optimist at heart.
