Re: Yahoo Mail Update
On Thu, Apr 10, 2008 at 8:54 PM, Rich Kulawiec [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 05:51:23PM -0700, chuck goolsbee wrote: Thanks for the update Jared. I can understand your request to not be used as a proxy, but it exposes the reason why Yahoo is thought to be clueless: They are completely opaque. They can not exist in this community without having some visibity and interaction on an operational level. I heartily second this. Yahoo (and Hotmail) (and Comcast and Verizon) mail system personnel should be actively participating here, on mailop, on spam-l, etc. A lot of problems could be solved (and some avoided) with some interaction. ---Rsk Why should large companies participate here about mail issues? Last I checked this wasn't the mailing list for these issues: NANOG is an educational and operational forum for the coordination and dissemination of technical information related to backbone/enterprise networking technologies and operational practices. But lets just say for a second this is the place to discuss company xys's mail issue. What benefit do they have participating here? Likely they'll be hounded by people who have some disdain for their company and no matter what they do they will still be evil or wrong in some way. It is easy for someone who has 10,000 users to tell someone who has 50 million users what to do when they don't have to work with such a large scale enterprise. I find it funny when smaller companies always tell larger companies what they need to be doing. -- Ross ross [at] dillio.net 314-558-6455
Re: Problems sending mail to yahoo?
On Sun, Apr 13, 2008 at 11:15 AM, Roger Marquis [EMAIL PROTECTED] wrote: Sounds like the party line inside Yahoo, but there are plenty of ISPs that do a really good job of combating spam. They do it with standard tools like RBLs, Spamassassin, OCR, ClamAV and without ineffective diversions like SPF or DKIM. Unless you have actually implemented filters on production mail platforms with several million users.. please. Not that spam really has much to do with network operations, well, except perhaps for those pesky Netcool/Openview/Nagios alerts... You havent been sitting in on most of the security related talks and bofs at *nog, right? If you have, that'd be a surprisingly naïve statement. srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Problems sending mail to yahoo?
Roger Marquis wrote: Sounds like the party line inside Yahoo, but there are plenty of ISPs that do a really good job of combating spam. They do it with standard tools like RBLs, Spamassassin, OCR, ClamAV and without ineffective diversions like SPF or DKIM. Seen from inside, it is not spamfilters but it is the routing table. I have seen spam dropping by 98% when zerorouting some networks. Nobody complained about false positives :) But this is another story for the big ones. They might have customers. The problem is that it is an art, not well documented (without reading 5 or 6 sendmail/postfix and anti-spam mailing lists for a several years), is not taught in school (unlike systems and network administration), and rarely gets measured with decent metrics. That is true. Plus the rules are constantly changeing. Not that spam really has much to do with network operations, well, except perhaps for those pesky Netcool/Openview/Nagios alerts... At the edge it does. It can bring your VoIP down and video on demand. I know from campus networks who improved p2p service when zerorouting networks known for sending spam. Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
Re: Yahoo Mail Update
At 01:58 AM 4/13/2008, you wrote: Why should large companies participate here about mail issues? Last I checked this wasn't the mailing list for these issues: True, though some aspects of mail service are inextricably tied to broader networking issues, and thus participation here might still benefit them. But sadly Yahoo doesn't even seem to participate in more relevant forums, such as the spam-l list. But lets just say for a second this is the place to discuss company xys's mail issue. What benefit do they have participating here? Likely they'll be hounded by people who have some disdain for their company and no matter what they do they will still be evil or wrong in some way. I've never seen someone treated badly for trying to help resolve problems. I think we all know that it can be hard to get things done within a large company and that often the folks who participate on a list like this are taking on work that isn't strictly speaking their job when they try to help resolve mail issues. And when a large company that was a mess does a turnaround, they also get praised: just look at the many positive comments about AOL on this and other lists over the past few years. It is easy for someone who has 10,000 users to tell someone who has 50 million users what to do when they don't have to work with such a large scale enterprise. I wouldn't presume to tell them how to accomplish something within their particular configuration. But I will, without apology, tell them that they need to accomplish it. For example, I'm quite comfortable saying that Earthlink should follow the minimum timeouts in RFC 1123, though I wouldn't presume to guess whether they should accomplish that by having separate fast and slow queues on different servers, on the same server, or not at all. Likewise, a working abuse role account is a minimum requirement for participation in the Internet email system, and I'm comfortable saying that the email it receives should be read by a competent human. I find it funny when smaller companies always tell larger companies what they need to be doing. When what the larger companies do enables criminal behavior that impacts the very viability of the smaller companies through de factor DoS attacks, it's not funny at all. Yahoo, for example, has chosen a business model (free email with little to no verification) that inevitably leads to spam being originated from their systems. Why should they be able to shift the cost of their business model to me, just because I run a much smaller business?
Re: Yahoo Mail Update
On Sun, Apr 13, 2008 at 3:57 PM, Rob Szarka [EMAIL PROTECTED] wrote: True, though some aspects of mail service are inextricably tied to broader networking issues, and thus participation here might still benefit them. But sadly Yahoo doesn't even seem to participate in more relevant forums, such as the spam-l list. There are other lists, far more relevant than spam-l or nanae. There's a way to present spam issues and mail filtering operationally.. and I see it all the time at MAAWG meetings, just for example. The issue here is that 90% of the comments on a thread related to this are from people who might be wizards at packet pushing, but cant filter spam. Or on mailserver lists you might find people who can write sendmail.cf from scratch instead of building it from a .mc file and still dont know about the right way to do spam filtering. When what the larger companies do enables criminal behavior that impacts the very viability of the smaller companies through de factor DoS attacks, it's not funny at all. Yahoo, for example, has chosen a business model (free email with little to no verification) that inevitably leads to spam being originated from their systems. Why should they be able to shift the cost of their business model to me, just because I run a much smaller business? So has hotmail, so have several of the domains that we host. srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Yahoo Mail Update
On Sun, Apr 13, 2008 at 1:58 AM, Ross [EMAIL PROTECTED] wrote: [ clip ] I heartily second this. Yahoo (and Hotmail) (and Comcast and Verizon) mail system personnel should be actively participating here, on mailop, on spam-l, etc. A lot of problems could be solved (and some avoided) with some interaction. ---Rsk Why should large companies participate here about mail issues? Last I checked this wasn't the mailing list for these issues: It is an operations list and part of operating a network is delivering content of protocols whether it be http or smtp. [ clip ] But lets just say for a second this is the place to discuss company xys's mail issue. What benefit do they have participating here? Likely they'll be hounded by people who have some disdain for their company and no matter what they do they will still be evil or wrong in some way. They can use an alias if they don't want to publish under their company banner. It is easy for someone who has 10,000 users to tell someone who has 50 million users what to do when they don't have to work with such a large scale enterprise. I find it funny when smaller companies always tell larger companies what they need to be doing. When lots of smaller companies tell larger companies what to do, they typically do it. Part of the value of a community like NANOG is for groups of smaller companies to demonstrate both the positive and negative aspects of products(routers) or services(mail) of others so that these other companies (cisco, Yahoo!, et. al.) can learn from us and either create new products(Nexus 7000) or add features(LISP) and fixes(autosecure) or (abuse desk). The fact that a bunch of little companies are pointing out the operational inefficiencies of large providers (of mail services) should offer some value to them, and to us. The reason why these operations are not open and friendly is because they are overhead and cost of doing business. I doubt you'll see any investments in making it easier, but if the interaction process was better explained or simplified, it might be helpful. Having some provider or group(MAAWG?) explain the new and improved overhead driven mail/abuse desk would make an excellent NANOG presentation, IMHO, and it could include a V6 slant like and to handle V6 abuse issues the plan is.. Best, -M
Re: Yahoo Mail Update
On Sun, Apr 13, 2008 at 8:24 PM, Martin Hannigan [EMAIL PROTECTED] wrote: Having some provider or group(MAAWG?) explain the new and improved overhead driven mail/abuse desk would make an excellent NANOG presentation, IMHO, and it could include a V6 slant like and to handle V6 abuse issues the plan is.. MAAWG spent three entire meetings drafting this - and a very interactive drafting process it was too (hang flipcharts on the walls, each with a key question, people circulate around the room with marker pens, write their ideas. Other people rate these ideas. The flipcharts are then taken down, the contents edited to produce a BCP Here's the abuse desk management BCP - one that includes several things that I personally regard as a very good idea indeed - http://www.maawg.org/about/publishedDocuments/Abuse_Desk_Common_Practices.pdf And by the time v6 actually gets used for exchanging email except between guy with personal colo and a tunneled /48, and freebsd.org / isc.org etc hosted lists .. you'll probably find that the basic concepts of filtering remain much the same, v4, v6 (or perhaps even Jim Fleming's or that Chinese vendor's IPv9) srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Yahoo Mail Update
Suresh Ramasubramanian wrote: On Sun, Apr 13, 2008 at 3:57 PM, Rob Szarka [EMAIL PROTECTED] wrote: True, though some aspects of mail service are inextricably tied to broader networking issues, and thus participation here might still benefit them. But sadly Yahoo doesn't even seem to participate in more relevant forums, such as the spam-l list. There are other lists, far more relevant than spam-l or nanae. There's a way to present spam issues and mail filtering operationally.. and I see it all the time at MAAWG meetings, just for example. MAAWG, is fine but the requirements for participation are substantially higher than the nanog list. The issue here is that 90% of the comments on a thread related to this are from people who might be wizards at packet pushing, but cant filter spam. Or on mailserver lists you might find people who can write sendmail.cf from scratch instead of building it from a .mc file and still dont know about the right way to do spam filtering. People who have operational problems don't generally get to pick the skillset they already have just because a problem appears, some cognizance of that is surely in order. If the discussion is headed further in the meta-direction we should take it to futures.
Re: Yahoo Mail Update
On Sun, Apr 13, 2008 at 10:09 PM, Joel Jaeggli [EMAIL PROTECTED] wrote: MAAWG, is fine but the requirements for participation are substantially higher than the nanog list. * Quite a lot of ISPs who already attend nanog are also maawg members * Lots of independent tech experts (Dave Crocker, Chris Lewis, Joe St.Sauver from UOregon etc) are regulars at maawg, designated as senior tech advisors * Quite a few other invited guest type people So, not as bad as it sounds People who have operational problems don't generally get to pick the skillset they already have just because a problem appears, some cognizance of that is surely in order. That was the only meta comment I had here. I'll stop now. srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Yahoo Mail Update
At 08:49 AM 4/13/2008, Suresh Ramasubramanian wrote: There are other lists, far more relevant than spam-l or nanae. Feel free to suggest some that you feel would be more appropriate or effective. Since reaching them via [EMAIL PROTECTED] or any of their published phone numbers doesn't seem to work, backchannels are all that's left. (I do, however, subscribe to many lists and have yet to notice a presence of clueful Yahoo people on any of them.) Yahoo, for example, has chosen a business model (free email with little to no verification) that inevitably leads to spam being originated from their systems. So has hotmail, so have several of the domains that we host. Indeed, and I didn't mean to imply that Yahoo was necessarily worse than Hotmail (and several free email providers based outside the US, as far as I can tell). The difference, as I'm sure you're aware, is that some free email providers seem to care enough to minimize the costs they impose on the rest of us by responding appropriately to the inevitable abuse.
Re: Problems sending mail to yahoo?
I realize it's natural and predictable, when spam is mentioned, to repeat the folklore...then the robots came and we were all driven underground to survive... However my point was something more in the realm of standards and operations and what we can do rather than going back over what we can't seem to do. 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) 540 Sending site in internal blacklist contact: URL or MAILBOX 541 Sending site is in external blacklist: URL 542 FROM address blocked: MAILBOX 543 RCPT address blocked: MAILBOX 544 BODY contained blacklisted URL or MAILBOX: URL or MAILBOX 545 BODY contained blacklisted string not a URL or MAILBOX 546 SUBJECT contained blacklisted URL or MAILBOX: URL or MAILBOX 547 SUBJECT contained blacklisted string not a URL or MAILBOX 548 SPF Failure (note: could be subsetted further or detail code added) 549 DKIM Failure (note: could be subsetted further or detail code added) 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. That's the first problem with this yahoo flap, right? You have to go to the backed up mail queues and stare at them and try to pattern match that a lot of these are from yahoo, and oh look they're deferred?, wait, inside the queue files you can find this 421 Deferred due to user complaints see URL which then leads you to a form to fill out and you're still not sure what exactly you're pursuing other than hoping you can make it go away either by your action or theirs. Gak, there isn't even a standard code which means MAILBOX FULL or ACCOUNT NOT RECEIVING MAIL other than MAILBOX FULL, maybe by choice, maybe non-payment, as specific as a site is comfortable with. That's what I mean by standards and at least trying to focus on what can be done rather than the endless retelling of what can't be done. More specific and standardized SMTP failure codes are just one example but I think they illustrate the point I'm trying to make. Oh yeah here's another (ok maybe somewhere this is written down), how about agreeing on contact mailboxes like we did with [EMAIL PROTECTED] Is it [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] (very commonly used) or [EMAIL PROTECTED] Who cares? But let's pick ONE, stuff it in an RFC or BCP and try to get each other to conform to it. -- -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*
Re: clickbank.net and bundleway.com
[EMAIL PROTECTED] (Jon R. Kibler) writes: Anyone have any info on either of these domains? I have seen several recent web sites that had an iframe that pointed to clickbank.net and interesting / hidden links to bundleway.com. Haven't found much of use in a quick search of Google, except for a few claims of fraud against them. I suspect that they are some how related to affiliate programs? TIA for anything you may be able to tell me! the nameservers who answered questions about bundleway.com in the last ~150 days were: 216.129.109.1 66.117.40.198 205.234.154.1 205.234.170.165 63.219.151.3 216.49.92.249 the A RR is stable, no flux at all. the nameservers are stable, also no flux. 1198886670 an bundleway.com IN A 1800,64.40.117.19 216.129.109.1 1197752951 ns bundleway.com IN NS 1800,ns0.dnsmadeeasy.com \ 1800,ns0.dnsmadeeasy.com.bundleway.com \ 1800,ns1.dnsmadeeasy.com \ 1800,ns1.dnsmadeeasy.com.bundleway.com \ 1800,ns2.dnsmadeeasy.com \ 1800,ns2.dnsmadeeasy.com.bundleway.com \ 1800,ns3.dnsmadeeasy.com \ 1800,ns3.dnsmadeeasy.com.bundleway.com \ 1800,ns4.dnsmadeeasy.com \ 1800,ns4.dnsmadeeasy.com.bundleway.com \ 216.129.109.1 note that there are no actual .dnsmadeeasy.com.bundleway.com nameservers, so i suspect that somebody somewhere forgot a trailing . or had the wrong $ORIGIN or something. this is in the zone, or at least, it's in all answers from the zone's servers, it's consistent enough that i expect it's in-zone rather than some kind of dns load balancing error. most traffic seen under clickbank.net is A RR responses, here are the top 10 out of ~4600 or so: roeib.4idiots.hop.clickbank.net mediafire.noadware.hop.clickbank.net mediafire.spywarebot.hop.clickbank.net mediafire.regsmart.hop.clickbank.net mediafire.adalert.hop.clickbank.net mediafire.regcure.hop.clickbank.net delusions.sharezone.hop.clickbank.net rvrsephone.phonesrch.hop.clickbank.net esearching.movies01.hop.clickbank.net vvllc2.phonesrch.hop.clickbank.net ... it's pretty damning stuff. the nameservers who produce these are, in order by frequency (downward): 209.81.12.120 209.81.12.121 64.128.87.120 64.128.87.121 216.99.132.5 216.99.132.104 (no overlap with the dnsmadeeasy.com nameservers shown earlier.) the A RR's given by these *.hop.clickbank.net answers are always one of these three: 900,209.81.12.132 900,209.81.12.133 900,64.128.87.132 900,64.128.87.133 900,209.81.12.134 900,209.81.12.135 that is, two A RRs in an RRset, TTL 900. the first two are overwhelmingly more frequent than the third one. looks like some kind of load balancing. there's a similar but less frequent pattern, *.pay.clickbank.net, whose A RRs are always one of these two sets: 900,209.81.12.134 900,209.81.12.135 900,64.128.87.134 900,64.128.87.135 the MX RRs for clickbank.net are always 900,10,a-mx.coloc8.net 900,20,b-mx.coloc8.net except one recent sighting of the following: 900,10,mx1.clickbank.net 900,10,mx2.clickbank.net there are also A RRs for 3LDs hop, www, ssl, and zzz, plus a 2LD A RR. i hope this helps. it's all courtesy of ISC SIE and our generous sensors, of whom i would welcome more. if you run a recursive nameserver for some population, and are willing to share your upstream server-to-server traffic with ISC for use in security research and operations, plz send me e-mail. -- Paul Vixie
Re: Problems sending mail to yahoo?
At 02:18 PM 4/13/2008, Barry Shein wrote: Is it [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] (very commonly used) or [EMAIL PROTECTED] Who cares? But let's pick ONE, stuff it in an RFC or BCP and try to get each other to conform to it. [EMAIL PROTECTED] 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...
Re: Problems sending mail to yahoo?
Gak, there isn't even a standard code which means MAILBOX FULL or ACCOUNT NOT RECEIVING MAIL other than MAILBOX FULL, maybe by choice, maybe non-payment, as specific as a site is comfortable with. That's what I mean by standards and at least trying to focus on what can be done rather than the endless retelling of what can't be done. 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. Having just watched the gory hashing through of how $MEGAISP deals with filtering on another list, I was amazed that the prevailing stance among mailbox hosters is that they don't really care about principles, and that they mostly care about whether or not users complain. 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. 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. And on the other hand, we have the filtering by statistics, which requires a large userbase and probably a This Is Spam button, where you use a complaint driven model to reject mail, but this is severely complicated because users have also been trained to report as spam any other mail that they don't want, which definitely includes even things that they've opted in to. 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? 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. 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. Addressing standards of the sort you suggest is relatively meaningless in the bigger picture, I think. Nice, but not that important. (*) It's enlightened to hope for standards that would allow remote sites to have some vague concept of what the problem is. I respect that. It just seems to be at odds with current reality. More specific and standardized SMTP failure codes are just one example but I think they illustrate the point I'm trying to make. Oh yeah here's another (ok maybe somewhere this is written down), how about agreeing on contact mailboxes like we did with [EMAIL PROTECTED] Yeah, like that's actually implemented or useful at a majority of domains. Is it [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] (very commonly used) or [EMAIL PROTECTED] Who cares? But let's pick ONE, stuff it in an RFC or BCP and try to get each other to conform to it. Having defined methods for contacting people OOB would be nice. IFF (and often/mostly they don't) anyone cared to actually try to resolve individual problems. Don't expect them to want to, because for the most part, they do not. Sigh. ... 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.
Re: clickbank.net and bundleway.com
This GoogleAd appeared while reading this thread: $400k ClickBank Website - www.AffiliateSiteX.com - Get your very own ClickBank website And let me show you how to push it Thanks, Google! (Link obviously redacted for security reasons.) Leads to www.affiliatesitex.com, which appears to be an alias for www.dollarmonitor.com...which Google is also carrying ads for. Alex
Re: Problems sending mail to yahoo?
On April 13, 2008 at 15:17 [EMAIL PROTECTED] (Rob Szarka) wrote: At 02:18 PM 4/13/2008, Barry Shein wrote: Is it [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] (very commonly used) or [EMAIL PROTECTED] Who cares? But let's pick ONE, stuff it in an RFC or BCP and try to get each other to conform to it. [EMAIL PROTECTED] is *already* specified (in RFC 2142). Thank you. Perhaps that's why I prefaced that paragraph with: Oh yeah here's another (ok maybe somewhere this is written down), how ^^^ about agreeing on contact mailboxes like we did with [EMAIL PROTECTED] but you for some reason elided it. Well, difficult to resist quibbling an example I suppose. -- -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*
Re: Yahoo Mail Update
On Sun, Apr 13, 2008 at 12:58:59AM -0500, Ross wrote: On Thu, Apr 10, 2008 at 8:54 PM, Rich Kulawiec [EMAIL PROTECTED] wrote: I heartily second this. Yahoo (and Hotmail) (and Comcast and Verizon) mail system personnel should be actively participating here, on mailop, on spam-l, etc. A lot of problems could be solved (and some avoided) with some interaction. Why should large companies participate here about mail issues? Last I checked this wasn't the mailing list for these issues: It's got nothing to do with size (large); Joe's ISP in Podunk should be on this lists as well. And one of the reasons I suggested multiple lists is that each has its own focus, so those involved with the care and feeding of mail systems should probably be on a number of them, in order to interact with something approximating the right set of peers at other operations. (Of course not all lists are appropriate for all topics.) But lets just say for a second this is the place to discuss company xys's mail issue. What benefit do they have participating here? Likely they'll be hounded by people who have some disdain for their company and no matter what they do they will still be evil or wrong in some way. They're more likely to be hounded by people who have disdain for their incompetence and the resulting operational issues they impose on their peers. But if they're reluctant to face the unhappiness of their peers -- those whose networks, systems and users are abused on a daily basis and who thus have ample reason to be unhappy -- then maybe they should try something different, such as doing their jobs properly. It is easy for someone who has 10,000 users to tell someone who has 50 million users what to do when they don't have to work with such a large scale enterprise. This is mythology. Someone who can *competently* run a 10,000 user operation will have little-to-no difficulty running a 50 million user operation. (In some ways, the latter is considerably easier.) It's not a matter of the size of anyone's operation, it's a matter of how well it's run, which in turn speaks to the knowledge, experience, diligence, etc. of those running it. ---Rsk
Re: Problems sending mail to yahoo?
On April 13, 2008 at 14:24 [EMAIL PROTECTED] (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
Re: Problems sending mail to yahoo?
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
Re: Yahoo Mail Update
On Sun, Apr 13, 2008 at 3:24 PM, Rich Kulawiec [EMAIL PROTECTED] wrote: On Sun, Apr 13, 2008 at 12:58:59AM -0500, Ross wrote: On Thu, Apr 10, 2008 at 8:54 PM, Rich Kulawiec [EMAIL PROTECTED] wrote: I heartily second this. Yahoo (and Hotmail) (and Comcast and Verizon) mail system personnel should be actively participating here, on mailop, on spam-l, etc. A lot of problems could be solved (and some avoided) with some interaction. Why should large companies participate here about mail issues? Last I checked this wasn't the mailing list for these issues: It's got nothing to do with size (large); Joe's ISP in Podunk should be on this lists as well. And one of the reasons I suggested multiple lists is that each has its own focus, so those involved with the care and feeding of mail systems should probably be on a number of them, in order to interact with something approximating the right set of peers at other operations. (Of course not all lists are appropriate for all topics.) Again I disagree with the principle that this list should be used for mail operation issues but maybe I'm just in the wrong here. Maybe this list is intended for everything internet related, if so I have some complaints I'd like to post about slow download speeds at my current isp. I think maybe there should be a better mission statement to clarify what it is intended for. Again large companies don't need to participate here. They have the user base so you either have to deal with them or block them. Then you have the business decisions of who is going to be more unhappy, their users who can't reach 10k in email accounts or your user base who can't reach 50 million in email accounts. This is the cost of doing business and yes it sucks at times but these choices you have to make as an operator. The businesses that do participate here and on other lists should be commended but it isn't an operational necessity for their business. But lets just say for a second this is the place to discuss company xys's mail issue. What benefit do they have participating here? Likely they'll be hounded by people who have some disdain for their company and no matter what they do they will still be evil or wrong in some way. They're more likely to be hounded by people who have disdain for their incompetence and the resulting operational issues they impose on their peers. But if they're reluctant to face the unhappiness of their peers -- those whose networks, systems and users are abused on a daily basis and who thus have ample reason to be unhappy -- then maybe they should try something different, such as doing their jobs properly. I'll say it again, it is easy to tell someone who has a much larger economy of scale how to do their job properly when you are the small fish in the pond. These guys have a lot of politics in their jobs to deal with so where you may be the sole shot caller in your organization they may have to work through the layers in their organization. I fully believe we could work out some of the operational inefficiencies if I were the only person making decisions but I'm not and that is the reality of big business. It is easy for someone who has 10,000 users to tell someone who has 50 million users what to do when they don't have to work with such a large scale enterprise. This is mythology. Someone who can *competently* run a 10,000 user operation will have little-to-no difficulty running a 50 million user operation. (In some ways, the latter is considerably easier.) It's not a matter of the size of anyone's operation, it's a matter of how well it's run, which in turn speaks to the knowledge, experience, diligence, etc. of those running it. ---Rsk If you say so, I find this comment pretty darn humorous saying 10k users should be easily scalable to 50 million. *sending to list this time -- Ross ross [at] dillio.net 314-558-6455
Re: Yahoo Mail Update
On Sun, Apr 13, 2008 at 5:27 AM, Rob Szarka [EMAIL PROTECTED] wrote: At 01:58 AM 4/13/2008, you wrote: Why should large companies participate here about mail issues? Last I checked this wasn't the mailing list for these issues: True, though some aspects of mail service are inextricably tied to broader networking issues, and thus participation here might still benefit them. But sadly Yahoo doesn't even seem to participate in more relevant forums, such as the spam-l list. Maybe their management or legal has told them not to. I know when I worked for a certain company we were forbidden from replying to operational lists or forums for fear of employees responses being used against the company in court or in the news. But lets just say for a second this is the place to discuss company xys's mail issue. What benefit do they have participating here? Likely they'll be hounded by people who have some disdain for their company and no matter what they do they will still be evil or wrong in some way. I've never seen someone treated badly for trying to help resolve problems. I think we all know that it can be hard to get things done within a large company and that often the folks who participate on a list like this are taking on work that isn't strictly speaking their job when they try to help resolve mail issues. And when a large company that was a mess does a turnaround, they also get praised: just look at the many positive comments about AOL on this and other lists over the past few years. I have seen plenty of people working for isps being abused even when trying to help solve problems, maybe not on this list but definitely on others. In many larger companies people have defined roles and structured goals they need to accomplish or face termination so they may not have time to participate in other venues. Companies that give their management/employees latitude and encourage working in the community should be praised but not all companies are setup this way. If you don't like how yahoo is responding to issues I would suggest sending certified letters to every person in upper management you can find as these people can typically implement changes. It is easy for someone who has 10,000 users to tell someone who has 50 million users what to do when they don't have to work with such a large scale enterprise. I wouldn't presume to tell them how to accomplish something within their particular configuration. But I will, without apology, tell them that they need to accomplish it. For example, I'm quite comfortable saying that Earthlink should follow the minimum timeouts in RFC 1123, though I wouldn't presume to guess whether they should accomplish that by having separate fast and slow queues on different servers, on the same server, or not at all. Likewise, a working abuse role account is a minimum requirement for participation in the Internet email system, and I'm comfortable saying that the email it receives should be read by a competent human. You can tell Earthlink whatever you want but it doesn't mean they need to follow it. Please read my previous reply about business decisions. I would agree that it is good for business to try and follow industry standards but sometimes business decisions need to be made where standards cannot be implemented. I'm not saying that is the case here and it could just be utter incompetence but not everything is black and white. A working abuse account is not the minimum requirement, I can run a mail system without that abuse account but may get blocked from sending mail to certain systems. Read above for my thoughts on standards. With that being said I do believe all companies should have a working abuse email that is appropriately staffed that can respond to complaints within 72 hours. I find it funny when smaller companies always tell larger companies what they need to be doing. When what the larger companies do enables criminal behavior that impacts the very viability of the smaller companies through de factor DoS attacks, it's not funny at all. Yahoo, for example, has chosen a business model (free email with little to no verification) that inevitably leads to spam being originated from their systems. Why should they be able to shift the cost of their business model to me, just because I run a much smaller business? I would say that you may being a bit over dramatic but that may just be me. The cost of their business model isn't shifted to you, you have the choice to block yahoo email from your systems or you have the choice to deal with the issues that comes along with accepting their mail. Comparing this to DoS attacks is just a little bit over the edge to me. -- Ross ross [at] dillio.net 314-558-6455
Fwd: Problems sending mail from .mumble
I was asked to forward this to the list by Eric: Date: Sun, 13 Apr 2008 10:27:40 -0700 From: Eric Brunner-Williams [EMAIL PROTECTED] User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: nanog@merit.edu Subject: Problems sending mail from .mumble Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howdy folks, This isn't as much fun as tracking ships, but at Friday's meeting of ICANN's GNSO Council (think Hairspray) and ICANN staff on the process for new gTLDs, the issue of file suffixes as proposed strings came up. Obviously the people who thought of wildcards (Sitefinder) didn't think through the full joy of the consequences. So this is (yet another) fishing expidition -- as MIME types are a handy list, if any of those strings were present in a header, as in [EMAIL PROTECTED], would any well-known thingee choke? Clues on a clue-by-four. I'll summarize replies off-list (unless requested otherwise) and Thanks in Advance, Eric -- -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*
Re: Problems sending mail to yahoo?
On April 13, 2008 at 14:24 [EMAIL PROTECTED] (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. In many (even most) cases, that is only useful if you're sending a lot of mail towards a single source, a variable which introduces yet *another* ambiguity, since volume is certainly a factor in blocking decisions. Further, if you look at the average mail message, you have domains based on multiple factors, such as services to do open tracking (1x1/invisible pixels, etc), branding, and many other reasons that there could be more than a single domain in a single message. Further, once you're being blocked, it may be implemented by-IP even though there was some other metric that triggered the block. Having records that allow a sender to go back and unilaterally determine what was amiss may not be considered desirable by the receiving site. 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. Do you mean to suggest that your definition of spammer only includes senders using massive bot armies? That'd be mostly pill spammers, phishers, and other really shady operators. There are whole other classes of spam and spammer. 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. I have some idea. However, I will concede that my conception of current spam volumes is based mostly on what I'm able to quantify, which is the ~4-8GB/day of spam we receive here. 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. Actually, we see significant variation in spam received per address. 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. I'm sure that if you were to talk to the Postmasters at any major ISP/mail provider, especially ones like AOL, Hotmail, Yahoo, and Earthlink, that you would discover that they're familiar with businesses which claim to be in the business of enhancing deliverability. However, what I'm saying was pretty much the inverse of the theory that you attribute to me: I'm saying that receivers often do NOT provide feedback detailing the specifics of why a block happened. As a matter of fact, I think I can say that the most common feedback provided in the mail world would be notice of listing on a DNS blocking list, and this is primarily because the default code and examples for implementation usually provide some feedback about the source (or, at least, source DNSBL) of the block. You'll see generic guidance such as the Yahoo! error message that started this thread (temporarily deferred due to user complaints, IIRC), but that's not particularly helpful, now, is it. It doesn't tell you which user, or how many complaints, etc. 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? Because there are businesses out there that claim to do that very sort of thing, except that they do it by actually sending mail and then checking canary e-mail boxes on the receiving site to measure effectiveness of their delivery strategy. Failures result in further tuning. Being able to simply analyze error messages would result in a huge boost for their effectiveness, since they would essentially be able to monitor the deliverability of entire mail runs, rather than assuming that the deliverability percentage of their canaries, plus any open tracking,
Re: Problems sending mail to yahoo?
At 04:41 PM 4/13/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? I'm not sure I know what you mean. Are you talking about the optional feedback loop? When I was signed up for that I did get a bunch of bogus reports, but other than that I've never received a spam report from AOL at all. The reason abuse@ addresses are useless is because what is being sent to them is useless. I'm sure that a lot of useless reports come in--my servers never originate spam, but we still get the occasional bogus report due to forged headers. At the same time, I certainly send dozens of real spam reports every day and they all contain actionable information (that would be supplemented further if an actual human were to ask). What I've found is that too big to fail ISPs respond (if they accept the email at all!) with either an automated response or a canned response from a help desk monkey who is actually wrong close to half the time, while many boutique providers and most US-based .edu sites respond personally and cluefully. (Don't get me started about the US government, especially the military...) My conclusion is that the problem is not crappy reports but rather under-investment in clue at big ISP help desks. All the fancy standards and tools in the world are not going to help this basic problem: stemming the tide of abuse from their networks is simply not a high enough priority for companies like Yahoo, Hotmail, ATT, et al. Until they start losing money every time spam leaves their network, I don't see their behavior changing.
Re: Problems sending mail to yahoo?
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
RE: Problems sending mail to yahoo?
FBi Date: Sat, 12 Apr 2008 15:42:29 -0500 FBi From: Frank Bulk - iNAME FBi Sounds like the obvious thing to tell customers complaining about FBi their e-mail not getting to Yahoo! is to tell them that Yahoo! FBi doesn't want it. Obviously. That's when the client asked if their servers (perhaps I should have been more clear) could be configured not even to attempt sending mail to Yahoo. If it's not going to get there, anyway, can we just block it when it's sent? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
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*
RE: Problems sending mail to yahoo?
I agree that they aren't completely useless. From our environment the abuse desks can be somewhat overwhelmed though. If you setup feedback loops for networks size of 1x /16 2x /17 2x /18 1x /19 to receive abuse complaints on dedicated / collocated customers you do get a some good complaints. Some of the time it is from compromised scripts, sometimes actual spammers, but most of the time it is from forwarded spam. This makes the abuse desk full of thousands and thousands of complaints. You can look in the headers of the spam complaints and see that it is forwarded spam, but it is still overhead. So signing up for a feedback loop for the entire network with something like Yahoo! can be burdensome and make abuse@ full of useless complaints. This isn't the problem I suppose in most environments, but it is in mine. Yahoo! blocking entire /24's are not necessarily a large problem, the larger problem is A. they don't tell you when it is blocked (I don't believe it would be hard to email the abuse@ contact of the IP address range..) B. their 'Bulk Mail Advocates' say they cannot tell what IP's are generating the /24 block once it is in place (perhaps it can be prior to the block?). C. They offer no way to exempt certain IP addresses to be exempted from the /24 'de-prioritization'. This means the smaller companies who send maybe 3 or 4 emails to Yahoo a day are having difficulty and there's nothing you can do until the issue with the entire /24 is solved. Administrators who actually find ways to get in touch with Yahoo to resolve issues are hindered by Yahoo's stance of 'It's coming from your network, you should be able to monitor it and figure it out'. In a dedicated/colo environment I don't think it is really reasonable to expect companies login to each server in a /24 to see who is sending mail to Yahoo. And even if they are sending mail to Yahoo were not psychic so we cannot tell what their users are marking as spam and what's not. I suppose the feedback loop would say that but...then abuse@ is flooded with complaints that are mostly mutual customers fault. Chances are if a server is sending spam to Yahoo they are sending it to quite a few other places as well which do actively report it. -Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Dennis Sent: Sunday, April 13, 2008 7:16 PM To: Geo. Cc: nanog@merit.edu Subject: Re: Problems sending mail to yahoo? 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
Re: Problems sending mail to yahoo?
On Apr 13, 2008, at 5:04 PM, Barry Shein wrote: 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. Address mobility doesn't buy you that much. It's relatively easy to mechanically detect, and block, IP addresses that source mail solely from spam- related botnets. (Not easy in the absolute sense, but easier than other problems and, mostly, a solved one). Botnet sourced mail generally doesn't get seen much by recipients at ISPs with competent spam filtering. It sure can cause other operational problems, but in terms of being a spam problem it's not the biggest one out there. Blocking unwanted mail from sources that send a mixture of wanted and unwanted mail, while still allowing the wanted mail through is extremely difficult, and a much, much harder problem for spam mitigation to solve. And those are primarily the non-botnet sources. Spam filtering at real ISPs with real recipients has to deal with the fact that recipients do want to read some of the mail they're sent from Gmail, Yahoo Groups, Topica and suchlike. Cheers, Steve
the O(N^2) problem
Bottom line first: We need OOB metadata (trust/distrust) information exchange that scales better than the current O(N^2) nonsense, yet is not PKI. And now, the details... which ended up longer reading than I intended. My apologies. As Mark Twain said, I didn't have time to write a short letter, so I wrote a long one instead. :-) When it comes to establishing trust: * The current SMTP model is O(N^2); * I posit that the current IP networking model is sub-O(N); * PKI models are pretty much O(1). Polynomial-order just doesn't scale well. It's mathematical fact, and particularly painful when the independent variable is still increasing quickly. Many operators seem to reject PKI as power in too few hands. I'll not disagree with that. Conclusion: What we need is something that scales better than O(N^2), but that is not as few trusted keepers of the world as PKI. Let's look to one of the current hot tickets: social networking. Who is whose friend, who is in whose network, blah blah blah. (The junior high students seem to grok the concept of trust being semi-transitive!) Let's also draw upon operational lessons from a couple old-timers. I recall using a critter known as NNTP. And once upon a time, before my days on the Internet, lived a funny little beast called UUCP. We track email quality from all mailservers that hit us. I can whip up a list of MXes/organizations that I'm willing to trust -- and let's leave that term imprecisely-defined for now. Here's what I propose: Establish a distrust protocol. Let path weight be distrust. The trust path is of secondary importance to path weight, although not completely irrelevant. SMTP endpoint not in graph? Fine; have some default behavior. Let _trust_ be semi-transitive, a la BGP -- a technology that we know, understand, and at least sort of trust to run this crazy, giant network that dwarfs even a 50M-user provider. Let actual _content_ still be end-to-end, so that we do not simply reincarnate NNTP or UUCP. Alternatively: I'm open to other suggestions. Or, there's plan C: We continue to argue, banter, carp, fuss, grumble, moan, swear, whine, et cetera (I decided against running the alphabet) over the problem. Hey, it's worked/working great so far, right? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Problems sending mail to yahoo?
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
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. 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
Re: Problems sending mail to yahoo?
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. :) Adrian
Re: Problems sending mail to yahoo?
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.
Re: the O(N^2) problem
Another alternative is something we've been working on that we call Perspectives: http://www.cs.cmu.edu/~dwendlan/perspectives/ Warning: This is a work in progress. The Mozilla plugin is a little flaky and the paper is still being revised for the final revision for USENIX. The SSH code works pretty well. We haven't written an SMTP version yet. The basic idea is pretty simple: Use multiple paths to a destination to figure out if you're likely getting to the right place. If you _and_ your friends all observe the same public key from a server, preferably for a long period of time, then trust it. Else scream bloody murder. Perspectives provides these friends in the form of notary servers who you can ask about the past and present keys supplied by an SSL or SSH server. (An alternate way of viewing this is to think of Perspectives as a low- overhead, low-cost PKI.) It's an interesting thought exercise to wonder if we could extend the model to trust not to send spam instead of simply trust to be the owner of the key, but that same exercise applies with a PKI, too. -Dave On Apr 13, 2008, at 8:36 PM, Edward B. DREGER wrote: Bottom line first: We need OOB metadata (trust/distrust) information exchange that scales better than the current O(N^2) nonsense, yet is not PKI. And now, the details... which ended up longer reading than I intended. My apologies. As Mark Twain said, I didn't have time to write a short letter, so I wrote a long one instead. :-) When it comes to establishing trust: * The current SMTP model is O(N^2); * I posit that the current IP networking model is sub-O(N); * PKI models are pretty much O(1). Polynomial-order just doesn't scale well. It's mathematical fact, and particularly painful when the independent variable is still increasing quickly. Many operators seem to reject PKI as power in too few hands. I'll not disagree with that. Conclusion: What we need is something that scales better than O(N^2), but that is not as few trusted keepers of the world as PKI. Let's look to one of the current hot tickets: social networking. Who is whose friend, who is in whose network, blah blah blah. (The junior high students seem to grok the concept of trust being semi-transitive!) Let's also draw upon operational lessons from a couple old-timers. I recall using a critter known as NNTP. And once upon a time, before my days on the Internet, lived a funny little beast called UUCP. We track email quality from all mailservers that hit us. I can whip up a list of MXes/organizations that I'm willing to trust -- and let's leave that term imprecisely-defined for now. Here's what I propose: Establish a distrust protocol. Let path weight be distrust. The trust path is of secondary importance to path weight, although not completely irrelevant. SMTP endpoint not in graph? Fine; have some default behavior. Let _trust_ be semi-transitive, a la BGP -- a technology that we know, understand, and at least sort of trust to run this crazy, giant network that dwarfs even a 50M-user provider. Let actual _content_ still be end-to-end, so that we do not simply reincarnate NNTP or UUCP. Alternatively: I'm open to other suggestions. Or, there's plan C: We continue to argue, banter, carp, fuss, grumble, moan, swear, whine, et cetera (I decided against running the alphabet) over the problem. Hey, it's worked/working great so far, right?
trust networks (Re: Problems sending mail to yahoo?)
AC Date: Mon, 14 Apr 2008 10:18:40 +0800 AC From: Adrian Chadd AC There already has been a paradigm shift. University students AC (college for you 'merkins) use facebook, myspace (less now, AC thankfully!) and IMs as their primary online communication method. IOW: Must establish trust OOB before communication is allowed. Deny-by-default is not a panacea, to be sure. Accept-by-default? Seemingly the greater of the evils. Providers and end-users alike both are using ad-hoc methods to deal with spam as best they can. United we stand, divided we fall, yadda yadda. Here's a thought: Google has massive resources. Their searches deal extensively with graph theory, traversal, et cetera. Is it any wonder that they launched Orkut? And why Gmail required an invite for so long? Ever consider that a Gmail username found reading a Blogspot blog might be considered a sign of similar interest, perhaps even trust? It takes neither a rocket scientist nor a conspiracy theorist to conclude that Google is working on the trust network problem internally. Others probably are as well; I merely chose a high-profile example. I'll say it again: Providers would be well-served to create _some_ form of trust metric and data exchange. If anyone is interested in cooperating with data formats, source code, other efforts, kooky ideas, or insults, please ping me off-list. It might not lead to anything useful or of critical mass, but it has a better chance than endless regurgitation of (S^2)(D^2) on NANOG-L. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Problems sending mail to yahoo?
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.
Re: Problems sending mail to yahoo?
SL Date: Mon, 14 Apr 2008 14:47:12 +1200 (NZST) SL From: Simon Lyall SL The question is what tool are people going to use to talk to people, SL government bodies and companies that they are not friends with? SL Even if the person you want to contact is on IM it is likely they SL will block messages from random people due to the existing Spam SL problem there. Hence the need for semi-transitive trust. What tool do people use to exchange packets with networks with which they are not peers? We've already solved some of the same underlying principles. Red car, blue car; both are built the same. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Problems sending mail to yahoo?
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
Re: Problems sending mail to yahoo?
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 .. Adrian
Re: Problems sending mail to yahoo?
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. [EMAIL PROTECTED] 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.
Re: Problems sending mail to yahoo?
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. That underlying security problem gives us many symptoms: spam, phishing, typosquatting, DDoS attacks, adware, spyware, viruses, worms, data loss incidents, web site defacements, search engine gaming, DNS cache poisoning, and a long list of others. Dealing with symptoms is good: it makes the patient feel better. But it shouldn't be confused with treatment of the disease. Even if we could snap our fingers and stop all spam permanently tomorrow (a) it wouldn't do us much good and (b) some other symptom would evolve to fill its niche in the abuse ecosystem. 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. ---Rsk
Re: Problems sending mail to yahoo?
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.
Re: the O(N^2) problem
On Apr 13, 2008, at 5:36 PM, Edward B. DREGER wrote: Bottom line first: We need OOB metadata (trust/distrust) information exchange that scales better than the current O(N^2) nonsense, yet is not PKI. Not sure why PKI should be excluded, but, so far, this is too abstract to know what the question is... And now, the details... which ended up longer reading than I intended. My apologies. As Mark Twain said, I didn't have time to write a short letter, so I wrote a long one instead. :-) When it comes to establishing trust: * The current SMTP model is O(N^2); I don't see SMTP as even a trust model since there's pretty much nothing trustworthy in SMTP. * I posit that the current IP networking model is sub-O(N); Again, I'm not seeing IP as a trust model, but, YMMV. * PKI models are pretty much O(1). Polynomial-order just doesn't scale well. It's mathematical fact, and particularly painful when the independent variable is still increasing quickly. Sure. Many operators seem to reject PKI as power in too few hands. I'll not disagree with that. Depends on the PKI. For example, the PGP/GPG Web of Trust concept pretty much lets each individual build their own trust model to whatever O(x) they choose where greater values of x require more effort and also provide greater security/trust granularity and lower values of x involve greater trust of others that you claim you can trust and less direct effort on your part. Let's also draw upon operational lessons from a couple old-timers. I recall using a critter known as NNTP. And once upon a time, before my days on the Internet, lived a funny little beast called UUCP. I remember UUCP. It was pretty much O(n^2). We track email quality from all mailservers that hit us. I can whip up a list of MXes/organizations that I'm willing to trust -- and let's leave that term imprecisely-defined for now. Uh, OK. Starting to understand what the question might be aiming towards. Here's what I propose: Establish a distrust protocol. Let path weight be distrust. The trust path is of secondary importance to path weight, although not completely irrelevant. SMTP endpoint not in graph? Fine; have some default behavior. Let _trust_ be semi-transitive, a la BGP -- a technology that we know, understand, and at least sort of trust to run this crazy, giant network that dwarfs even a 50M-user provider. Let actual _content_ still be end-to-end, so that we do not simply reincarnate NNTP or UUCP. Now I'm lost again. You've mixed so many different metaphors from interdomain routing to distance-vector computaton to store-and-forward that I simply don't understand what you are proposing or how one could begin to approach implementing it or what problem you seem to think it solves (although it sort of seems like you're wanting to attack the trustworthiness of email to battle SPAM through some mechanism that depends only on the level of trust for the (source, arrival path) tuple from whence it came. What am I missing? Owen
Re: Problems sending mail to yahoo?
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
Re: the O(N^2) problem
On Mon, Apr 14, 2008 at 10:34 AM, Owen DeLong [EMAIL PROTECTED] wrote: Now I'm lost again. You've mixed so many different metaphors from interdomain routing to distance-vector computaton to store-and-forward that I simply don't understand what you are proposing or how one could begin to approach implementing it or what problem you seem to think it solves (although it sort of seems like you're wanting to attack the trustworthiness of email to battle SPAM through some mechanism that depends only on the level of trust for the (source, arrival path) tuple from whence it came. Looks like what various people in the industry call a reputation system
