North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Problems sending mail to yahoo?
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 | [email protected] | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo*