At 02:18 PM 4/13/2008, Barry Shein wrote:

Is it abuse@domain or spam@domain or support@domain or postmaster@domain (very commonly used) or ???@domain. Who cares? But let's pick ONE, stuff it in an RFC or BCP and try to get each other to conform to it.

abuse@domain is *already* specified (in RFC 2142). Granted, separating reports of email abuse from those for other forms of abuse might be useful for large providers, but since we can't even get many domains even to set up the already-specified abuse@ address, much less read the mail we send to it, I'm not convinced that it would help. OTOH, many email providers seem to think it's my job to know what their internal organization is and re-route email to some spam-specific email reporting address. While that is just rude and ignorant behavior in my book, at least having a single standardized address would be an improvement...

of abuse might be useful for large providers, but since we can't even get many domains even to set up the already-specified abuse@ address, much less read the mail we send to it,

When someone like AOL offloads their user complaints of spams to all the abuse@ addresses instead of verifying that they actually are spams before sending off complaints, is it any surprise that everyone else is refusing to do their jobs for them? The reason abuse@ addresses are useless is because what is being sent to them is useless. George Roettger Netlink Services

On Sun, 13 Apr 2008, Geo. wrote:

...

of abuse might be useful for large providers, but since we can't even get many domains even to set up the already-specified abuse@ address, much less read the mail we send to it,

When someone like AOL offloads their user complaints of spams to all the abuse@ addresses instead of verifying that they actually are spams before sending off complaints, is it any surprise that everyone else is refusing to do their jobs for them?

The reason abuse@ addresses are useless is because what is being sent to them is useless.

As one that works for a company that makes full use of complaints sent to it, abuse@ addresses are not useless, far from it. Please don't get the idea that because some think they're useless, it therefore is universal. We also get 100s of AOL feedbacks a day, which are filtered separately. Also not useless. And we've also reported incidents to other companies' abuse functions, and had them be resolved same-day because of it. Also, far from useless. How about if you're not actively in an abuse function, you hold off on declaring the function useless, cause the meme could catch on that it is, even if it's not, and I've yet to see an automated filtering/blocking system fully replace or completely obsolete a good trained network operator who understands what is and is not abuse on the network. -Dave D

1. They are not complaints as such. They are what AOL users click report spam on 2. They are sent in a standard format - http://www.mipassoc.org/arf/ - and if you weed out the obvious (separate forwarding traffic out through another IP, and ditto for bounce traffic), then you will find that - for actual ISPs - actual spam reports will far outweigh the amount of misclicked reports. 3. As I said, its in ARF and that's machine parseable and you can get stats from it. On Mon, Apr 14, 2008 at 2:11 AM, Geo. <geoincidents@nls.net> wrote:

When someone like AOL offloads their user complaints of spams to all the abuse@ addresses instead of verifying that they actually are spams before sending off complaints, is it any surprise that everyone else is refusing to do their jobs for them?

The reason abuse@ addresses are useless is because what is being sent to them is useless.

On April 13, 2008 at 14:24 jgreco@ns.sol.net (Joe Greco) wrote:

I would have thought it was obvious, but to see this sort of enlightened ignorance(*) suggests that it isn't: The current methods of spam filtering require a certain level of opaqueness.

Indeed, that must be the problem. But then you proceed to suggest:

So, on one hand, we have the "filtering by heuristics," which require a level of opaqueness, because if you respond "567 BODY contained www.sex.com, mail blocked" to their mail, you have given the spammer feedback to get around the spam.

Giving the spammer feedback? In the first place, I think s/he/it knows what domain they're using if they're following bounces at all. Perhaps they have to guess among whether it was the sender, body string, sending MTA, but really that's about it and given one of those four often being randomly generated (sender) and another (sender MTA) deducible by seeing if multiple sources were blocked on the same email...my arithmetic says you're down to about two plus or minus. But even that is naive since spammers of the sort anyone should bother worrying about use massive bot armies numbering O(million) and generally, and of necessity, use fire and forget sending techniques. Perhaps you have no conception of the amount of spam the major offenders send out. It's on the order of 100B/day, at least. That's why you and your aunt bessie and all the people on this list get the same exact spam. Because they're being sent out in the hundreds of billions. Per day. Now, what exactly do you base your interesting theory that spammers analyze return codes to improve their techniques for sending through your own specific (not general) mail blocks? Sure they do some bayesian scrambling and so forth but that's general and will work on zillions of sites running spamassassin or similar so that's worthwhile to them. But what, exactly, do you base your interesting theory that if a site returned "567 BODY contained www.sex.com" that spammers in general and such that it's worthy of concern would use this information to tune their efforts? This is not an existence proof, one example is not sufficient, it has to be evidence worthy of concern given O(100 billion) spams per day overwhelmingly sent by botnets which are the actual core of the actual problem. I say you're guessing, and not very convincingly either.

So you have two opaque components to filtering. And senders are deliberately left guessing - is the problem REALLY that a mailbox is full, or am I getting greylisted in some odd manner?

Except that most sites return some indication that a mailbox is full. It's just unfortunately in the realm of heuristics. But look into popular mailing list software packages (mailman, majordomo) and you'll see modules for classifying bounce backs heuristically and automatic list removal (or not if it seems like a temporary failure, e.g., mailbox full.)

Filtering stinks. It is resource-intensive, time-consuming, error-prone, and pretty much an example of something that is desperately flagging "the current e-mail system is failing."

And standardized return codes (for example) will make this worse, how?

You want to define standards? Let's define some standard for establishing permission to mail. If we could solve the permission problem, then the filtering wouldn't be such a problem, because there wouldn't need to be as much (or maybe even any). As a user, I want a way to unambiguously allow a specific sender to send me things, "spam" filtering be damned. I also want a way to retract that permission, and have the mail flow from that sender (or any of their "affiliates") to stop.

Sure, but this is pie in the sky. For starters you'd have to get the spammers to conform which would almost certainly take a design which was very difficult not to conform to, it would have to be technologically involuntary. Whitelists are the closest I can think of but they haven't been very popular and for good reasons. Anyhow, the entire planet awaits your design. A set of standardized return codes was carefully chosen by me as something which could be (other than the standards process itself) adopted practically overnight and with virtually zero backwards compatability problems (oh there'll always be an exception.)

Right now I've got a solution that allows me to do that, but it requires a significant paradigm change, away from single-e-mail-address.

There's nothing new in disposable, single-use addresses (or credit card numbers for that matter, a different realm) if that's what you mean but if you have something more clever the world (i.e., the big round you see when you look down) is your oyster.

Addressing "standards" of the sort you suggest is relatively meaningless in the bigger picture, I think. Nice, but not that important.

Well, first you'd have to indicate that you actually have a view of the problem which supports such a judgment. At any rate you're quibbling the example as I forewarned. But standardizing receiving MTA fail codes is, I suspect, more useful than you give them credit. It would be some progress at little to no cost in the large. It deals less with spam filtering and more with effective MTA to MTA operation. At least it's sticking to the realm of improving standards in a way that can be accomplished. I don't see how I could have given a better example without a lot of hand-waving and vagaries. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

Massive quoting gets old fast so I'll try to summarize and if I misrepresent your POV in any way my profuse apologies in advance. First and foremost let me say that if we had a vote here tomorrow on the spam problem I suspect you'd win but that's because most people, even (especially) people who believe themselves to be technically knowledgeable, hold a lot of misconceptions about spam. So much for democracy. I say the core problem in spam are the botnets capable of delivering on the order of 100 billion msgs/day. You say there are other kinds of spammers. I'll agree but if we got rid of or incapacitated the massive botnets that would be a trickle, manageable, and hardly be worth fussing about, particularly on an operational list. The reason is that without the botnets the spammers don't have address mobility. You could just block their servers. But if we don't agree on those points then we're talking past each other. I assert that the problem are the massive O(100B) botnet spammers and they simply don't have the resources or interest really (because they don't have the resources or business model) to do things like analyze return codes etc as you describe. So it's doubtful to me that returning more meaningful return codes in SMTP rejections would be of much use to them. It's also not of much use to them, as I previously described, even if they tried. They could deduce about the same information for about the same "price" without the return codes. But any such return codes should be voluntary, particularly the details, and a receiving MTA should be free to respond with as much or as little information as they are comfortable with right down to the big red button, "421 it just ain't happenin' bub!" But it was just an example of how perhaps some standards, particularly regarding mail rejection, might help operationally. I'm not pushing the particular example I gave of extending status codes. Also, again I can't claim to know what you're working on, but there are quite a few "disposable" address systems in production which use various variations such as one per sender, one per message, change it only when you want to, etc. But maybe you have something better, I encourage you to pursue your vision. And, finally, one quote:

I didn't say I had a design. Certainly there are solutions to the problem, but any solution I'm aware of involves paradigm changes of some sort, changes that apparently few are willing to make.

Gosh if you know of any FUSSP* whose only problem is that it requires everyone on the internet to abandon SMTP entirely or similar by all means share it. Unfortunately this is a common hand-wave, "oh we could get rid of spam overnight but it would require changes to (SMTP, usually) which would take a decade or more to implement, if at all!" Well, since it's already BEEN a decade or more that we've all been fussing about spam in a big way maybe we should have listened to people with a secret plan to end the war back in 1998. So I'm here to tell ya I'll listen to it now and I suspect so will a lot of others. * FUSSP - Final and Ultimate Solution to the Spam Problem. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

Massive quoting gets old fast so I'll try to summarize and if I misrepresent your POV in any way my profuse apologies in advance.

First and foremost let me say that if we had a vote here tomorrow on the spam problem I suspect you'd win but that's because most people, even (especially) people who believe themselves to be technically knowledgeable, hold a lot of misconceptions about spam. So much for democracy.

I say the core problem in spam are the botnets capable of delivering on the order of 100 billion msgs/day.

You say there are other kinds of spammers.

I'll agree but if we got rid of or incapacitated the massive botnets that would be a trickle, manageable, and hardly be worth fussing about, particularly on an operational list.

That's not quite true. The spam problem predates the massive botnets. Massive botnets are rather a recent thing. *A* core problem *for engineering purposes* is that botnets are capable of delivering an essentially unlimited flood of source material for our mail systems. This is a primary target for anti-spam efforts at the major ISP's, and certainly many of them have a lot of experience in trying to stem this highly effective and nonstop DDoS attack on the e-mail system. I do not believe that anyone seriously disagrees with that. However, the average user has different problems. First off, let me state this as a prerequisite for any further discussion. E-mail has to be perceived, by the users, as a beneficial tool, one that they can rely on for the things that they choose to do. If you disagree with this, then any further discussion is meaningless, because we do not share a common view of what the e-mail system needs to be. You would not be the only person to perceive e-mail in a different manner, if you did. To be sure, there are people who perceive it as something that is trivial, in the class of IM or IRC protocols, for example. I view it as something I'd like to work at least as reliably as the US Post. So, here are some additional problems. These are not botnet problems, but rather user problems with the e-mail system. Users cannot reliably receive e-mail that they have asked to receive. For example, receiving receipts from a vendor. Users cannot be assured that the e-mail that they've received is from the sender that it appears to be. Users cannot know if the mail that they've sent has been received by the dodgy freemail hoster that their friend is on. Users cannot withdraw permission to send from an abusive sender. They are finding their address shared with others, or are unable to unsub, or whatever. These are all significant problems with the current e-mail implementation. They do not represent DDoS-class problems. However, they do represent a massive set of problems that are driving users away from e-mail. If it is allowed to continue, our FUSSP can be to simply block all port 25, as SMTP will become irrelevant. Yes, that's a bit dramatic, but it's also the way things are headed.

The reason is that without the botnets the spammers don't have address mobility. You could just block their servers.

That's demonstrably false, and displays a gross ignorance of both historical and current spammer modes of operation. It is exceedingly common for hosting providers to receive requests from clients to be allocated many noncontiguous IP addresses out of a number of /24's, and these requests are honored by many of the seedier providers. This has been the case for years. Some of them even attempt to justify it by claiming that they need it for purposes of affecting Google advertising (for example). See http://www.spamhaus.org/faq/answers.lasso?section=Glossary#233 to learn more about snowshoe spamming, and related techniques.

But if we don't agree on those points then we're talking past each other.

We don't agree on some of them, that's for sure.

I assert that the problem are the massive O(100B) botnet spammers and they simply don't have the resources or interest really (because they don't have the resources or business model) to do things like analyze return codes etc as you describe.

That's _a_ problem, but it is hardly the only problem pressing in on the e-mail system. Were this the only problem, it would be easiest to solve it by whitelisting legitimate senders, probably in combination with some variation of the Spamhaus PBL system, and winding up with a restrictive version of SMTP that requires you to somehow be authorized to send e-mail. Variations on this have been less than completely successful. It is a monumental undertaking, but it /could/ be done. It wouldn't solve the problem, however.

So it's doubtful to me that returning more meaningful return codes in SMTP rejections would be of much use to them.

Of course not - to them.

It's also not of much use to them, as I previously described, even if they tried. They could deduce about the same information for about the same "price" without the return codes.

Again - to them. But they're hardly the only class of spammers. I realize it's convenient to ignore that fact for the purposes of this discussion, since it supports your argument while ignoring the fact that other spammers would mine a lot of useful information out of such messages.

But any such return codes should be voluntary,

And they are. To the best of my knowledge, you can put pretty much any crud you like after the "### ", and if anybody wanted to return this data, they would be doing it today.

particularly the details, and a receiving MTA should be free to respond with as much or as little information as they are comfortable with right down to the big red button, "421 it just ain't happenin' bub!"

But it was just an example of how perhaps some standards, particularly regarding mail rejection, might help operationally. I'm not pushing the particular example I gave of extending status codes.

Also, again I can't claim to know what you're working on, but there are quite a few "disposable" address systems in production which use various variations such as one per sender, one per message, change it only when you want to, etc. But maybe you have something better, I encourage you to pursue your vision.

No. The difference to my solution is simply that it solves all the problems I outlined when I wanted to solve the problem I started with - finding a clean way to be able to exempt senders from anti-spam checks that they frequently fell afoul of. But then again, I am merely saying that there are solutions capable, but that they all seem to require some paradigm shift.

And, finally, one quote:

...

I didn't say I had a design. Certainly there are solutions to the problem, but any solution I'm aware of involves paradigm changes of some sort, changes that apparently few are willing to make.

Gosh if you know of any FUSSP* whose only problem is that it requires everyone on the internet to abandon SMTP entirely or similar by all means share it.

That was kind of the nifty part to my solution: it didn't require any changes at any sender's site. By accepting some tradeoffs, I was able to compartmentalize all the permission issues as functions controlled by the receiving site.

Unfortunately this is a common hand-wave, "oh we could get rid of spam overnight but it would require changes to (SMTP, usually) which would take a decade or more to implement, if at all!"

Well, since it's already BEEN a decade or more that we've all been fussing about spam in a big way maybe we should have listened to people with a secret plan to end the war back in 1998. So I'm here to tell ya I'll listen to it now and I suspect so will a lot of others.

If we cannot have a flag day for the e-mail system, and obviously, duh, we cannot have a flag day for the e-mail system, we have to look at other changes. That's too big a paradigm shift. My solution is a comprehensive solution to the permission problem, which is a root issue in the fight against spam, but it is based on a paradigm shift that ISP's are unwilling to underwrite - dealing with per-correspondent addresses. This has challenges associated with it, primarily related to educating users how to use it, and then getting users to commit to actually doing so. That's not TOO big a paradigm shift, since it's completely backwards- compatible and managed at the receiving site without any support required anywhere else in the e-mail system, but since service providers aren't interested in it, it is a non-starter. Were it interesting, it wouldn't be that tough to support relatively transparently via plugins into modern browsers such as Firefox and Thunderbird. But it is a LARGE paradigm shift, and it doesn't even solve every problem with the e-mail system. I am unconvinced that there aren't smaller potential paradigm shifts that could be made. However... It is exceedingly clear to me that service providers prefer to treat the spam problem in a statistical manner. It offers fairly good results (if you consider ~90%-99% accuracy to be acceptable) but doesn't actually do anything for users who need e-mail that they can actually rely on. It's cheap (relatively speaking) and the support costs can be made to be cheap.

* FUSSP - Final and Ultimate Solution to the Spam Problem.

Shoot all the spammers? :-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Sun, Apr 13, 2008, Joe Greco wrote:

...

browsers such as Firefox and Thunderbird. But it is a LARGE paradigm shift, and it doesn't even solve every problem with the e-mail system.

I am unconvinced that there aren't smaller potential paradigm shifts that could be made. However...

There already has been a paradigm shift. University students ("college" for you 'merkins) use facebook, myspace (less now, thankfully!) and IMs as their primary online communication method. A number of students at my university use email purely because the university uses it for internal systems and communication, and use the above for everything else.

I think you'll find that "we" are the paradigm shift that needs to happen. The younger people have already moved on. :)

I believe this is functionally equivalent to the "block 25 and consider SMTP dead" FUSSP. It's worth noting that each "newer" system is being systematically attacked as well. It isn't really a solution, it's just changing problem platforms. The abuse remains. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Sun, Apr 13, 2008, Joe Greco wrote:

...

I believe this is functionally equivalent to the "block 25 and consider SMTP dead" FUSSP.

It's worth noting that each "newer" system is being systematically attacked as well. It isn't really a solution, it's just changing problem platforms. The abuse remains.

Yes, but the ownership of the problem is better defined for messages -inside- a system.

If you've got tens of millions of users on your IM service, you can start using statistical techniques on your data to identify likely spam/ham, and (very importantly) you are able to cut individual users off if they're doing something nasty. Users can't "fake" their identity like they can with email. There's no requirement for "broadcasting" messages a la email lists (which btw is touted as one of those "things that break" when various anti-spam verify-sender proposals come up.)

Besides - google has a large enough cross section of users' email to do these tricks. I'd love to be a fly on the wall at google for just this reason ..

Few of these systems have actually been demonstrated to be invulnerable to abuse. As a matter of fact, I just saw someone from LinkedIn asking about techniques for mitigating abuse. When it's relatively cheap (think: economically attractive in excessively poor countries with high unemployment) to hire human labor, or even to engineer CAPTCHA evasion systems where you have one of these wonderful billion-node-botnets available, it becomes feasible to get your message out. Statistically, there will be some holes. You only need a very small success rate. The relative anonymity offered by e-mail is a problem, yes, but it is only one challenge to the e-mail architecture. For example, given a realistic way to revoke permission to mail, having an anonymous party send you a message (or even millions of messages) wouldn't be a problem, because you could stop the flow whenever you wanted. The problem is that there isn't a commonly available way to revoke permission to mail. I've posted items in places where e-mail addresses are likely to be scraped or otherwise picked up and later spammed. What amazed me was how cool it was that I could actually post a usable e-mail address and receive comments from random people, and then when the spam began to roll in, I could simply turn off the address, and it doesn't even hit the mailservers. That's the power of being able to revoke permission. The cost? A DNS query and answer anytime some spammer tries to send to that address. But a DNS query was happening anyways... The solution I've implemented here, then, has the interesting quality of moving ownership of the problem of permission within our systems, without also requiring that all correspondents use our local messaging systems (bboard, private messaging, whatever) or having to do ANY work to figure out what's spam vs ham, etc. That's my ultimate reply to your message, by the way. Since it is clear that many other networks have no interest in stemming the flood of trash coming from their operations, and clearly they're not going to be interested in permission schemes that require their involvement, I'd say that solutions that do not rely on other networks cooperating to solve the problem bear the best chance of dealing with the problem. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Mon, 14 Apr 2008, Adrian Chadd wrote:

There already has been a paradigm shift. University students ("college" for you 'merkins) use facebook, myspace (less now, thankfully!) and IMs as their primary online communication method. A number of students at my university use email purely because the university uses it for internal systems and communication, and use the above for everything else.

That is not anything new. ICQ is 10 years old and IRC was common in the early 90s. I would guess plenty of people on this list use (and used back then) both to talk to their friends and team mates. The question is what tool are people going to use to talk to people, government bodies and companies that they are not "friends" with? Even if the person you want to contact is on IM it is likely they will block messages from random people due to the existing Spam problem there. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

On Mon, Apr 14, 2008, Simon Lyall wrote:

That is not anything new. ICQ is 10 years old and IRC was common in the early 90s. I would guess plenty of people on this list use (and used back then) both to talk to their friends and team mates.

There's a difference here. In the 90's we used IRC and email. Today people use IM applications and web forums/website IMs. There are students which use almost no email outside of communicating to the university, to the point where they never check their university email. :) In fact, the students complain that they're receiving craploads of email from the university and related groups for stuff they don't want - a microcosm of spam on one campus. :) Adrian

On Sun, Apr 13, 2008 at 11:48:31PM -0400, Rich Kulawiec wrote:

On Sun, Apr 13, 2008 at 08:04:12PM -0400, Barry Shein wrote: A number of things that are true, including:

...

I say the core problem in spam are the botnets capable of delivering on the order of 100 billion msgs/day.

But I say the core problem is deeper. Spam is merely a symptom of an underlying problem. (I'll admit that I often use the phrase "spam problem" but that's somewhat misleading.)

The problem is pervasive poor security. Those botnets would not exist were it not for nearly-ubiquitous deployment of an operating system that cannot be secured -- and we know this because we've seen its own vendor repeatedly try and repeatedly fail. But a miserable excuse for an OS is just one of the causes; others have been covered by essays like Marcus Ranum's "Six Dumbest Ideas in Security", so I won't attempt to enumerate them all.

Is there a (nontrivial) OS that can be secured inexpensively, ie. for the price that is paid for by shoppers at your local big box outlet? To me, that's as much the problem as anything else that's been written so far. The Internet is what it is largely because that is what the users (collectively) will pay for. Furthermore, it's not so much the OS as it is the applications, which arguably might be more securable if Joe and Jane User took the time to enable the security features that are available for the OSes they buy. But that doesn't happen. I don't blame Joe and Jane User; most nontechnical people do not view their home or work systems as something more than an appliance for getting work done or personal entertainment.

A secondary point that actually might be more important:

We (and I really do mean 'we" because I've had a hand in this too) have compounded our problems by our collective response -- summed up beautifully on this very mailing list a while back thusly:

If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well". --- Paul Vixie on NANOG

We need to hold ourselves accountable for the security problems in our own operations, and then we need to hold each other accountable. This is very different from our strategy to date -- which, I submit, has thoroughly proven itself to be a colossal failure.

One of the things I like about this list is that it consists of people and organizations who DO hold themselves accountable. But as long as it's not the collective will of the Internet to operate securely, not much will change. --gregbo

On Apr 13, 2008, at 2:24 PM, Joe Greco wrote:

For example, I feel very strongly that if a user signs up for a list, and then doesn't like it, it isn't the sender's fault, and the mail isn't spam. Now, if the user revokes permission to mail, and the sender keeps sending, that's covered as spam under most reasonable definitions, but that's not what we're talking about here.

To expect senders to have psychic knowledge of what any individual recipient is or is not going to like is insane. Yet that's what current expectations appear to boil down to.

This is actually becoming a method some groups are using to attempt to censor others. This happened to one of our customers a while back: Site A publishes some things that Group B finds objectionable. Group B wants to get it removed, but it's not illegal, against the hosting company's TOS or copyright infringement. Group B tells all of it's members to go to Site A and sign up for A's discussion forum, using as many email addresses as they own. A user registers for an account (one email sent to the user to confirm their email address). The user clicks the confirmation link, then gets an introductory email. The user then does everything possible on the site that could generate emails. Password changes. "Notify me by email when the forum has a new post" activated. Sending private messages to each other. Etc. When they've got thousands of users signed up, each with between 6 and 20 emails from Site A, Group B tells all of its users to go through all the emails and click "Report as Spam" on every one of them. Every mail provider out there suddenly sees tens of thousands of reported spams coming from Site A from a wide range of people, and can independently verify that other sources are seeing elevated levels of spam from Site A's mail server. Everyone blocks mail from Site A, thinking it's a spam source. This took an insane amount of time to sort out. If the organizer of "Group B" hadn't emailed me personally confirming (and bragging) about what they had done, I still probably wouldn't have believed it. Our AOL feedback loop took days to go through, and contacting every blacklist we had our mail server entered on and convincing them of our story was difficult to put it mildly. And to make this mildly on- topic, we resolved this somewhat quickly with every provider except Yahoo - which never responded to any of our emails or form submissions. Then there are the users who apparently think the "Report as Spam" button is like a spare for the "Delete" button, and use them interchangeably... We regularly have users who sign up for a mailing list, click the opt-in confirmation link, then report the confirmation email as spam. We remove them from the mailing list, then they complain they aren't getting their list anymore. We reply back explaining why they were removed, and they report our reply as spam. -- Kevin

...

You want to define standards? Let's define some standard for establishing permission to mail. If we could solve the permission problem, then the filtering wouldn't be such a problem, because there wouldn't need to be as much (or maybe even any). As a user, I want a way to unambiguously allow a specific sender to send me things, "spam" filtering be damned. I also want a way to retract that permission, and have the mail flow from that sender (or any of their "affiliates") to stop.

Right now I've got a solution that allows me to do that, but it requires a significant paradigm change, away from single-e-mail-address.

In general, your "permission to send" idea is a good one to put in the requirements list for a standard email architecture. But your particular solution stinks because it simply adds another bandage to a creaky old email architecture that is long past its sell-by date.

Yes. I'm well aware of that. My requirements list included that my solution be able to actually /fix/ something with /today's/ architecture; this is a practical implementation to solve a real problem, which was that I was tired of vendor mail being confused for spam. So, yes, it stinks when compared to the concept of a shiny new mail architecture. However, it currently works and is successfully whitelisting the things I intended. I just received a message from a tool battery distributor that some batteries I ordered months ago are finally shipping. It was crappy HTML, and I would normally have completely missed it - probably even forgetting that we had ordered them, certainly not recognizing the "From" line it came from. It's a success story. Rare. You are welcome to scoff at it as being a stinky bandaid on a creaky mail system.

IMHO, the only way that Internet email can be cleaned up is to create an entirely new email architecture using an entirely new set of protcols with entirely new port assignments and no attempt whatsoever to maintain reverse compatibility with the existing architecture. That is a fair piece of work and requires a lot of people to get their heads out of the box and apply some creativity. Many will say that the effort is doomed before it starts because it is not compatible with what went before. I don't buy that argument at all.

In any case, a new architecture won't come about until we have some clarity of the requirements of the new architecture. And that probably has to be hashed out somewhere else, not on any existing mailing list.

If such a discussion does come about, I want people to understand that user-controlled permission is a much better fix than arbitrary spam filtering steps. There's a lot of inertia in the traditional spam filtering advice, and a certain amount of resistance to considering that the status quo does not represent e-mail nirvana. Think of it as making that "unsubscribe" at the bottom of any marketing e-mail actually work, without argument, without risk. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

Can we wrap the mail threads up

actually, i am still learning from some of them. i have a hypothesis to add nanog list volume is proportional to S + E where S is the amount of Slack time the active members have and E is the existence of a significant Event in the absence of a significant event, volume is directly driven by the amount of free time we have at the tube. as there is no event to discuss, we will discuss whatever is kinda interesting, often the same subjects. after all, this is a discussion forum, not a current news desk. if an operational event ocurrs, discussion of it quickly predominates over the S component. if we could watch this happening, we might even learn something interesting about information flow in our culture, as the wavefront of the E information causes posters attention to move. and, in the absence of an E, and S being diverted to to actual paid work, volume goes down. as pfs mentioned this eve, some time in the last months, the shortage of E and S was so severe that someone posted an "is the list working" test message. randy

On Sun, 13 Apr 2008, Barry Shein wrote:

For example, and it's only an example don't quibble the example, defining a list of return SMTP codes which are actually specific and meaningful like (let's assume they should be 5xx, maybe 7xx would be a better start? Policy failure codes) [...] and so on, a taxonomy which could then at least be dealt with intelligently by sending MTAs and supporting software rather than each side cooking up their own stuff.

See RFC 3463. Unfortunately it doesn't help much to solve the problem it was designed for. I ranted about this a while back... http://www.ietf.org/mail-archive/web/ima/current/msg00588.html Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ BAILEY: NORTHWESTERLY 6 TO GALE 8, VEERING SOUTHEASTERLY 4 OR 5. MODERATE OR ROUGH. RAIN OR SHOWERS, THEN FAIR. MODERATE OR GOOD.