Re: Problems sending mail to yahoo?
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. this presumes non-inventive spammers, which i fear is not the case. but it sure would be a good place to start :) randy
RE: Problems sending mail to yahoo?
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. Hear, hear! You want to define standards? Let's define some standard for establishing permission to mail. If we could solve the permission problem, then the filtering wouldn't be such a problem, because there wouldn't need to be as much (or maybe even any). As a user, I want a way to unambiguously allow a specific sender to send me things, spam filtering be damned. I also want a way to retract that permission, and have the mail flow from that sender (or any of their affiliates) to stop. Right now I've got a solution that allows me to do that, but it requires a significant paradigm change, away from single-e-mail-address. In general, your permission to send idea is a good one to put in the requirements list for a standard email architecture. But your particular solution stinks because it simply adds another bandage to a creaky old email architecture that is long past its sell-by date. IMHO, the only way that Internet email can be cleaned up is to create an entirely new email architecture using an entirely new set of protcols with entirely new port assignments and no attempt whatsoever to maintain reverse compatibility with the existing architecture. That is a fair piece of work and requires a lot of people to get their heads out of the box and apply some creativity. Many will say that the effort is doomed before it starts because it is not compatible with what went before. I don't buy that argument at all. In any case, a new architecture won't come about until we have some clarity of the requirements of the new architecture. And that probably has to be hashed out somewhere else, not on any existing mailing list. --Michael Dillon
Re: Problems sending mail to yahoo?
You want to define standards? Let's define some standard for establishing permission to mail. If we could solve the permission problem, then the filtering wouldn't be such a problem, because there wouldn't need to be as much (or maybe even any). As a user, I want a way to unambiguously allow a specific sender to send me things, spam filtering be damned. I also want a way to retract that permission, and have the mail flow from that sender (or any of their affiliates) to stop. Right now I've got a solution that allows me to do that, but it requires a significant paradigm change, away from single-e-mail-address. In general, your permission to send idea is a good one to put in the requirements list for a standard email architecture. But your particular solution stinks because it simply adds another bandage to a creaky old email architecture that is long past its sell-by date. Yes. I'm well aware of that. My requirements list included that my solution be able to actually /fix/ something with /today's/ architecture; this is a practical implementation to solve a real problem, which was that I was tired of vendor mail being confused for spam. So, yes, it stinks when compared to the concept of a shiny new mail architecture. However, it currently works and is successfully whitelisting the things I intended. I just received a message from a tool battery distributor that some batteries I ordered months ago are finally shipping. It was crappy HTML, and I would normally have completely missed it - probably even forgetting that we had ordered them, certainly not recognizing the From line it came from. It's a success story. Rare. You are welcome to scoff at it as being a stinky bandaid on a creaky mail system. IMHO, the only way that Internet email can be cleaned up is to create an entirely new email architecture using an entirely new set of protcols with entirely new port assignments and no attempt whatsoever to maintain reverse compatibility with the existing architecture. That is a fair piece of work and requires a lot of people to get their heads out of the box and apply some creativity. Many will say that the effort is doomed before it starts because it is not compatible with what went before. I don't buy that argument at all. In any case, a new architecture won't come about until we have some clarity of the requirements of the new architecture. And that probably has to be hashed out somewhere else, not on any existing mailing list. If such a discussion does come about, I want people to understand that user-controlled permission is a much better fix than arbitrary spam filtering steps. There's a lot of inertia in the traditional spam filtering advice, and a certain amount of resistance to considering that the status quo does not represent e-mail nirvana. Think of it as making that unsubscribe at the bottom of any marketing e-mail actually work, without argument, without risk. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
[admin] RE: Problems sending mail to yahoo?
Folks, Can we wrap the mail threads up or at least move them over to their respective best-places like zorch, nsp-sec, spam-l, asrg, or yet-another-favorite-list-for-spam-religion? We've gone far beyond typical mass-mail operations. Best Regards, Marty -- Martin Hannigan http://www.verneglobal.com/ Verne Global Datacenters e: [EMAIL PROTECTED] Keflavik, Icelandp: +16178216079
Re: /24 blocking by ISPs - Re: Problems sending mail to yahoo?
(all opinions below my own... comments are intended to address a number of points made previously in this extended thread, by rick and others) are you saying you don't consider the sending ip address or the envelope sender or the envelope recipient to be a. useful for spam detection b. personally identifiable information having done quite a lot of spam filtering (and having worked on big mail before, e.g. on the original AOL internet gateways) i think they are in both categories. (the HELO strings can be pretty useful also)... the scale of mail at yahoo, gmail, hotmail, aol (maybe brightmail and postini, too) is well beyond the numbers anyone else here is citing. i can assure you there are lots of smart and caring people working on problems of mail abuse (both incoming from the internet and outgoing, too). both of these cost us a lot of money, and we know it. yahoo receives 500M visitors per month, and collects about 25 TB of logs every day. analyze that! my understanding is the chinese govt has specific requirements regarding logging and log retention that are compulsory for any company with servers in china. europe and other countries are trying to promulgate laws about log retention. logs cut both ways, by the way. they can be exculpatory as well, particularly in the case of a phished or cracked account used for something illegal. with the ip addresses of the abuse, the defense can assert that the account owner was not whodunit. with no logs, it's much harder to substantially defend against the govt in such cases, presumption of innocence notwithstanding. on the original issue (as i work for yahoo, but in the security group, not in mail), we *do* try to follow the lists, at least as lurkers. as a big and public company, somewhat in the spotlight from time to time, we are restricted from making statements that could be misinterpreted as speaking for the company without going through various approval channels. i summarized the substantive bits of this thread for yahoo mail management for their comments, and particularly seconding the suggestion that yahoo provide more transparency to isps to make it possible for them to clean/keep clean their own houses. there is dialog going on about improving the process so it's more predictable and less frustrating for ISPs. the forms really do work, they tell me. (not fast enough for you, we hear clearly.) (i just hope more transparency doesn't make things easier for, say, the Russian Business Network or the Storm gang.) on the question of greylisting, you're right that there are delays imposed on senders of email who are perceived as spam senders but first connect fails greylisting is not used. the documentation could be improved. (all documentation, except guy steele's or mary claire van leunen's, could be improved.) unfortunately, we're all pretty much in the same boat on this one, so let's not fight about it (at least, don't fight with me...) On Apr 12, 2008, at 7:08 PM, Rich Kulawiec wrote: On Sat, Apr 12, 2008 at 09:36:43AM -0700, Matthew Petach wrote: *heh* And yet just last year, Yahoo was loudly dennounced for keeping logs that allowed the Chinese government to imprison political dissidents. Talk about damned if you do, damned if don't... But those are very different kinds of logs -- with personally identifiable information. I see a sharp difference between those and logs which record (let's say) SMTP abuse incidents/attempts by originating IP address. ---Rsk
Re: Problems sending mail to yahoo?
On Thu, Apr 10, 2008 at 10:30 AM, Barry Shein [EMAIL PROTECTED] wrote: SNIP 421 4.7.0 [TS01] Messages from MAILSERVERIP temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html (where MAILSERVERIP is one of our mail server ip addresses) Domainkeys solved my problem. I had the exact same thing happen, sometimes it wouldn't even make it to the box. Setup domain keys, and my problem went away.
Re: Fwd: Problems sending mail from .mumble
On Sun, 13 Apr 2008 17:50:25 EDT, Barry Shein said: 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? As a practical matter, 'bar.mime-type' had better be a proper DNS entry, or a lot of places that do a is the address at least putatively returnable? test (which *should* be essentially 100% - does anybody *not* check this?), they will find it won't go very far. As a second practical matter, I suspect that all the places that have already decided that '*.biz' is a cesspool will be even more dubious accepting mail from '[EMAIL PROTECTED]'. I'm still trying to figure out if this was for real, or if it was intended to be posted 2 weeks ago and ICANN bureaucracy delayed it... ;) pgpu8VQSRann1.pgp Description: PGP signature
Re: Problems sending mail to yahoo?
On Sun, 13 Apr 2008, Barry Shein wrote: For example, and it's only an example don't quibble the example, defining a list of return SMTP codes which are actually specific and meaningful like (let's assume they should be 5xx, maybe 7xx would be a better start? Policy failure codes) [...] and so on, a taxonomy which could then at least be dealt with intelligently by sending MTAs and supporting software rather than each side cooking up their own stuff. See RFC 3463. Unfortunately it doesn't help much to solve the problem it was designed for. I ranted about this a while back... http://www.ietf.org/mail-archive/web/ima/current/msg00588.html Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ BAILEY: NORTHWESTERLY 6 TO GALE 8, VEERING SOUTHEASTERLY 4 OR 5. MODERATE OR ROUGH. RAIN OR SHOWERS, THEN FAIR. MODERATE OR GOOD.
nanog volume (was: Problems sending mail to yahoo?)
Can we wrap the mail threads up actually, i am still learning from some of them. i have a hypothesis to add nanog list volume is proportional to S + E where S is the amount of Slack time the active members have and E is the existence of a significant Event in the absence of a significant event, volume is directly driven by the amount of free time we have at the tube. as there is no event to discuss, we will discuss whatever is kinda interesting, often the same subjects. after all, this is a discussion forum, not a current news desk. if an operational event ocurrs, discussion of it quickly predominates over the S component. if we could watch this happening, we might even learn something interesting about information flow in our culture, as the wavefront of the E information causes posters attention to move. and, in the absence of an E, and S being diverted to to actual paid work, volume goes down. as pfs mentioned this eve, some time in the last months, the shortage of E and S was so severe that someone posted an is the list working test message. randy
Re: Fwd: Problems sending mail from .mumble
On Mon, 14 Apr 2008 08:47:04 PDT, Eric Brunner-Williams said: The issue is whether exe in the root will break something. Rather than just ask for a few well-known suffixes, and forgetting some, and leaving out ps as it is already assigned to a ccTLD, I've picked on the MIME-TYPE set of labels. Are you asking about actual MIME times 'text.plain', 'application.ps', and so on, or are you asking about the labels that one popular operating system sometimes uses to denote them, such as .exe, .ps and so on? Some of us use systems that don't insist on extensions - and the major one that does has a history of doing so poorly (how many times have we seen something with a name of foo.exe labelled an image/jpg and ending up executed rather than displayed?) pgppoPN5VRUrE.pgp Description: PGP signature
RE: nanog volume (was: Problems sending mail to yahoo?)
-Original Message- From: Randy Bush [mailto:[EMAIL PROTECTED] Sent: Monday, April 14, 2008 12:56 PM To: Martin Hannigan Cc: nanog@merit.edu Subject: nanog volume (was: Problems sending mail to yahoo?) Can we wrap the mail threads up actually, i am still learning from some of them. Great, I'll stop the world. -M
Re: Fwd: Problems sending mail from .mumble
On Mon, Apr 14, 2008 at 11:17 AM, [EMAIL PROTECTED] wrote: On Sun, 13 Apr 2008 17:50:25 EDT, Barry Shein said: 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? As a practical matter, 'bar.mime-type' had better be a proper DNS entry, or a lot of places that do a is the address at least putatively returnable? test (which *should* be essentially 100% - does anybody *not* check this?), they will find it won't go very far. It's got some interesting implications if it's: domain.exe ... 'did you mean to go to domain.exe or execute domain.exe or display domain.pdf ?' the UI folks will have a headache with that I bet... I could see a rule set (simplified) like: 1) if -f domain.exe -x domain.exe ; then exec(domain.exe) 2) if ! -f domain.exe ; then openlocation(domain.exe) that would be fun in the world of site-finder, eh? I wonder what word or excel or '$application' does with a random blob of html foo shoved down it's throat?? Is it still the case that folks thinking about site-finder believe 'all the world is a web-browser' ??? Seriously? As a second practical matter, I suspect that all the places that have already decided that '*.biz' is a cesspool will be even more dubious accepting mail from '[EMAIL PROTECTED]'. and here I took the 'bar.mime-type' to be: domain.exe or domain.mp3 or domain.pdf ... Barry, which do you mean? (or which did Eric mean)
Re: Fwd: Problems sending mail from .mumble
On 2008-04-14, Christopher Morrow [EMAIL PROTECTED] wrote: It's got some interesting implications if it's: domain.exe ... 'did you mean to go to domain.exe or execute domain.exe or display domain.pdf ?' the UI folks will have a headache with that I bet... I could see a rule set (simplified) like: It doesn't seem to be a big problem for .com...
Re: Fwd: Problems sending mail from .mumble
On Mon, Apr 14, 2008 at 3:05 PM, Stuart Henderson [EMAIL PROTECTED] wrote: On 2008-04-14, Christopher Morrow [EMAIL PROTECTED] wrote: It's got some interesting implications if it's: domain.exe ... 'did you mean to go to domain.exe or execute domain.exe or display domain.pdf ?' the UI folks will have a headache with that I bet... I could see a rule set (simplified) like: It doesn't seem to be a big problem for .com... oh I've been away from dos for too long (not long enough??)... so sure maybe this isn't a problem :) or maybe the load from .com-ish things isn't enough to notice? -Chris
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: 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: 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: 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: 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
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?
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.) Sure. Anyone could do this. It's trivial. Perhaps there's a reason that virtually no one implements something like this. (Hm!) 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. I'm currently working towards a model where I deploy an address per site, which isn't a single-use model by any means. As a matter of fact, it's a model that allows that address to be shared (even abusively) by the senders, but at the point I decide to revoke permission, permission goes away for _everyone_ sending to that address. So it _is_ disposable, in the conventional sense. It brings the permission control aspect back squarely under my control, not under some random ESP's decision about whether or not to send to me. Consider the benefits for deliverability if a major ISP implemented something like this. Provide a facility for users to be able to get disposable addresses (preferably ones where the disposable portion could be handled prior to hitting the mail server, i.e. in DNS), and then guarantee to both users and senders that no mail sent to these addresses would be subject to spam filtering, rate limits, or other arbitrary things, on the basis that the subscriber clearly asked for the material. Revocation of permission would be available to the user, through the simple process of eliminating the DNS record for that particular disposable address. Quite frankly, this is almost the scenario that started me on this in the first place, because I was having such a devil of a time with getting our anti-spam measures to not trip on invoices and other legitimate stuff that arrives here, much of which is nearly indistinguishable, at the machine level, from spam. Despite being a viable solution to a large portion of the e-mail deliverability puzzle, my best guess is that no ISP actually wants to incur the cost and support hit of trying to get their users to use such a system. The current system, where users simply sigh and accept that they may not get their e-mail, is apparently preferable. It's certainly easier. Lower the expectations rather than try to fix the problem. That's fine, but then I'd really like them to be honest about it, and just admit that they're not so concerned about actually delivering desired mail as they are about keeping their costs as low as possible (etc.) Addressing standards of the sort you suggest is relatively meaningless in the bigger picture, I think. Nice, but not that important. Well, first you'd have to indicate that you actually have a view of the problem which supports such a judgment. At any rate you're quibbling the example as I forewarned. But standardizing receiving MTA fail codes is, I suspect, more useful than you give them credit. It would be some progress at little to no cost in the large. By all means, then. Go ahead. You'll amaze me if you can actually get this implemented at any major ISP or mailbox provider. It would be nice for my cold and cynical viewpoints to be disproven, rather than to be proven as too optimistic. It deals less with spam filtering and more with effective MTA to MTA operation. That's not how the large ISP/mailbox providers will see it. At least it's sticking to the realm of improving standards in a way that can be accomplished. I don't see how I could have given a better example without a lot of hand-waving and vagaries. Look, I certainly agree that it'd be *nice*, but there are lots of things that are *nice* that aren't going to happen. Shall we beat the BCP38 horse any further? There's a long history of things that would be nice that never come to pass. I've already written off reliable deliverability at large ISP's as one of those things. I'm now looking towards solutions to enable reliable deliverability at smaller sites where principles might still matter enough that people haven't completely written off e-mail as unusable. ... 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: 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
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 codes
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.
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: 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: /24 blocking by ISPs - Re: Problems sending mail to yahoo?
On 4/11/08, Raymond L. Corbin [EMAIL PROTECTED] wrote: It's not unusual to do /24 blocks, however Yahoo claims they do not keep any logs as to what causes the /24 block. If they kept logs and were able to tell us which IP address in the /24 sent abuse to their network we would then be able to investigate it. Their stance of 'it's coming from your network you should know' isn't really helpful in solving the problem. When an IP is blocked a lot of ISP's can tell you why. I would think when they block a /24 they would atleast be able to decipher who was sending the abuse to their network to cause the block and not simply say 'Were sorry our anti-spam measures do not conform with your business practices'. Logging into every server using a /24 is looking for needle in a haystack. *heh* And yet just last year, Yahoo was loudly dennounced for keeping logs that allowed the Chinese government to imprison political dissidents. Talk about damned if you do, damned if don't... I guess logs should only be kept as long as they can only be used for good, and not evil? Matt -Ray
Re: /24 blocking by ISPs - Re: Problems sending mail to yahoo?
On Sat, Apr 12, 2008 at 09:36:43AM -0700, Matthew Petach wrote: *heh* And yet just last year, Yahoo was loudly dennounced for keeping logs that allowed the Chinese government to imprison political dissidents. Talk about damned if you do, damned if don't... But those are very different kinds of logs -- with personally identifiable information. I see a sharp difference between those and logs which record (let's say) SMTP abuse incidents/attempts by originating IP address. ---Rsk
RE: Problems sending mail to yahoo?
Sounds like the obvious thing to tell customers complaining about their e-mail not getting to Yahoo! is to tell them that Yahoo! doesn't want it. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edward B. DREGER Sent: Friday, April 11, 2008 2:44 PM To: nanog@merit.edu Subject: Re: Problems sending mail to yahoo? JA Date: Fri, 11 Apr 2008 10:22:11 -0400 JA From: Joe Abley JA To return to the topic at hand, you may already have outsourced the JA coordination of your boycott to Yahoo!, too! They're already not JA accepting your mail. There's no need to stop sending it! :-) Except for queue management. I just got off the phone with one client who requested precisely: Can you just have [the servers] refuse to send mail to Yahoo? 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?
dear coo/ceo/whomever: i want approval to send the five folk who go to nanog, and the five folk who go to maawg, and the five folk who go to first to *all* go to the new frobnitz joint conference. think that'll fly? Why not? We already solved that problem for the five folk who go to the ARIN meetings. --Michael Dillon P.S. Thinking out of the box would suggest that the person funding these conference trips should force people to rotate the conferences that they go to. Want to get approval to go to another NANOG? Then you have to attend the next MAAWG and the next FIRST conference before you can attend NANOG again. It is now standard enterprise practice to rotate their best managers through various different functions of the company. Why don't we do this with some of the technical management functions as well?
Re: Problems sending mail to yahoo?
Joe Greco wrote: So it's a vast sea of security by obscurity and standards be damned. It's a real and serious failure of the IETF et al. ... Having nearly given up in disgust on trying to devise workable anti-spam solutions that would reliably deliver requested/desired mail to my own mailbox, I came to the realization that the real problem with the e-mail system is so fundamental that there's no trivial way to save it. 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. Add a few local customizations (I know, this is the time consuming part), IP-layer IDS, stir carefully and voila, spam to real mail ratios well below 1 to 100. All without big junk folders, with very rare false positives, and little or no effort on the part of end-users. 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. Not that spam really has much to do with network operations, well, except perhaps for those pesky Netcool/Openview/Nagios alerts... Roger Marquis
Re: Problems sending mail to yahoo?
On 10 Apr 2008, at 23:58 , Rob Szarka wrote: At 02:23 PM 4/10/2008, you wrote: Maybe we all should do the same to them until they quit spewing out all the Nigerian scams and the like that I've been seeing from their servers lately! If there were an coordinated boycott, I would participate. Yahoo is *by far* the worst single abuser of our server among the legitimate email providers. Having done my own share of small-scale banging-of-heads-against-yahoo recently, the thing that surprised me was how many people with non- yahoo addresses had their mail handled by yahoo. It turns out that if Y! doesn't want to receive mail from me, suddenly I can't send mail to anybody in my extended family, or to most people I know in the town where I live. These involve domains like ROGERS.COM and BTINTERNET.COM, and not just the obvious Y! domains. In my more paranoid moments I have wondered how big a market share Y! now has in personal e-mail, given the number of large cable/telcos who have outsourced mail handling to them for their residential products. Once you pass a certain threshold, the fact that Y! subscribers are the only people who can reliably deliver mail to other Y! subscribers provides a competitive advantage and a sales hook to make the resi mail empire even larger. At that point it makes no sense for Y! to expend effort to accept *more* mail from subscribers of other services. To return to the topic at hand, you may already have outsourced the coordination of your boycott to Yahoo!, too! They're already not accepting your mail. There's no need to stop sending it! :-) Joe
Re: Problems sending mail to yahoo?
On Thu, Apr 10, 2008 at 11:58:05PM -0400, Rob Szarka wrote: I report dozens of spams from my personal account alone every day and never receive anything other than automated messages claiming to have dealt with the same abuse that continues around the clock or, worse, bogus/clueless claims that the IP in question is not theirs and suggestions that I check the same ARIN database that I used to confirm the responsible party in the first place. I gave up sending abuse reports to Yahoo (and Hotmail) many years ago. All available evidence strongly indicates that there is nobody there who understands them, is capable of taking effective action, or cares to take any effective action. That evidence includes not just their complete failure to control outbound abuse, but their ill-advised and ineffective attempts to control inbound abuse (as we see in this thread), their complete failure to participate in abuse forums such as Spam-L, their complete failure to shut down spammer/phisher domains they're hosting, and their complete failure to shut down spammer/phisher dropboxes they're providing. Sadly, Google's Gmail appears to be on the first steps down this same path. I had hoped for a display of markedly higher clue level from them, but -- for whatever reason -- it hasn't manifested itself yet. So in the short term, advising customers that Yahoo's and Hotmail's freemail services are of very poor quality and should never be relied on for anything, and that Gmail is a better choice, is probably viable. In the long term, though, I think it may only delay the inevitable. ---Rsk
RE: /24 blocking by ISPs - Re: Problems sending mail to yahoo?
It's not unusual to do /24 blocks, however Yahoo claims they do not keep any logs as to what causes the /24 block. If they kept logs and were able to tell us which IP address in the /24 sent abuse to their network we would then be able to investigate it. Their stance of 'it's coming from your network you should know' isn't really helpful in solving the problem. When an IP is blocked a lot of ISP's can tell you why. I would think when they block a /24 they would atleast be able to decipher who was sending the abuse to their network to cause the block and not simply say 'Were sorry our anti-spam measures do not conform with your business practices'. Logging into every server using a /24 is looking for needle in a haystack. -Ray From: Suresh Ramasubramanian [EMAIL PROTECTED] Sent: Thursday, April 10, 2008 11:56 PM To: Raymond L. Corbin Cc: Chris Stone; nanog@merit.edu Subject: /24 blocking by ISPs - Re: Problems sending mail to yahoo? On Fri, Apr 11, 2008 at 1:22 AM, Raymond L. Corbin [EMAIL PROTECTED] wrote: Yeah, but without them saying which IP's are causing the problems you can't really tell which servers in a datacenter are forwarding their spam/abusing Yahoo. Once the /24 block is in place then they claim to have no way of knowing who actually caused the block on the /24. The feedback loop would help depending on your network size. Almost every large ISP does that kind of complimentary upgrade There are enough networks around, like he.net, Yipes, PCCW Global / Cais etc, that host huge amounts of snowshoe spammers - http://www.spamhaus.org/faq/answers.lasso?section=Glossary#233 (you know, randomly named / named after a pattern domains, with anonymous whois or probably a PO box / UPS store in the whois contact, DNS served by the usual suspects like Moniker..) a /27 or /26 in a /24 might generate enough spam to drown the volume of legitimate email from the rest of the /24, and that would cause this kind of /24 block In some cases, such as 63.217/16 on CAIS / PCCW, there is NOTHING except spam coming from several /24s (and there's a /20 and a /21 out of it in spamhaus), and practically zero traffic from the rest of the /16. Or there's Cogent with a similar infestation spread around 38.106/16 ISPs with virtual hosting farms full of hacked cgi/php scripts, forwarders etc just dont trigger /24 blocks at the rate that ISPs hosting snowshoe spammers do. /24 blocks are simply a kind of motivation for large colo farms to try choosing between hosting spammers and hosting legitimate customers. srs ..
Re: Problems sending mail to yahoo?
At 10:22 AM 4/11/2008, Joe Abley wrote: It turns out that if Y! doesn't want to receive mail from me, suddenly I can't send mail to anybody in my extended family, or to most people I know in the town where I live. These involve domains like ROGERS.COM and BTINTERNET.COM, and not just the obvious Y! domains. Good point. I think this also includes ATT/SBC/SNET in some fashion (with which many of my customers have been having different problems this week). To return to the topic at hand, you may already have outsourced the coordination of your boycott to Yahoo!, too! They're already not accepting your mail. There's no need to stop sending it! :-) Yes, but it's the flow of mail (spam) *from* them I'm worried about...
Re: Problems sending mail to yahoo?
JA Date: Fri, 11 Apr 2008 10:22:11 -0400 JA From: Joe Abley JA To return to the topic at hand, you may already have outsourced the JA coordination of your boycott to Yahoo!, too! They're already not JA accepting your mail. There's no need to stop sending it! :-) Except for queue management. I just got off the phone with one client who requested precisely: Can you just have [the servers] refuse to send mail to Yahoo? 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?
The lesson one should get from all this is that the ultimate harm of spammers et al is that they are succeeding in corrupting the idea of a standards-based internet. Sites invent policies to try to survive in a deluge of spam and implement those policies in software. Usually they're loathe to even speak about how any of it works either for fear that disclosure will help spammers get around the software or fear that someone, maybe a customer maybe a litigious marketeer who feels unfairly excluded, will hold their feet to the fire. So it's a vast sea of security by obscurity and standards be damned. It's a real and serious failure of the IETF et al. P.S. Anyone else getting hit by sales calls for DDoS appliances and other salespeople as a result of this thread? This fishing in NANOG waters by salespeople is irritating and a good reason not to do business with these companies. I don't take my time to post on NANOG to invite a deluge of sales calls. -- -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?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barry Shein Sent: Friday, April 11, 2008 5:04 PM To: nanog@merit.edu Subject: Re: Problems sending mail to yahoo? The lesson one should get from all this is that the ultimate harm of spammers et al is that they are succeeding in corrupting the idea of a standards-based internet. Sites invent policies to try to survive in a deluge of spam and implement those policies in software. Usually they're loathe to even speak about how any of it works either for fear that disclosure will help spammers get around the software or fear that someone, maybe a customer maybe a litigious marketeer who feels unfairly excluded, will hold their feet to the fire. So it's a vast sea of security by obscurity and standards be damned. It's a real and serious failure of the IETF et al. Has anyone ever figured out what percentage of a connection to the internet is now overhead i.e. spam, scan, viruses, etc? More than 5%? If we put everyone behind 4to6 gateways would the spam crush the gateways or would the gateways stop the spam? Would we add code to these transitional gateways to make them do more than act like protocol converters and then end up making them permanent because of benefit? Perhaps there's more to transitioning to a new technology after all? Maybe we could get rid of some of the cruft and right a few wrongs while we're at it? P.S. Anyone else getting hit by sales calls for DDoS appliances and other salespeople as a result of this thread? This fishing in NANOG waters by salespeople is irritating and a good reason not to do business with these companies. I don't take my time to post on NANOG to invite a deluge of sales calls. nanog admin If we catch them, we'll act. We added some language related to that to the new AUP and have been able to act on it as a result. /nanog admin -- Martin Hannigan http://www.verneglobal.com/ Verne Global Datacenters e: [EMAIL PROTECTED] Keflavik, Icelandp: +16178216079
Re: Problems sending mail to yahoo?
The lesson one should get from all this is that the ultimate harm of spammers et al is that they are succeeding in corrupting the idea of a standards-based internet. Sites invent policies to try to survive in a deluge of spam and implement those policies in software. Usually they're loathe to even speak about how any of it works either for fear that disclosure will help spammers get around the software or fear that someone, maybe a customer maybe a litigious marketeer who feels unfairly excluded, will hold their feet to the fire. So it's a vast sea of security by obscurity and standards be damned. It's a real and serious failure of the IETF et al. Has anyone ever figured out what percentage of a connection to the internet is now overhead i.e. spam, scan, viruses, etc? More than 5%? If we put everyone behind 4to6 gateways would the spam crush the gateways or would the gateways stop the spam? Would we add code to these transitional gateways to make them do more than act like protocol converters and then end up making them permanent because of benefit? Perhaps there's more to transitioning to a new technology after all? Maybe we could get rid of some of the cruft and right a few wrongs while we're at it? We(*) can't even get BCP38 to work. Ha. Having nearly given up in disgust on trying to devise workable anti-spam solutions that would reliably deliver requested/desired mail to my own mailbox, I came to the realization that the real problem with the e-mail system is so fundamental that there's no trivial way to save it. Permission to mail is implied by simply knowing an e-mail address. If I provide [EMAIL PROTECTED] to a vendor in order to receive updates to an online order, the vendor may retain that address and then mail it again at a later date. Worse, if the vendor shares the address list with someone else, we eventually have the Millions CD problem - and I have no idea who was responsible. Giving out tagged addresses gave a somewhat useful way to track back the who was responsible, but didn't really offload the spam from the mail server. I've solved my spam problem (or, more accurately, am in the process of slowly solving my spam problem) by changing the paradigm. If the problem is that knowing an e-mail address acts as the key to the mail box, then giving the same key to everyone is stupid. For vendors, I now give them a crypto-signed e-mail address(*2). By making the key a part of the DNS name, I can turn off reception for a bad sender (anyone I don't want to hear from anymore!) or a sender who's shared my address with their affiliates (block two for the price of one!) All other validated mail makes it to my mailbox without further spam filtering of any kind. This has been excessively effective, though doing it for random consumers poses a lot of interesting problems. However, it proves to me that one of the problems is the permission model currently used. The spam problem is potentially solvable, but there's a failure to figure out (at a leadership level) paradigm changes that could actually make a difference. There's a lot of resistance to changing anything about the way e-mail works, and understandably so. However, these are the sorts of things that we have to contemplate and evaluate if we're really interested in making fundamental changes that reduce or eliminate abuse. (*) fsvo we that doesn't include AS14536. (*2) I've omitted a detailed description of the strategy in use because it's not necessarily relevant to NANOG. I'm happy to discuss it with anyone interested. It has technical merit going for it, but it represents a significant divergence from current practice. ... 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: /24 blocking by ISPs - Re: Problems sending mail to yahoo?
On Fri, Apr 11, 2008 at 8:37 PM, Raymond L. Corbin [EMAIL PROTECTED] wrote: It's not unusual to do /24 blocks, however Yahoo claims they do not keep any logs as to what causes the /24 We keep quite detailed logs. No comment about yahoo - I've never been at the other end of a /24 block from them srs
Re: Problems sending mail to yahoo?
On Sat, Apr 12, 2008 at 2:34 AM, Barry Shein [EMAIL PROTECTED] wrote: The lesson one should get from all this is that the ultimate harm of spammers et al is that they are succeeding in corrupting the idea of a standards-based internet. The lesson here is that different groups at the same ISPs go to different places Packet pushers go to *NOG. And the abuse desks mostly all go to MAAWG. And any CERTs / security types the ISP has go to FIRST and related events. And most of them never do coordinate internally, run by different groups probably in different cities ... --srs
Re: Problems sending mail to yahoo?
Suresh Ramasubramanian wrote:
On Sat, Apr 12, 2008 at 2:34 AM, Barry Shein [EMAIL PROTECTED]
wrote:
The lesson one should get from all this is that the ultimate harm
of spammers et al is that they are succeeding in corrupting the
idea of a standards-based internet.
huh? i think that, with their attacks, they are actually helping to
drive improvements in the standards. of course, the disfunction of
the standards organizations does not make this as clean a process and as
much of a win as it could be. but considering that security was not
very thoroughly designed in the original standards, we're not doing all
that badly. it's always gonna be a chase.
The lesson here is that different groups at the same ISPs go to
different places
i am not sure that is so much a lesson as an observation. the lesson
may be, in part, that this is sub-optimal. can it be changed? how?
Packet pushers go to *NOG. And the abuse desks mostly all go to
MAAWG. And any CERTs / security types the ISP has go to FIRST and
related events. And most of them never do coordinate internally, run
by different groups probably in different cities ...
dear coo/ceo/whomever: i want approval to send the five folk who go to
nanog, and the five folk who go to maawg, and the five folk who go to
first to *all* go to the new frobnitz joint conference.
think that'll fly?
otoh, being on the frobnitz program committee would be an interesting
lesson and exercise in industry physics.
when i first joined acm ('67), i could keep up with a significant
portion of the literature. now i maybe see a single digit percentage.
the field has broadened. the ops and other applied areas have similarly
broadened and specialized. we are victims of our own success.
randy
Re: Problems sending mail to yahoo?
On Sat, Apr 12, 2008 at 9:02 AM, Randy Bush [EMAIL PROTECTED] wrote: Packet pushers go to *NOG. And the abuse desks mostly all go to MAAWG. And any CERTs / security types the ISP has go to FIRST and related events. And most of them never do coordinate internally, run by different groups probably in different cities ... dear coo/ceo/whomever: i want approval to send the five folk who go to nanog, and the five folk who go to maawg, and the five folk who go to first to *all* go to the new frobnitz joint conference. Collocation would be a useful idea - save airfare, hotel etc. I had this lovely little experience where the lead CERT guy at ISP X was talking about a particular trojan that was hitting his ISP, and was hitting [ISP Y] and hitting [ISP Z]. He says I saw these trojans hitting ISPs Y and Z but didnt know anybody there. If he'd just bothered to step across the hall and talk to his colleagues at ISP X's abuse desk.. they are, and have been for years, in regular contact with their counterparts at Y and Z - email, face to face, phone, IM etc. otoh, being on the frobnitz program committee would be an interesting lesson and exercise in industry physics. You think there's not enough convergence + shared interests in such programs? I mean, abuse + security teams could care less about MPLS and peering, but there is a lot they're discussing (walled gardens, botnet mitigation etc) that does get discussed in far better detail at nanog. Or at FIRST. srs
Re: Problems sending mail to yahoo?
[ should this move to nanog-futures? well, it's a quiet saturday ] Collocation would be a useful idea - save airfare, hotel etc. immensely difficult. the nanog sc could not even get the nanog administrative structure to avoid a direct and damaging conflict with afnog for the next meeting. if successful, it will have taken over two years of work to get a meeting in the dominican republic. ... not that this might not be worth trying. just that it is extremely far from simple. otoh, being on the frobnitz program committee would be an interesting lesson and exercise in industry physics. You think there's not enough convergence + shared interests in such programs? different question. what i meant was that the synergies and tensions between the subject areas would be quite evident on a joint pc, and have to be worked out. doing so would be an educational experience. I mean, abuse + security teams could care less about MPLS and peering, but there is a lot they're discussing (walled gardens, botnet mitigation etc) that does get discussed in far better detail at nanog. Or at FIRST. yes. randy
Problems sending mail to yahoo?
Is it just us or are there general problems with sending email to yahoo in the past few weeks? Our queues to them are backed up though they drain slowly. They frequently return: 421 4.7.0 [TS01] Messages from MAILSERVERIP temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html (where MAILSERVERIP is one of our mail server ip addresses) Yes I followed the link and filled out the form but after several days no response or change. Despite the wording of their message we're not aware of any cause for user complaints. For example if there were a spam leak you'd expect to see complaints in general to postmaster, abuse, etc. None we're aware of. We host quite a few mailing lists and it seems like whatever they're using is being touched off by the volume of (legitimate) mailing list traffic. I'm automatically moving all their email to a slower delivery queue to see if that helps. Just wondering if this was a widespread problem or are we just so blessed, and any insights into what's going on over there. -- -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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Barry Shein wrote: Is it just us or are there general problems with sending email to yahoo in the past few weeks? Our queues to them are backed up though they drain slowly. They frequently return: 421 4.7.0 [TS01] Messages from MAILSERVERIP temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html (where MAILSERVERIP is one of our mail server ip addresses) Just wondering if this was a widespread problem or are we just so blessed, and any insights into what's going on over there. I see this a lot also and what I see causing it is accounts on my servers that don't opt for spam filtering and they have their accounts here set to forward mail to their yahoo.com accounts - spam and everything then gets sent there - they complain to yahoo.com about the spam and bingo - email delays from here to yahoo.com accounts Chris - Chris Stone, MCSE Vice President, CTO AxisInternet, Inc. 910 16th St., Suite 1110, Denver, CO 80202 - PH 303.592.AXIS x302 - 866.317.AXIS | FAX 303.893.AXIS - [EMAIL PROTECTED]| www.axint.net - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFH/lMZnSVip47FEdMRClejAJwOeQjw3CHu7C0XCv1vbazfGrJLBQCeP1sd wDWM0m17XPSV1nOkebTmnJE= =aiBv -END PGP SIGNATURE-
Re: Problems sending mail to yahoo?
On Thu, Apr 10, 2008 at 01:30:06PM -0400, Barry Shein wrote: Is it just us or are there general problems with sending email to yahoo in the past few weeks? Our queues to them are backed up though they drain slowly. They frequently return: 421 4.7.0 [TS01] Messages from MAILSERVERIP temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html (where MAILSERVERIP is one of our mail server ip addresses) Yes I followed the link and filled out the form but after several days no response or change. I had a similar problem recently and found someone at yahoo who would tweak things so I was no longer getting delayed. The problem is dumb users reporting list mail as spam in an attempt to unsubscribe. This is common with a few mail services but the first time I personally was impacted as I tend to run a nice clean 'ship'. I do wish that the mail providers would do a better job of warning people what is happening, why and give some warning. I have 400+ unique yahoo accounts that get list mail so short of sending them all email saying they're idiots you have to wait for them to tweak their delays. Worst part is if the lists are active you can quickly end up with thousands of queued messages making it harder to clear the queue. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Problems sending mail to yahoo?
I work for an ISP that seems to have the same exact problem. We're not even that large of an ISP, 5k customers maybe. We are not a SPAM haven either. We've tried to work with Yahoo! also and have gotten nowhere. If you find anything out on how to deal with it, let me know. I'll update you if I or my Systems guys find out more but it's been going on for a couple weeks and I don't see an end in sight. Regards, Steve InfoStructure Barry Shein wroteth on 4/10/2008 10:30 AM: Is it just us or are there general problems with sending email to yahoo in the past few weeks? Our queues to them are backed up though they drain slowly. They frequently return: 421 4.7.0 [TS01] Messages from MAILSERVERIP temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html (where MAILSERVERIP is one of our mail server ip addresses) Yes I followed the link and filled out the form but after several days no response or change. Despite the wording of their message we're not aware of any cause for user complaints. For example if there were a spam leak you'd expect to see complaints in general to postmaster, abuse, etc. None we're aware of. We host quite a few mailing lists and it seems like whatever they're using is being touched off by the volume of (legitimate) mailing list traffic. I'm automatically moving all their email to a slower delivery queue to see if that helps. Just wondering if this was a widespread problem or are we just so blessed, and any insights into what's going on over there. -- Steve Ryan Master Solvinator [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Office: 541*.* 773*.* 5000 Fax: 541*.* 535*.* 7599 288 S Pacific Hwy Talent, OR 97540
Re: Problems sending mail to yahoo?
Is it just us or are there general problems with sending email to yahoo in the past few weeks? Our queues to them are backed up though they drain slowly. I have ~3,000 messages (from today) stuck with this 421-ts01 problem. Mostly it's our campus mail bag which is a digest that goes out to students (many of whom forward their campus mail off-site). Interestingly, it's only on the newest of our outbound SMTP boxes that's affected. The others (which have been in use for some years) still work just fine. Our SPF record is a permissive 'ptr ~all', btw. Cheers, Michael Holstein Cleveland State University
Re: Problems sending mail to yahoo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Matt Baldwin wrote: mostly. It feels like a poorly implemented spam prevention system. Doing some Google searches will turn up some more background on the issue. We've been telling our users that Yahoo mail is problematic and if they can to switch away from using them as their private email or hosted email. Maybe we all should do the same to them until they quit spewing out all the Nigerian scams and the like that I've been seeing from their servers lately! Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFH/lscnSVip47FEdMRCpwyAJ45+ARClupjQ6TlTJ37r+Yumk8F1ACcDVto WVQtKwWk5uKMq16KvnqwZXc= =ecRV -END PGP SIGNATURE-
Re: Problems sending mail to yahoo?
BS Date: Thu, 10 Apr 2008 13:30:06 -0400 (EDT) BS From: Barry Shein BS Is it just us or are there general problems with sending email to BS yahoo in the past few weeks? Our queues to them are backed up though BS they drain slowly. [ snip details ] BS Just wondering if this was a widespread problem or are we just so BS blessed, and any insights into what's going on over there. Not only been there, done that, but am there, doing that. We admin the server for a list in which one person sends out a weekly post. Subscriber base is about 14,000 people, with around 2000 of those subscribers using Yahoo boxes. Excessive bounces trigger automatic unsubscribes. Although Yahoo readership accounts for 14% of subscribers, it's not uncommon for 98% of automated unsubscribes to be Yahoo-based... followed by Yahoo-using people sending list-admin requests asknig why they were dropped, and wanting to sign back up. Following URLs in Yahoo's 4xx codes gives virtually-useless information. The easiest fix to date has been for people to use less-presumptive email services. 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?
FWIW: I've been tempted to implement sort of a reverse blacklisting. If an (MX|provider) trips a 4xx threshold, have the local MTA s/4/5/ on emails to the problem (MX|domain). If it trips a 5xx threshold, including upgraded 4xx responses, simply refuse delivery altogether at the local end. You don't like our email? Fine. You won't see it. We've observed good success convincing people to switch away from overly-draconian email providers... so a reverse blacklist might not be as _Wolkenkuckucksheim_ as it seems. Or, then again, it might. ;-) 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?
Hello, I have had to tell some dedicated server clients that they will need to disable their forwards to Yahoo or add something like postini for those accounts that forward to Yahoo...It generally works...however Yahoo! for the past three months is now blocking entire /24's if a few IP's get complaints. They have the feedback loops however when you have a network with 175,000 IP addresses and you sign up for a feedback loop for them all they tend to flood your abuse desk with false positives, or forwarded spam. They also don't keep track of which IP's are getting the complaints for you to investigate after the block on the /24 so asking them won't help :(. This potentially means one customer could easily effect the other customer. They offer whitelisting, but this won't get you passed their blocks on the entire /24. They apparently will eventually accept the message because they aren't necessarily 'blocked' but they are 'depriortized' meaning they don't believe your IP is important enough to deliver the message at that time, so they want you to keep trying and when their servers are not 'busy' or 'over loaded' they will accept the message. (Paraphrased from conversations with their 'Bulk Mail Advocacies and Anti-Abuse manager.) -Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Stone Sent: Thursday, April 10, 2008 1:49 PM To: nanog@merit.edu Subject: Re: Problems sending mail to yahoo? -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Barry Shein wrote: Is it just us or are there general problems with sending email to yahoo in the past few weeks? Our queues to them are backed up though they drain slowly. They frequently return: 421 4.7.0 [TS01] Messages from MAILSERVERIP temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html (where MAILSERVERIP is one of our mail server ip addresses) Just wondering if this was a widespread problem or are we just so blessed, and any insights into what's going on over there. I see this a lot also and what I see causing it is accounts on my servers that don't opt for spam filtering and they have their accounts here set to forward mail to their yahoo.com accounts - spam and everything then gets sent there - they complain to yahoo.com about the spam and bingo - email delays from here to yahoo.com accounts Chris - Chris Stone, MCSE Vice President, CTO AxisInternet, Inc. 910 16th St., Suite 1110, Denver, CO 80202 - PH 303.592.AXIS x302 - 866.317.AXIS | FAX 303.893.AXIS - [EMAIL PROTECTED]| www.axint.net - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFH/lMZnSVip47FEdMRClejAJwOeQjw3CHu7C0XCv1vbazfGrJLBQCeP1sd wDWM0m17XPSV1nOkebTmnJE= =aiBv -END PGP SIGNATURE-
Re: Problems sending mail to yahoo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Raymond L. Corbin wrote: Hello, I have had to tell some dedicated server clients that they will need to disable their forwards to Yahoo or add something like postini for those accounts that forward to Yahoo...It generally works...however Yahoo! for the past three months is now blocking entire /24's if a few IP's get complaints. They have the feedback loops however when you have a network with 175,000 IP addresses and you sign up for a feedback loop for them all they tend to flood your abuse desk with false positives, or forwarded spam. They also don't keep track of which IP's are getting the complaints for you to investigate after the block on the /24 so asking them won't help :(. This potentially means one customer could easily effect the other customer. They offer whitelisting, but this won't get you passed their blocks on the entire /24. They apparently will eventually accept the message because they aren't necessarily 'blocked' but they are 'depriortized' meaning they don't believe your IP is importan t enough to deliver the message at that time, so they want you to keep trying and when their servers are not 'busy' or 'over loaded' they will accept the message. (Paraphrased from conversations with their 'Bulk Mail Advocacies and Anti-Abuse manager.) I've had to tell some of our customers the same and that if they wanted to continue the forwarding to their yahoo.com accounts, they'd need to add spam filtering to their accounts here so that the crap is not forwarded, resulting in the email delays for all customers. Works for some and generated more revenue ;-) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFH/muAnSVip47FEdMRCthkAKCW80FIV2FvdctuCxT3JYI2q0MyfACfai2t YkgPN/PGEmxsS6tJplWKg90= =p9F7 -END PGP SIGNATURE-
Re: Problems sending mail to yahoo?
Barry Shein wrote: Is it just us or are there general problems with sending email to yahoo in the past few weeks? Our queues to them are backed up though they drain slowly. They frequently return: 421 4.7.0 [TS01] Messages from MAILSERVERIP temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html (where MAILSERVERIP is one of our mail server ip addresses) Just wondering if this was a widespread problem or are we just so blessed, and any insights into what's going on over there. I see this a lot also and what I see causing it is accounts on my servers that don't opt for spam filtering and they have their accounts here set to forward mail to their yahoo.com accounts - spam and everything then gets sent there - they complain to yahoo.com about the spam and bingo - email delays from here to yahoo.com accounts We had this happen when a user forwarded a non-filtered mail stream from here to Yahoo. The user indicated that no messages were reported to Yahoo as spam, despite the fact that it's certain some of them were spam. I wouldn't trust the error message completely. It seems likely that a jump in volume may trigger this too, especially of an unfiltered stream. ... 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: Problems sending mail to yahoo?
Yeah, but without them saying which IP's are causing the problems you can't really tell which servers in a datacenter are forwarding their spam/abusing Yahoo. Once the /24 block is in place then they claim to have no way of knowing who actually caused the block on the /24. The feedback loop would help depending on your network size. When you have a few hundred thousand clients, and those clients have clients, and they even have client, it simply floods your abuse desk with complaints from Yahoo when it is obviously forwarded spam. So it's more of pick your poison deal with customer complaints about not being able to send to yahoo for a few days or get your abuse desk flooded with complaints which hinders solving actual issues like compromised accounts. -Ray -Original Message- From: Chris Stone [mailto:[EMAIL PROTECTED] Sent: Thursday, April 10, 2008 3:33 PM To: Raymond L. Corbin Cc: nanog@merit.edu Subject: Re: Problems sending mail to yahoo? -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Raymond L. Corbin wrote: Hello, I have had to tell some dedicated server clients that they will need to disable their forwards to Yahoo or add something like postini for those accounts that forward to Yahoo...It generally works...however Yahoo! for the past three months is now blocking entire /24's if a few IP's get complaints. They have the feedback loops however when you have a network with 175,000 IP addresses and you sign up for a feedback loop for them all they tend to flood your abuse desk with false positives, or forwarded spam. They also don't keep track of which IP's are getting the complaints for you to investigate after the block on the /24 so asking them won't help :(. This potentially means one customer could easily effect the other customer. They offer whitelisting, but this won't get you passed their blocks on the entire /24. They apparently will eventually accept the message because they aren't necessarily 'blocked' but they are 'depriortized' meaning they don't believe your IP is importan t enough to deliver the message at that time, so they want you to keep trying and when their servers are not 'busy' or 'over loaded' they will accept the message. (Paraphrased from conversations with their 'Bulk Mail Advocacies and Anti-Abuse manager.) I've had to tell some of our customers the same and that if they wanted to continue the forwarding to their yahoo.com accounts, they'd need to add spam filtering to their accounts here so that the crap is not forwarded, resulting in the email delays for all customers. Works for some and generated more revenue ;-) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFH/muAnSVip47FEdMRCthkAKCW80FIV2FvdctuCxT3JYI2q0MyfACfai2t YkgPN/PGEmxsS6tJplWKg90= =p9F7 -END PGP SIGNATURE-
Re: Problems sending mail to yahoo?
On Thu, Apr 10, 2008 at 12:23:24PM -0600, Chris Stone wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Matt Baldwin wrote: mostly. It feels like a poorly implemented spam prevention system. Doing some Google searches will turn up some more background on the issue. We've been telling our users that Yahoo mail is problematic and if they can to switch away from using them as their private email or hosted email. Maybe we all should do the same to them until they quit spewing out all the Nigerian scams and the like that I've been seeing from their servers lately! Naaah. I hear that Microsoft is going to buy Yahoo!, so this problem will go away once Yahoo! mail gets folded into Microsoft hotmail, whereupon things will get soo much better!
RE: Problems sending mail to yahoo?
In a large multi-datacenter environment you can't login to each users servers and tail their logs to see who's forwarding :( . I'm more of a windows person, but when working with a client on Linux using EXIM I think I did fgrep yahoo.com /etc/valiases/* yahoo-fwds.txt Something like that to get a list of all of the addresses that forward to Yahoo...I think they used CPanel on their server too. Other then that I believe I was grepping through other clients logs for the most popular Yahoo email addresses... I think that if they are going to do CIDR blocks they should at least keep logs as to what caused them to escalate it to that not simply say 'it's your network you figure it out..' -Ray -Original Message- From: Chris Stone [mailto:[EMAIL PROTECTED] Sent: Thursday, April 10, 2008 4:08 PM To: Raymond L. Corbin Cc: nanog@merit.edu Subject: Re: Problems sending mail to yahoo? -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Raymond L. Corbin wrote: Yeah, but without them saying which IP's are causing the problems you can't really tell which servers in a datacenter are forwarding their spam/abusing Yahoo. Once the /24 block is in place then they claim to have no way of knowing who actually caused the block on the /24. The feedback loop would help depending on your network size. When you have a few hundred thousand clients, and those clients have clients, and they even have client, it simply floods your abuse desk with complaints from Yahoo when it is obviously forwarded spam. So it's more of pick your poison deal with customer complaints about not being able to send to yahoo for a few days or get your abuse desk flooded with complaints which hinders solving actual issues like compromised accounts. I look at all my mail server log files and see which logs show obvious spam being forwarded (a lot of times the MAIL FROM address is a dead giveaway) or I tail -F the mail log for a bit and watch the spam coming in and forwarding back out. When I see the forwarding domain that's who I have contacted to upsell some spam filtering. But, we're a small ISP, so I don't have thousands, let alone hundreds of thousands of clients, to deal with... Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFH/nORnSVip47FEdMRCi+HAJ9CJoJ/VAkEssv6TznwcYQVGVWkIACfRwhI VYw0v4HWI8mWs2SHEF3jnq0= =YMQR -END PGP SIGNATURE-
Re: Problems sending mail to yahoo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Raymond L. Corbin wrote: Yeah, but without them saying which IP's are causing the problems you can't really tell which servers in a datacenter are forwarding their spam/abusing Yahoo. Once the /24 block is in place then they claim to have no way of knowing who actually caused the block on the /24. The feedback loop would help depending on your network size. When you have a few hundred thousand clients, and those clients have clients, and they even have client, it simply floods your abuse desk with complaints from Yahoo when it is obviously forwarded spam. So it's more of pick your poison deal with customer complaints about not being able to send to yahoo for a few days or get your abuse desk flooded with complaints which hinders solving actual issues like compromised accounts. I look at all my mail server log files and see which logs show obvious spam being forwarded (a lot of times the MAIL FROM address is a dead giveaway) or I tail -F the mail log for a bit and watch the spam coming in and forwarding back out. When I see the forwarding domain that's who I have contacted to upsell some spam filtering. But, we're a small ISP, so I don't have thousands, let alone hundreds of thousands of clients, to deal with... Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFH/nORnSVip47FEdMRCi+HAJ9CJoJ/VAkEssv6TznwcYQVGVWkIACfRwhI VYw0v4HWI8mWs2SHEF3jnq0= =YMQR -END PGP SIGNATURE-
Re: Problems sending mail to yahoo?
On Thu, Apr 10, 2008 at 01:30:06PM -0400, Barry Shein wrote: Is it just us or are there general problems with sending email to yahoo in the past few weeks? It's not you. Lots of people are seeing this, as Yahoo's mail servers are apparently too busy sending ever-increasing quantities of spam to have to accept inbound traffic. Sufficiently persistent and lucky people have sometimes managed to penetrate the outer clue-resistant shells of Yahoo and effect changes, but some of those seem ineffective and temporary. There doesn't seem to be any simple, universal fix for this other than advising people that Yahoo's email service is already miserable and continues to deteriorate, and hoping that they migrate elsewhere. ---Rsk
RE: Problems sending mail to yahoo?
I hope that's sarcasm? Instead of getting the bounces your messages will simply go missing after they accepted it...or you will get bounces sent to you a few years after you sent the message...(happened to a client yesterday...). -Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henry Yen Sent: Thursday, April 10, 2008 4:17 PM To: nanog@merit.edu Subject: Re: Problems sending mail to yahoo? On Thu, Apr 10, 2008 at 12:23:24PM -0600, Chris Stone wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Matt Baldwin wrote: mostly. It feels like a poorly implemented spam prevention system. Doing some Google searches will turn up some more background on the issue. We've been telling our users that Yahoo mail is problematic and if they can to switch away from using them as their private email or hosted email. Maybe we all should do the same to them until they quit spewing out all the Nigerian scams and the like that I've been seeing from their servers lately! Naaah. I hear that Microsoft is going to buy Yahoo!, so this problem will go away once Yahoo! mail gets folded into Microsoft hotmail, whereupon things will get soo much better!
Re: Problems sending mail to yahoo?
HY Date: Thu, 10 Apr 2008 16:17:08 -0400 HY From: Henry Yen HY Naaah. I hear that Microsoft is going to buy Yahoo!, so this HY problem will go away once Yahoo! mail gets folded into Microsoft HY hotmail, whereupon things will get soo much better! Maybe all the 42x responses are an attempt to cut load while migrating things onto Exchange. ;-) 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.
/24 blocking by ISPs - Re: Problems sending mail to yahoo?
On Fri, Apr 11, 2008 at 1:22 AM, Raymond L. Corbin [EMAIL PROTECTED] wrote: Yeah, but without them saying which IP's are causing the problems you can't really tell which servers in a datacenter are forwarding their spam/abusing Yahoo. Once the /24 block is in place then they claim to have no way of knowing who actually caused the block on the /24. The feedback loop would help depending on your network size. Almost every large ISP does that kind of complimentary upgrade There are enough networks around, like he.net, Yipes, PCCW Global / Cais etc, that host huge amounts of snowshoe spammers - http://www.spamhaus.org/faq/answers.lasso?section=Glossary#233 (you know, randomly named / named after a pattern domains, with anonymous whois or probably a PO box / UPS store in the whois contact, DNS served by the usual suspects like Moniker..) a /27 or /26 in a /24 might generate enough spam to drown the volume of legitimate email from the rest of the /24, and that would cause this kind of /24 block In some cases, such as 63.217/16 on CAIS / PCCW, there is NOTHING except spam coming from several /24s (and there's a /20 and a /21 out of it in spamhaus), and practically zero traffic from the rest of the /16. Or there's Cogent with a similar infestation spread around 38.106/16 ISPs with virtual hosting farms full of hacked cgi/php scripts, forwarders etc just dont trigger /24 blocks at the rate that ISPs hosting snowshoe spammers do. /24 blocks are simply a kind of motivation for large colo farms to try choosing between hosting spammers and hosting legitimate customers. srs ..
Re: Problems sending mail to yahoo?
At 02:23 PM 4/10/2008, you wrote: Maybe we all should do the same to them until they quit spewing out all the Nigerian scams and the like that I've been seeing from their servers lately! Chris If there were an coordinated boycott, I would participate. Yahoo is *by far* the worst single abuser of our server among the legitimate email providers. I report dozens of spams from my personal account alone every day and never receive anything other than automated messages claiming to have dealt with the same abuse that continues around the clock or, worse, bogus/clueless claims that the IP in question is not theirs and suggestions that I check the same ARIN database that I used to confirm the responsible party in the first place. Until I read this thread, my suspicion was that all my spam reports were triggering the 4xx delays, and I'm still not sure that's not the case. (I only have one customer forwarding to yahoo.com, and that's post-filters.) Naturally, they delay mail to [EMAIL PROTECTED] the same as any other mail. And, yes, I've tried to reach a human there. The only humans I ever reached briskly forwarded me to voice mail hell for customer support. So, I will start sending 5XX or 4XX messages to Yahoo if you guys will. I don't care if I have to spend all day on the phone with my customers explaining why. They hate spam, too, and they'll understand.
Cogent's having peering problems with AOL again
Cogent's again seeing congestion at their hand-off to ATDN.net. Traceroutes to their mailservers show packet loss and mail into AOL is dying a few packets into the conversation. Cogent says they're waiting on a call back from AOL, no ETR provided. Carl Hirsch
Comcast SMTP problems
This is probably just regional, but here in SE PA, I've had a few customers who send their outgoing mail through smtp.comcast.net getting internal queueing error. Anybody find what it is or was and when/if it was fixed? TIA, James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: Apple Airport Extreme IPv6 problems?
Some months ago I already circulated in this list instructions that I've provided in other IPv6 related exploder for doing so ... Introduction to 6to4 https://lists.afrinic.net/pipermail/afripv6-discuss/2007/61.html Configuring 6to4 Relay in Cisco https://lists.afrinic.net/pipermail/afripv6-discuss/2007/66.html Configuring 6to4 Relay in Linux https://lists.afrinic.net/pipermail/afripv6-discuss/2007/67.html Configuring 6to4 Relay in BSD https://lists.afrinic.net/pipermail/afripv6-discuss/2007/68.html Configuring 6to4 Relay in Windows https://lists.afrinic.net/pipermail/afripv6-discuss/2007/74.html Configuring Teredo Server/Relay in Linux/BSD https://lists.afrinic.net/pipermail/afripv6-discuss/2007/80.html Regards, Jordi De: [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sun, 16 Sep 2007 15:38:21 +0100 Para: nanog@merit.edu Conversación: Apple Airport Extreme IPv6 problems? Asunto: RE: Apple Airport Extreme IPv6 problems? I think we will never move to IPv6 if vendors don't do things like the one in the Airport. However, in order to make this transition phase where there may be a possible degradation of the RTT, we need to cooperation of the operators, for example deploying 6to4 relays in their networks. And just what should operators do to cooperate? Are you aware of any documents that describe how to set up 6to4 relays in an ISP network? --Michael Dillon ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: Apple Airport Extreme IPv6 problems?
For a production service, I will never use dual naming for IPv4 and IPv6, is ridiculous ask the users to understand if they want to use one or the other to use a different name. For a testing, not an issue. Regards, Jordi De: Martin Hannigan [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Mon, 17 Sep 2007 13:06:25 -0400 Para: Iljitsch van Beijnum [EMAIL PROTECTED] CC: Barrett Lyon [EMAIL PROTECTED], nanog@merit.edu Asunto: Re: Apple Airport Extreme IPv6 problems? On 9/15/07, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 15-sep-2007, at 21:25, Barrett Lyon wrote: The other thought that occurred to me, does FF/Safari/IE have any ability to default back to v4 if v6 is not working or behaving badly? This could be a helpful transition feature but may be more trouble than it's worth. Browsers are pretty good at falling back on a different address in general / IPv4 in particular when the initial try doesn't work, but it does take too long if the packet is silently dropped somewhere. If there is an ICMP unreachable there is no real delay. Worst case is a path MTU discovery black hole, then browsers generally don't fall back. Getting back to my original discussion with Barrett, what should we do about naming? I initially though that segregating v6 in a subdomain was a good idea, but if this is truly a migration, v4 should be the interface segregated. I have also read Jordi? saying that no dual naming should occur, but I think this is unrealistic. (Sorry if I misquoted you, Jordi) It would be good if more ISPs deployed 6to4 gateways so the 6to4 experience would be better. We are. There are an unending supply of small details that are in the way at the moment. :-) Best, Marty ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Unfortunately, Juniper doesn't support 6to4, only in Netscreen boxes. This is ridiculous and I already asked Juniper several times about this ..., but never got a positive feedback about when it will be supported. Regards, Jordi De: [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 18 Sep 2007 14:54:11 +0100 Para: nanog@merit.edu Conversación: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?) Asunto: RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?) - setup a 6to4 relay + route 192.88.99.1 + 2002::/16 How? This is reasonably well documented for a Cisco but here's a minimal sample config: Thanks. I used your info, and other sources, to put up a page at http://www.getipv6.info/index.php/First_Steps_for_ISPs which describes how to set up 6to4 relay on Cisco, where to get Teredo relay software that you can run, and where to get tunnel broker software. There are a couple of gaps. I can find no info on how to set up 6to4 relay services on Juniper routers. Does JUNOS support this at all? If you know, go to the above page, click on Juniper, and tell us what needs to be done. In addition, CSELT in Italy distributed an IPv6 tunnel broker package at one time. I cannot find this anywhere. If you know where this software can be acquired or if you know of better IPv6 tunnel broker software, add it to the above page. I now know why people are so quick to give advice on what to do without explaining how to do it. It just is not easy to find out how to setup 6to4 relay services, Teredo relay services and IPv6 tunnel broker services. No doubt you can hire a consultant to do this for you, but if we want to get significant deployment we cannot rely on consultants who keep their toolkits secret. --Michael Dillon ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
There is something not correct here ... Proto-41 is supported by many boxes, even NAT boxes, I guess by mistake from de vendor/implementation ... Basically many boxes just understand TCP and UDP and they decide to pass-thru other unknown protocols, instead of discarding them. I've document that long time ago: http://tools.ietf.org/html/draft-palet-v6ops-proto41-nat-03 There is a PDF document also linked into the ID which may be interesting to read for an specific example. I use many times proto-41 (even with 6to4) even when I get private (behind NAT) addresses for my laptop via my 3G phone. Regards, Jordi De: Nathan Ward [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Mon, 17 Sep 2007 01:17:24 +1200 Para: NANOG nanog@merit.edu Asunto: Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?) On 16/09/2007, at 8:03 AM, Jeroen Massar wrote: - IPv6 native (anything not 2002::/16 + 2003::/32) - IPv4 native - IPv6 6to4 (2002::/16) - IPv6 Teredo (2003::/32 Incase anyone is using this for reference purposes, Jaroen really means 2001::/32, not 2003::/32. Teredo was also previously on 3ffe:831f::/32, for those of you on older Windows XP machines. This prefix no longer works - upgrade. Now the really BIG problem there is though is that when network connectivity is broken. TCP connect will be sent, but no response comes back or MTU is broken, then the session first has to time out. snip 6to4 and Teredo are a big problem here, especially from an operator viewpoint. Yes. Infact, especially if you have users on Vista. It does this IPv6 tunnelling thing that on the surface appears really cool. When you try and talk IPv6 to something other than link-local: (in order) - If you have a non-RFC1918 (ie. 'public') address, it fires up 6to4. - If you have an RFC1918 address, it fires up Teredo. Seems cool in theory, and you'd think that it would really help global IPv6 deployment - I'm sure that's how it was intended, and I applaud MS for taking a first step. But in practice, however, this has essentially halted any IPv6 /content/ deployment that people want to do, as user experience is destroyed. You can help, though - here's the problem: 6to4 uses protocol 41 over IP. This doesn't go through NAT, or stateful firewalls (generally). Much like GRE. Because of this, if you're a enterprise-esque network operator who runs non-RFC1918 addresses internally and do NAT, or you do stateful firewalling, PLEASE, run a 6to4 relay on 192.88.99.1 internally, but return ICMPv6 unreachable/admin denied/whatever to anything that tries to send data out through it. Better yet, tell your firewall vendor to allow you to inspect the contents of 6to4 packets, and optionally run your own 6to4 relay, so outgoing traffic is fast. Even if you don't want to deploy IPv6 for some time, do this at the very least RIGHT NOW, or you're preventing those of us who want to deploy records alongside our A records from doing so. If you need configs for vendor/OS B/C/J/L, let me know and I'll write some templates. I see this sort of IPv4 network quite commonly at universities, where students take their personal laptops and throw them on the campus 802.11 network. While disabling the various IPv6 things in Vista at an enterprise policy level might work for some networks, it doesn't for for a university with many external machines visiting. So, if you're a university with a network like this (ie. most universities here in NZ, for example), please spend a day or two to fix this problem in your network - or better yet, do a full IPv6 deployment. I'd like to get some work done to get some 'qualification' testing of the availability of 6to4 from a 'client' POV standardised, so this problem can go away. Moving city+job has hindered such things as of late. As such, if you, as an ACCESS operator want to have full control over where your users IPv6 traffic goes to you might want to do a couple of things to get it at least a bit in your control: - setup a 6to4 relay + route 192.88.99.1 + 2002::/16 - setup a Teredo Server + Relay and make available the server information to your users and inform them of it. For those not on v6ops, I've got a draft right now that explains why you should (as an access provider) run a Teredo server, and proposes a standard to allow you to direct your users to your local Teredo server. I should be pushing out an update to it shortly. See above RE. moving life around. Also, Relays are only useful if you have native IPv6 somewhere, OR if you run a 6to4 relay (which probably means you have native IPv6..). Note the distinct usage of 'servers' and 'relays', for the uninitiated. I'm building some embedded system images that run Teredo and 6to4 relays, with pretty much zero configuration. It runs on Soekris hardware right now (ie. sub $USD300), but if people are interested I can port it to regular x86 hardware. All you need is an IPv6 tunnel
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 24/09/2007, at 10:46 PM, JORDI PALET MARTINEZ wrote: There is something not correct here ... Proto-41 is supported by many boxes, even NAT boxes, I guess by mistake from de vendor/implementation ... Basically many boxes just understand TCP and UDP and they decide to pass-thru other unknown protocols, instead of discarding them. Probably doesn't work so well if you have 6k people behind the same NAT, and they all try and use proto-41, though. -- Nathan Ward
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 20/09/2007, at 4:08 AM, Seth Mattinen wrote: Adrian Chadd wrote: On Wed, Sep 19, 2007, Iljitsch van Beijnum wrote: location would be enough. If I had some old 7200s lying around I'd use those, in locations where replacing drives isn't a huge deal a BSD box (Linux if you insist) would be a good choice because they give you a bigger CPU for your money. As someone who is building little compact flash and USB flash based BSD boxes for various tasks, I can quite happily say its entirely possible to build diskless based Linux/BSD routers which are upgraded about as easy as upgrading a Cisco router (ie, copy over new image, run save-config script, reboot.) Its been that way for quite some time. If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is enough to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. What about Soekris hardware? I don't have any personal experience with it, but it looks very appealing to build load balancers/ routers out of, and quite inexpensive. Adrian, Seth, anyone else interested. I've almost got a Soekris FreeBSD image going, working just as Adrian describes RE upgrades, running Miredo and 6to4 relays. I'll release for testing within a couple weeks, drop me an email if you'd like to play. I'm doing both NET4801 and NET4501, as that's what I've got here right now. The only stuff left to do is put some basic configs on there, and test Miredo some. 6to4 etc. all functions fine, it just needs some hand holding. -- Nathan Ward
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Mon, 24 Sep 2007 23:35:12 +1200, Nathan Ward said: Probably doesn't work so well if you have 6k people behind the same NAT, and they all try and use proto-41, though. If you have 6,000 people behind a single NAT, proto-41 is probably the least of your concerns, and Randy Bush may or may not be thinking of awarding you an Innovative Engineering Award. :) pgpmLKqZ6571Z.pgp Description: PGP signature
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 24/09/2007, at 11:48 PM, [EMAIL PROTECTED] wrote: On Mon, 24 Sep 2007 23:35:12 +1200, Nathan Ward said: Probably doesn't work so well if you have 6k people behind the same NAT, and they all try and use proto-41, though. If you have 6,000 people behind a single NAT, proto-41 is probably the least of your concerns, and Randy Bush may or may not be thinking of awarding you an Innovative Engineering Award. :) Don't worry, /I/ don't do this. Some large enterprise/campus networks do, though. Let's revise my number to 2. Just as much as a problem if they're both trying to do proto-41 :-) The other thing to note - 6to4 kicks in on Vista if it has a non- RFC1918 IPv4 address, so we're talking about people NATing large numbers of non-RFC1918 space. Regardless of how crazy they might seem, these networks exist, and they're preventing people from rolling out IPv6 () to production stuff. It's annoying, because they're often the same people who say I'm not going to pay attention to IPv6, I've got enough addresses., and we all lose because of it. (That, or when those networks become few enough that we can turn on records for production stuff, they'll be forced to sort their stuff out). -- Nathan Ward
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Yes, that's clear, I was assuming we are talking about end boxes such as a CPE. Regards, Jordi De: Nathan Ward [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Mon, 24 Sep 2007 23:35:12 +1200 Para: NANOG nanog@merit.edu Asunto: Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?) On 24/09/2007, at 10:46 PM, JORDI PALET MARTINEZ wrote: There is something not correct here ... Proto-41 is supported by many boxes, even NAT boxes, I guess by mistake from de vendor/implementation ... Basically many boxes just understand TCP and UDP and they decide to pass-thru other unknown protocols, instead of discarding them. Probably doesn't work so well if you have 6k people behind the same NAT, and they all try and use proto-41, though. -- Nathan Ward ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 24-sep-2007, at 13:55, Nathan Ward wrote: The other thing to note - 6to4 kicks in on Vista if it has a non- RFC1918 IPv4 address, so we're talking about people NATing large numbers of non-RFC1918 space. Regardless of how crazy they might seem, these networks exist [...] when those networks become few enough that we can turn on records for production stuff, they'll be forced to sort their stuff out). How far can one bend over backwards before breaking said back?
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Mon, Sep 24, 2007, JORDI PALET MARTINEZ wrote: Yes, that's clear, I was assuming we are talking about end boxes such as a CPE. You'd be surprised how many Cisco 827's there are out there in strange places without a sane NAT config (with all the 12.4T NAT twiddles set appropriately.) Max NAT session before running out of RAM? ~8k or so? What kills it? Trackerless P2P. Lovely. And lets not discuss the default cisco IOS firewall and its tracking state + throttling stuff.. Adrian
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Date: Mon, 24 Sep 2007 12:41:12 +0200 From: JORDI PALET MARTINEZ [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Unfortunately, Juniper doesn't support 6to4, only in Netscreen boxes. This is ridiculous and I already asked Juniper several times about this ..., but never got a positive feedback about when it will be supported. Unfortunately, IPv6 support in almost any network hardware is pretty lame. Yes, both C and J support IPv6, but that is often pretty slim support, especially in terms of management and accounting. And they have the nerve to charge extra for IPv6 capability that is missing most features needed to provide true, production quality support. It's even worse in areas like security products and various network application, monitoring, and analysis devices. About the only things that is pretty likely fully IPv6 capable is the end system. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpQJwSHy3ESq.pgp Description: PGP signature
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
In article [EMAIL PROTECTED] you write: On 9/15/07, Jeroen Massar [EMAIL PROTECTED] wrote: [spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy Gallery :)] Somewhat long, hopefully useful content follows... Barrett Lyon wrote: [..] [ clip ] Of course when there is only a A or only that protocol will be used. All applications are supposed to use getaddrinfo() which sorts these addresses per the above specification, the app should then connect() to them in order, fail/timeout and try the next one till it Since when is a timeout on the Internet ok? Haven't we moved beyond that? You mean to say you get 100% connectivity with IPv4? This is a controllable timeout. We don't have to do it, which is the point. What's the right way to do this? Thank you, and thank you Barret for starting the thread. :-) -M I've been running dual stacked for 5 years with a trans pacific tunnel to HE (10 hops). While there have been the occasional glitch I don't see much difference between IPv4 and IPv6. Work has also been running dual stacked. I very rarely fall back to IPv4, and given my usage patterns I do notice when IPv6 connectivity fails. Looping through the addresses as returned by getaddrinfo is a reasonable strategy. Mark
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 9/21/07, Mark Andrews [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] you write: On 9/15/07, Jeroen Massar [EMAIL PROTECTED] wrote: [spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy Gallery :)] Somewhat long, hopefully useful content follows... Barrett Lyon wrote: [..] [ clip ] Of course when there is only a A or only that protocol will be used. All applications are supposed to use getaddrinfo() which sorts these addresses per the above specification, the app should then connect() to them in order, fail/timeout and try the next one till it Since when is a timeout on the Internet ok? Haven't we moved beyond that? You mean to say you get 100% connectivity with IPv4? I mean to say that I don't willingly set out to deliver 100%.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 21-sep-2007, at 7:54, Martin Hannigan wrote: All applications are supposed to use getaddrinfo() which sorts these addresses per the above specification, the app should then connect() to them in order, fail/timeout and try the next one Since when is a timeout on the Internet ok? Haven't we moved beyond that? This is a controllable timeout. We don't have to do it, which is the point. What's the right way to do this? I agree that it's not acceptable to engineer things such that timeouts occur by design. However, things tend to break, and in those situations it's important to recover as well as can be expected. So the correct way to operate here is for the network designer to make reasonably sure (unreliable datagram etc) that everything works, for the stack designer to make sure that there is a good algorithm for selecting the best combination of destination and source addresses and for the application to cycle through all addresses if the two former efforts weren't completely successful.
RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is enough to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. What about Soekris hardware? I don't have any personal experience with it, but it looks very appealing to build load balancers/routers out of, and quite inexpensive. Before you choose which hardware platform to use, you should take a look at the software platform and see what other people are using. There are dozens of Linux router distros like OpenWRT out there. http://leaf.sourceforge.net/ Linux Embedded gateway/router/firewall http://www.linuxdevices.com/articles/AT6003080606.html Building a low cost router appliance Linux Devices is a good site to find information about embedded hardware platforms that support Linux. There are a lot of possibilities ranging from fanless x86 systems built around a Via EPIA motherboard to traditional embedded platforms based around ARM or MIPS processors. And just about anything that runs Linux will also run BSD if that is what you want. --Michael Dillon
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 9/15/07, Jeroen Massar [EMAIL PROTECTED] wrote: [spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy Gallery :)] Somewhat long, hopefully useful content follows... Barrett Lyon wrote: [..] [ clip ] Of course when there is only a A or only that protocol will be used. All applications are supposed to use getaddrinfo() which sorts these addresses per the above specification, the app should then connect() to them in order, fail/timeout and try the next one till it Since when is a timeout on the Internet ok? Haven't we moved beyond that? This is a controllable timeout. We don't have to do it, which is the point. What's the right way to do this? Thank you, and thank you Barret for starting the thread. :-) -M
