Re: Reverse DNS RFCs and Recommendations
In message 5279f5e1.9030...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Mark Andrews wrote: You misunderstand very basic points on why forward and reverse DNS checking is useful. If an attacker can snoop DHCP reply packet to a victim's CPE, the attacker can snoop any packet to a victim's server, which is already bad. The DHCP reply packet is special as is is broadcasted. What? Rfc3315 is explicit on it: 18.2.8. Transmission of Reply Messages The Reply message MUST be unicast through the interface on which the original message was received. While IPv6 is unicast, IPv4 isn't and having a scheme that will work for IPv4 as well as IPv6 is useful. Also there is NO GUARANTEE that the response can't be seen so you design the protocol to work when it can be seen. That is, Mark's security model is broken only to introduce obscurity with worse security. This is a about adding a delegation into the DNS securely so only the machine that the prefix is delegated to and the ISP can update it. There are a number of reasons to want to do this securely from both the ISP side and the customer side regardless of whether you secure the DNS responses themselves. And carrying TSIG key in DHCP reply is just secure from the both sides. Not in the clear it isn't. Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Reverse DNS RFCs and Recommendations
Mark Andrews wrote: The DHCP reply packet is special as is is broadcasted. What? Rfc3315 is explicit on it: 18.2.8. Transmission of Reply Messages The Reply message MUST be unicast through the interface on which the original message was received. While IPv6 is unicast, IPv4 isn't and having a scheme that will work for IPv4 as well as IPv6 is useful. In your draft, you wrote: CPE generates DHCPv6 Prefix Delegation [RFC3633] request which Moreover, even for IPv4, the scheme can (and should) mandate unicast DHCP reply. Also there is NO GUARANTEE that the response can't be seen so you design the protocol to work when it can be seen. Your misunderstanding on DHCPv6 is OK, because you also misunderstand that it were more secure? Then, as there is NO GUARANTEE that CAs of DNSSEC can't be compromised, you MUST design the protocol to work when they can be compromised. And carrying TSIG key in DHCP reply is just secure from the both sides. Not in the clear it isn't. Clear text in DHCP reply is just secure when required security level allows to use DHCP. Masataka Ohta
Re: DNS and nxdomain hijacking
You can find a fairly good overview at http://tools.ietf.org/html/draft-livingood-dns-redirect-03 Comcast does not do this, see http://corporate.comcast.com/comcast-voices/comcast-domain-helper-shuts-down Jason Livingood (Comcast) On 11/5/13, 3:38 PM, Warren Bailey wbai...@satelliteintelligencegroup.commailto:wbai...@satelliteintelligencegroup.com wrote: All, I've noticed a lot more nxdomain redirects on providers (cox, uverse, tmo, etc.) networks lately. How is this being done?? Is it a magic box or some kind of subscription service? Are any of you doing it? //warren
Re: DNS and nxdomain hijacking
On 11/5/13, 7:57 PM, Phil Bedard bedard.p...@gmail.com wrote: I think every major residential ISP in the US has been doing this for 5+ years now. I worked at one provider who made a pretty decent chunk of change off the monthly ad revenue and that was 6 years ago. People typo a lot of URLs. There¹s less money in it that you¹d think and the monetization rates are declining. Jason
Re: DNS and nxdomain hijacking
On 11/5/13, 11:01 PM, Mark Andrews ma...@isc.org wrote: In message 20131106033003.gb6...@dyn.com, Andrew Sullivan writes: On Tue, Nov 05, 2013 at 07:57:59PM -0500, Phil Bedard wrote: I think every major residential ISP in the US has been doing this for 5+ years now. Comcast doesn't, because it breaks DNSSEC. Only if you are validating. Exactly. And this was one of the central arguments that helped defeat the DNS redirection portions of SOPA/PIPA/ProtectIP/COICA. Jason
Re: Reverse DNS RFCs and Recommendations
Reverse DNS for (typical) residential customer IPv6 addresses is dead, people just haven¹t come to grips with it just yetŠ ;-) When publicly-reachable services in home networks are created that may be a different matter of course. But it is hard to imagine an ISP automatically or dynamically generating reverse records for all the IPv6 addresses handed out to your average residential users. Jason On 11/5/13, 12:31 AM, Lee Howard l...@asgard.org wrote: http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00 It would be great to have this conversation in the IETF Homenet WG, as well as DNSops. This would solve the gaps I identified. Not sure why I, as an ISP, would spend money on this. Lee
Re: Reverse DNS RFCs and Recommendations
On Nov 6, 2013, at 9:02 AM, Livingood, Jason jason_living...@cable.comcast.com wrote: Reverse DNS for (typical) residential customer IPv6 addresses is dead, people just haven¹t come to grips with it just yetŠ ;-) When publicly-reachable services in home networks are created that may be a different matter of course. But it is hard to imagine an ISP automatically or dynamically generating reverse records for all the IPv6 addresses handed out to your average residential users. Jason On 11/5/13, 12:31 AM, Lee Howard l...@asgard.org wrote: http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00 It would be great to have this conversation in the IETF Homenet WG, as well as DNSops. This would solve the gaps I identified. Not sure why I, as an ISP, would spend money on this. Lee Dynamic DNS providers will undoubtably endeavor to make money from and SRV entries for publicly-reachable services in SOHO and home networks. Dynamic DNS providers are normally not delegated authority to provide PTR records for ISP managed addresses, making provision of complementary and PTR records highly unlikely. Because of the cost of scaling and delegation issues I agree with Jason and see no compelling business case for rDNS services for SOHO or residential users. It’s dead, Jim James R. Cutler james.cut...@consultant.com signature.asc Description: Message signed with OpenPGP using GPGMail
RE: Level3 and ATT Latency
As a matter of pure competitive intelligence gathering (i.e. I do not mean this as a rhetorical question), which providers list peering issues on their portal? Particularly when they might be a bit more of an ongoing nature vs. a concrete outage? Dave -Original Message- From: Tassos Chatzithomaoglou [mailto:ach...@forthnet.gr] Sent: Tuesday, November 05, 2013 11:54 PM To: nanog@nanog.org Subject: Re: Level3 and ATT Latency Unfortunately, many issues don't appear (deliberately?) as network events on their portal. -- Tassos Jason Baugher wrote on 6/11/2013 06:46: For what it's worth, Level3 finally told us they had a peering issue with ATT. They ended up re-routing traffic for the time being until they identify the issue. Of course, for some reason a peering issue doesn't warrant a Network Event on their portal... On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist da...@crmls.org wrote: I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today. They just got it spliced back up. Not sure if it is related to your latency. David -Original Message- From: Eric Williams [mailto:ewilli...@connectria.com] Sent: Tuesday, November 05, 2013 11:49 AM To: nanog@nanog.org Subject: Level3 and ATT Latency Is anybody else seeing or having major latency between Level 3 and ATT today? We are multi-homed with Level 3 being one of our ISP's and had to divert traffic after seeing these issues. http://www.internetpulse.net/ Eric
Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
On Wed, 06 Nov 2013 08:50:06 +0900, Masataka Ohta said: valdis.kletni...@vt.edu wrote: How do you intend to *find* the agents who were hired at a government agency's under-the-table request that never had a written record that the company had access to? By memories of those who are at the table. Hint: I'm not talking about a way to have perfect security. I'm talking about possible/good/recommended approach to improve the security without witch hunting. You still haven't explained how the memories of those who are at the table help, when the NSA plant has very good reasons to say they're not an NSA plant, and you haven't explained how you can show they *are* a plant. pgp1cbvQ4tHqW.pgp Description: PGP signature
Do you obfuscate email headers when reporting spam issues to clients?
Hello, We (iWeb AS32613) are currently making great strides in getting out from under the volume of reports received and getting on top of things. How much trouble does your abuse department go to in order to obfuscate headers when providing evidence of spamming activity regardless of if it’s intentional/professional spammer activity or some kind of malware infection allowing a third party to spam. Especially for the pro spammers, we don’t want them list washing anything or worse yet becoming privy to spamtrap data if the reporting party wasn’t smart enough to obfuscate their own data before sending in the report. So basically in order to be able to provide some evidence to clients they can use in the case of an infection of some type but not give away too much information to professional spammers we need to find a balance. I’m not sure if it’s worthwhile going to too much trouble on this since basically regardless of the data they get sent they are going to be nuked if they are actual spammers anyway. -- Landon Stewart landonstew...@gmail.com
Recovery mode on Juniper M7i
Hello everyone! Greetings of the day. I am kind of (badly) stuck with multiple routers and not able to recover the root password. It's Juniper M7i. I have followed the Juniper support page as given here - http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland strange enough that it worked with one of routers I have but failed on rest all. I am getting stuck on Step #12. As I give boot -s to get into single user mode of BSD, system next asks me for root password and hence I am out of luck to get into recovery mode. I tried pressing enter on that prompt as well but no luck. I am connecting to router via console and do have physical access to router(s). Was wondering if someone has seen similar issues and could guide on what I am doing wrong? Most of other help pages I have seen on net have same exact steps as given on that page. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, Nov 6, 2013 at 1:30 PM, Landon landonstew...@gmail.com wrote: How much trouble does your abuse department go to in order to obfuscate headers when providing evidence of spamming activity regardless of if it’s intentional/professional spammer activity or some kind of malware infection allowing a third party to spam. Especially for the pro spammers, we don’t want them list washing anything or worse yet becoming privy to spamtrap data if the reporting party wasn’t smart enough to obfuscate their own data before sending in the report. Howdy, It depends on the exact situation, but the general-purpose answer is: none. zero. zip. The customer usually can't act on your information unless he can line it up with an entry in his own logs. He needs lots of details in the headers to figure out which computer or which of his users the message came from. And he needs that information to determine whether the message really came from his system -- headers get forged, you know. If he can line it up with an entry in his logs then, if he's a spammer, he knows what address the message was sent to rendering your obfuscation pointless. And by now spammers are very good at list scrubbing from the slightest bit of uniquely identifiable information they can get back. Assuming they bother, which many don't. It does depend on the situation though. You shouldn't be forwarding the customer 200 spam complaints. After a small sample of messages he either has enough information to track the source of the problem or he is the problem. Also, when I bounce spam, I scrub my antispam engine's report from the bounce. No point telling the spammer how he failed to reach me. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Reverse DNS RFCs and Recommendations
In message 5964ada4-8fcf-4fce-9e64-7474ccae5...@consultant.com, Cutler James R writes: On Nov 6, 2013, at 9:02 AM, Livingood, Jason jason_living...@cable.comcast.com wrote: Reverse DNS for (typical) residential customer IPv6 addresses is dead, people just haven't come to grips with it just yet.;-) When publicly-reachable services in home networks are created that may be a different matter of course. But it is hard to imagine an ISP automatically or dynamically generating reverse records for all the IPv6 addresses handed out to your average residential users. Jason This discussion is currently NOT about ISP's generating PTR records for IPv6 reverse. It is about the automatic delegation of the DNS reverse namespace to to servers under customer control when the CPE device requests it as part of the Prefix Delegation request. This is about a adding KEY, DS and NS records at the delegation point in a secure manner. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Recovery mode on Juniper M7i
On Nov 6, 2013, at 1:11 PM, Anurag Bhatia m...@anuragbhatia.com wrote: Hello everyone! Greetings of the day. I am kind of (badly) stuck with multiple routers and not able to recover the root password. It's Juniper M7i. I have followed the Juniper support page as given here - http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland strange enough that it worked with one of routers I have but failed on rest all. what's your junos version?
Re: Recovery mode on Juniper M7i
Maybe you're not doing anything wrong and someone tweaked the routers and marked the console as insecure, a previous owner maybe? http://superuser.com/questions/85536/securing-freebsd-in-single-user-mode http://www.freebsd.org/cgi/man.cgi?query=bootsektion=8 HTH. On 6 November 2013 21:11, Anurag Bhatia m...@anuragbhatia.com wrote: Hello everyone! Greetings of the day. I am kind of (badly) stuck with multiple routers and not able to recover the root password. It's Juniper M7i. I have followed the Juniper support page as given here - http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland strange enough that it worked with one of routers I have but failed on rest all. I am getting stuck on Step #12. As I give boot -s to get into single user mode of BSD, system next asks me for root password and hence I am out of luck to get into recovery mode. I tried pressing enter on that prompt as well but no luck. I am connecting to router via console and do have physical access to router(s). Was wondering if someone has seen similar issues and could guide on what I am doing wrong? Most of other help pages I have seen on net have same exact steps as given on that page. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, Nov 6, 2013 at 1:30 PM, Landon landonstew...@gmail.com wrote: We (iWeb AS32613) are currently making great strides in getting out from under the volume of reports received and getting on top of things. Incidentally, I'd suggest that an ounce of prevention is worth a pound of cure. Simply block outbound tcp port 25 for new hosting customers on a tell me if you want it open basis. Don't make 'em jump through hoops: if they want it open, open it. But for everybody who doesn't tell you they want it open, keep it closed. Then analyze your data traffic for a month or two and close the port on any old customers that haven't sent any email. By doing so, you restrict the potential source of the problem to just those customers who intentionally generate email from their hosted service. Non-email using customers who get hit with worms and spambots will bounce off your shield. Also, you force spammers to bring themselves to your notice before they can send any mail -- something they're disinclined to do. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Recovery mode on Juniper M7i
Can you paste in the output after 'boot -s' , I came across several issues while recovering Root Password, But never faced this :) On Thu, Nov 7, 2013 at 2:41 AM, Anurag Bhatia m...@anuragbhatia.com wrote: Hello everyone! Greetings of the day. I am kind of (badly) stuck with multiple routers and not able to recover the root password. It's Juniper M7i. I have followed the Juniper support page as given here - http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland strange enough that it worked with one of routers I have but failed on rest all. I am getting stuck on Step #12. As I give boot -s to get into single user mode of BSD, system next asks me for root password and hence I am out of luck to get into recovery mode. I tried pressing enter on that prompt as well but no luck. I am connecting to router via console and do have physical access to router(s). Was wondering if someone has seen similar issues and could guide on what I am doing wrong? Most of other help pages I have seen on net have same exact steps as given on that page. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com
Re: Recovery mode on Juniper M7i
Hi sure Please find screenshot... @Mehmet - I checked that in daytime and didn't found anything specific about that version. Sorry don't have it handy with me right now but will check exact version again in morning and will update you. On Wed, Nov 6, 2013 at 10:33 PM, Rakesh M raaki...@gmail.com wrote: Can you paste in the output after 'boot -s' , I came across several issues while recovering Root Password, But never faced this :) On Thu, Nov 7, 2013 at 2:41 AM, Anurag Bhatia m...@anuragbhatia.com wrote: Hello everyone! Greetings of the day. I am kind of (badly) stuck with multiple routers and not able to recover the root password. It's Juniper M7i. I have followed the Juniper support page as given here - http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland strange enough that it worked with one of routers I have but failed on rest all. I am getting stuck on Step #12. As I give boot -s to get into single user mode of BSD, system next asks me for root password and hence I am out of luck to get into recovery mode. I tried pressing enter on that prompt as well but no luck. I am connecting to router via console and do have physical access to router(s). Was wondering if someone has seen similar issues and could guide on what I am doing wrong? Most of other help pages I have seen on net have same exact steps as given on that page. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com
Re: Recovery mode on Juniper M7i
Direct access to the bootstrap loader should bypass any access restrictions configured on the box. However, it sounds like the device is not dropping into single-user mode. I would suggest removing and wiping the CF card. Then boot from alternative media (USB) and snapshot on to the blank card. Cheers, Jeff On 11/6/2013 3:28 PM, Pedro Cavaca wrote: Maybe you're not doing anything wrong and someone tweaked the routers and marked the console as insecure, a previous owner maybe? http://superuser.com/questions/85536/securing-freebsd-in-single-user-mode http://www.freebsd.org/cgi/man.cgi?query=bootsektion=8 HTH. On 6 November 2013 21:11, Anurag Bhatia m...@anuragbhatia.com wrote: Hello everyone! Greetings of the day. I am kind of (badly) stuck with multiple routers and not able to recover the root password. It's Juniper M7i. I have followed the Juniper support page as given here - http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland strange enough that it worked with one of routers I have but failed on rest all. I am getting stuck on Step #12. As I give boot -s to get into single user mode of BSD, system next asks me for root password and hence I am out of luck to get into recovery mode. I tried pressing enter on that prompt as well but no luck. I am connecting to router via console and do have physical access to router(s). Was wondering if someone has seen similar issues and could guide on what I am doing wrong? Most of other help pages I have seen on net have same exact steps as given on that page. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com -- Jeff Sorrels Network Administrator KanREN, Inc jlsorr...@kanren.net 785-856-9820, #2
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, Nov 6, 2013 at 4:45 PM, William Herrin b...@herrin.us wrote: Incidentally, I'd suggest that an ounce of prevention is worth a pound of cure. Simply block outbound tcp port 25 for new hosting customers on a tell me if you want it open basis. Or to thwart those clever spammers, block inbound SYN/ACK packets with a source port of 25. This catches the ones who send SYNs out other providers with your network's source addresses which bypasses most simple ACLs. --Doug
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, Nov 6, 2013 at 1:30 PM, Landon landonstew...@gmail.com wrote: How much trouble does your abuse department go to in order to obfuscate headers when providing evidence of spamming activity regardless of if it?s intentional/professional spammer activity or some kind of malware infection allowing a third party to spam. Especially for the pro spammers, we don?t want them list washing anything or worse yet becoming privy to spamtrap data if the reporting party wasn?t smart enough to obfuscate their own data before sending in the report. Howdy, It depends on the exact situation, but the general-purpose answer is: none. zero. zip. The customer usually can't act on your information unless he can line it up with an entry in his own logs. He needs lots of details in the headers to figure out which computer or which of his users the message came from. And he needs that information to determine whether the message really came from his system -- headers get forged, you know. Because this is an issue inherent primarily with bulk mail, we remove all identifying information *except* the unsub link, which *should* have a unique identifying token embedded within, from which the sender *should* be able to determine the complainant's email address. And, if there is no such link, we use that as an opportunity to educate them as to *why* they need to include such a link (mind you, in order to be accredited with us the sender has to have already demonstrated that they comply with including an unsub link, but because many of our accreditation customers are ESPs, their customers may sometimes not be modelling 100% of best practices). Regardless of unsub link, or anything else, if we get a spam complaint against one of our customers, we hold their feet to the fire, and require them to explain exactly how the particular list was built, how the address was acquired, etc.. Failure to do so can (and usually does) result in termination of their accreditation - in the case of an ESP, they have to take corrective measures against their spamming customer or the ESP will lose their accreditation. Anne Anne P. Mitchell, Esq. Author: Section 6 of the CAN-SPAM Act of 2003 CEO/President Institute for Social Internet Public Policy http://www.ISIPP.com Member, Cal. Bar Cyberspace Law Committee How do you get to the inbox instead of the spam filter? SuretyMail! Helping businesses keep their email out of the junk folder since 1998 http://www.isipp.com/SuretyMail
Re: Reverse DNS RFCs and Recommendations
In message 5964ada4-8fcf-4fce-9e64-7474ccae5...@consultant.com, Cutler James R writes: Dynamic DNS providers will undoubtably endeavor to make money from and SRV entries for publicly-reachable services in SOHO and home networks. Dynamic DNS providers are normally not delegated authority to provide PTR records for ISP managed addresses, making provision of complementary and PTR records highly unlikely. Because of the cost of scaling and delegation issues I agree with Jason and see no compelling business case for rDNS services for SOHO or residential users. Did you BOTHER TO READ the draft before commenting as the comments imply that you haven't. Nothing in the draft is more difficult than is what is already being done inside enterprises networks today every single minute of the day. Enterprise DHCP servers construct DNS PTR records and add them to the DNS using TSIG signed UPDATE requests. They do it at one per machine. This is DHCP servers constucting a DNS KEY record and adding it to the DNS using TSIG signed UPDATE requests. The amount is ONE per customer. ISP's already support a PTR record per customer so your scale arguement is blown out of the water. This is draft addresses the delegation issue by automating it so that any CPE device from any manufacture can perform the delegation without humans being involved. Mark It's dead, Jim James R. Cutler james.cut...@consultant.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, Nov 6, 2013 at 5:16 PM, Anne P. Mitchell, Esq. amitch...@isipp.com wrote: Because this is an issue inherent primarily with bulk mail, we remove all identifying information *except* the unsub link, which *should* have a unique identifying token embedded within, from which the sender *should* be able to determine the complainant's email address. Hi Anne, Judging from Landon's web page a vanishingly small percentage of his customers are in the opt-in mailing list business. He's in the generic hosting business, so aside from the abusers his customers will tend to be heavy on single-recipient administrative emails rather than mailing lists. If you send him a complaint scrubbed in the manner you describe, he won't have enough information to act. You'd basically be wasting both his time and yours. Failure to do so can (and usually does) result in termination of their accreditation Accreditation of what? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Do you obfuscate email headers when reporting spam issues to clients?
so aside from the abusers his customers will tend to be heavy on single-recipient administrative emails rather than mailing lists. Then, if they are truly one-to-one administrative emails, that's rather odd if they are generating a disproportionate number of spam complaints, dontcha think? Unless they are inserting too much marketing into to them (always dicey). Failure to do so can (and usually does) result in termination of their accreditation Accreditation of what? I'll respond more fully to this offlist, as it's OT, but the short answer is that we accredit email senders who are adhering to best practices (not unlike ReturnPath, only we're the other white meat). Anne Anne P. Mitchell, Esq. Author: Section 6 of the CAN-SPAM Act of 2003 CEO/President Institute for Social Internet Public Policy http://www.ISIPP.com Member, Cal. Bar Cyberspace Law Committee How do you get to the inbox instead of the spam filter? SuretyMail! Helping businesses keep their email out of the junk folder since 1998 http://www.isipp.com/SuretyMail
RE: Level3 and ATT Latency
Comcast to XO due to Comcast's TATA peering issue. Ongoing. J.J. From: Siegel, David david.sie...@level3.com Sent: Wednesday, November 06, 2013 7:10 AM To: Tassos Chatzithomaoglou; nanog@nanog.org Subject: [GRAYMAIL] RE: Level3 and ATT Latency As a matter of pure competitive intelligence gathering (i.e. I do not mean this as a rhetorical question), which providers list peering issues on their portal? Particularly when they might be a bit more of an ongoing nature vs. a concrete outage? Dave -Original Message- From: Tassos Chatzithomaoglou [mailto:ach...@forthnet.gr] Sent: Tuesday, November 05, 2013 11:54 PM To: nanog@nanog.org Subject: Re: Level3 and ATT Latency Unfortunately, many issues don't appear (deliberately?) as network events on their portal. -- Tassos Jason Baugher wrote on 6/11/2013 06:46: For what it's worth, Level3 finally told us they had a peering issue with ATT. They ended up re-routing traffic for the time being until they identify the issue. Of course, for some reason a peering issue doesn't warrant a Network Event on their portal... On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist da...@crmls.org wrote: I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today. They just got it spliced back up. Not sure if it is related to your latency. David -Original Message- From: Eric Williams [mailto:ewilli...@connectria.com] Sent: Tuesday, November 05, 2013 11:49 AM To: nanog@nanog.org Subject: Level3 and ATT Latency Is anybody else seeing or having major latency between Level 3 and ATT today? We are multi-homed with Level 3 being one of our ISP's and had to divert traffic after seeing these issues. http://www.internetpulse.net/ Eric
Re: Level3 and ATT Latency
On Wed, Nov 06, 2013 at 10:51:08PM +, J.J. Mc Kenna wrote: Comcast to XO due to Comcast's TATA peering issue. Ongoing. I'd love to see verifiable public data to back up that claim. Kind regards, Job pgpkM0i4UwL6b.pgp Description: PGP signature
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, Nov 6, 2013 at 12:30 PM, Landon landonstew...@gmail.com wrote: Hello, How much trouble does your abuse department go to in order to obfuscate headers when providing evidence of spamming activity regardless of if it’s intentional/professional spammer activity or some kind of malware infection allowing a third party to spam. I suggest using separate spam traps for reporting, from spam traps used to develop filters and blacklists, seeded/published at similar places. Don't report spam hitting secret spamtraps; just use what is received at secret spam traps to develop the spam corpus, blacklists, or filtering rules. There are exceptions, but when reporting spam: the recipient needs actionable information. Not just someone claiming that there is spam from them. If they are the upstream IP network abuse contact or operator of a large mail server, they should see who it came from, who it went to, the timestamps, message ids, and full headers. The stuff you could remove to make list washing hard or disguise a spam trap, is the same stuff the receiver of your report needs, to efficiently and effectively help identify their outbreak, and put a stop to the spam, so you're also making it hard for legitimate contacts to find the appropriate log entry, and match the e-mail message to the account it came from. -- -JH
Re: Do you obfuscate email headers when reporting spam issues to clients?
If you send him a complaint scrubbed in the manner you describe, he won't have enough information to act. You'd basically be wasting both his time and yours. As many here know, I spent 4 years on the receiving end of the abuse@savvisbox: when I was hired it was for multiple roles, but the abuse@was a primary. Savvis had a significant spam problem when I arrived, and until just a few months before I left, had literally none. First of all, *every* abuse email should be seriously investigated, regardless of header obfuscation. Secondly, header obfuscation is NOT a waste of time for abuse@ - in fact, it is only marginally less useful than a fully loaded complaint. The reason is that even the smallest (or, conversely, the most expertly organized) spammer will leave a complaint trail. The complaints grow in importance as they grow in number: ten complaints in the morning abuse email tells me that there is a serious problem with the sender, even if every single header and other identifying information is removed from the complaints. Ten complaints may not indicate malice (although it usually does), but it does tell abuse@ to start their resolution clock. Any abuse department which outright rejects (or claims they are unable to process) an obfuscated (munged) complaint is not to be trusted - period. The abuse department that wont respond to munging is deliberately closing their eyes to abuse on their network. Any abuse@ that fails to immediately act on reports of third-party beneficiaries (for example, drop boxes or ordering websites) on their network is doing the same thing. As a complainant, rather than the abuse@ recipient, I will always scrub my reports *thoroughly*, by removing the significant digits of time stamps, any unique identifiers I can find (from message-ID to unsubscribe links), and anything else I think can possibly be used to listwash. The only exception to this is if I am reporting to someone I know and explicitly trust (and there are damn few of those left). As the abuse@ guy, I would strongly encourage scrubbed reports, even reports which prove nothing other than an email went out that was unwanted (as opposed to unsolicited - it's not uncommon for people to make spam complaints rather than unsubscribe from mailings they legitimately subscribed to). There are a multitude of internal [ proprietary] tools at most ISPs that can lead to the appropriate determination as to what is or isn't spamming, but for the tools to be used, there needs to be a starting complaint(s). //Alif On Wed, Nov 6, 2013 at 4:40 PM, William Herrin b...@herrin.us wrote: On Wed, Nov 6, 2013 at 5:16 PM, Anne P. Mitchell, Esq. amitch...@isipp.com wrote: Because this is an issue inherent primarily with bulk mail, we remove all identifying information *except* the unsub link, which *should* have a unique identifying token embedded within, from which the sender *should* be able to determine the complainant's email address. Hi Anne, Judging from Landon's web page a vanishingly small percentage of his customers are in the opt-in mailing list business. He's in the generic hosting business, so aside from the abusers his customers will tend to be heavy on single-recipient administrative emails rather than mailing lists. If you send him a complaint scrubbed in the manner you describe, he won't have enough information to act. You'd basically be wasting both his time and yours. Failure to do so can (and usually does) result in termination of their accreditation Accreditation of what? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, 6 Nov 2013, Landon wrote: Hello, We (iWeb AS32613) are currently making great strides in getting out from under the volume of reports received and getting on top of things. How much trouble does your abuse department go to in order to obfuscate headers when providing evidence of spamming activity regardless of if its intentional/professional spammer activity or some kind of malware infection allowing a third party to spam. Especially for the pro spammers, we dont want them list washing anything or worse yet becoming privy to spamtrap data if the reporting party wasnt smart enough to obfuscate their own data before sending in the report. If you know you have pro spammers on your network, the question isn't how much to obfuscate spam complaints you receive...it's why haven't you terminated the customer(s)? As for the rest, if the reporter wants obfuscation, it's on them to do it. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, Nov 6, 2013 at 6:27 PM, Nonaht Leyte alif.terran...@gmail.comwrote: Any abuse department which outright rejects (or claims they are unable to process) an obfuscated (munged) complaint is not to be trusted - period. This is very credible from someone admitting to scrubbing reports, of information required by some abuse teams to appropriately process complaints, *NOT*. You say scrub Many would say: munging evidence, so that it is no longer admissible, or usable as supporting documentation to suspend or terminate a subscriber's service. There are abuse departments that would ignore such reports, or reply, requesting information before proceeding, and they have that right; especially, if the scrubbed reports don't offer sufficient evidence, for their particular investigation workflow to function. As a complainant, rather than the abuse@ recipient, I will always scrub my reports *thoroughly*, by removing the significant digits of time stamps, any unique identifiers I can find (from message-ID to unsubscribe links), regardless of header obfuscation. Secondly, header obfuscation is NOT a waste of time for abuse@ - in fact, it is only marginally less useful than a fully loaded complaint. The reason is that even the smallest (or, This is an assumption, that is only true in some cases. conversely, the most expertly organized) spammer will leave a complaint trail. The complaints grow in importance as they grow in number: ten Often the spammer will not leave a complaint trail; they may very well have sent 1000 messages, that are logged with various different From: addresses. However, non-spammers will also often leave a complaint trail; to give an example: very often, non-spammers will even forward their own mail to another mailbox provider, e.g. Yahoo/AOL, and report duly forwarded spam that arrives in their forwarding destination inbox, as spam originating from the forwarding provider. Without the recipient address; the provider doing the mail forwarding has no idea if it is the forwarded mail, or ordinarily sent mail that is being filed as spam. -- -JH
Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
valdis.kletni...@vt.edu wrote: You still haven't explained how the memories of those who are at the table help, when the NSA plant has very good reasons to say they're not an NSA plant, and you haven't explained how you can show they *are* a plant. That is a problem between NSA, which recommended a person, and the person recommended by NSA. Masataka Ohta
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, Nov 6, 2013 at 5:46 PM, Anne P. Mitchell, Esq. amitch...@isipp.com wrote: so aside from the abusers his customers will tend to be heavy on single-recipient administrative emails rather than mailing lists. Then, if they are truly one-to-one administrative emails, that's rather odd if they are generating a disproportionate number of spam complaints, dontcha think? Unless they are inserting too much marketing into to them (always dicey). Hi Anne, In any given above-board hosting operation there are a whole lot of things going on: There's the small ad-hoc lists where an address is typoed and the mail meant for Uncle George now goes to a random stranger. There's the emails to formerly dead addresses now resurrected by new owners. There's the folks who signed up for something and decided to unsubscribe by reporting it as spam. There the folks playing pranks on a friend by putting his address in a bunch of please contact me web pages, causing the target to be one-on-one solicited by a bunch of individual salesmen. There are the server owners whose security was breached and their happy web app is now being used to relay lots of spam. And there's the spammer owned servers spewing out spam. In each of these situations save the final one, obfuscating information in the reported spam email only serves to make it difficult or impossible to identify and stop the problem. If you start with the assumption that the origin is a spammer until proven otherwise it becomes a self-fulfilling prophecy -- because when you report the obfuscated message, they can't track it down and fix it! Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, Nov 6, 2013 at 7:27 PM, Nonaht Leyte alif.terran...@gmail.com wrote: As many here know, I spent 4 years on the receiving end of the abuse@savvisbox: when I was hired it was for multiple roles, but the abuse@was a primary. Savvis had a significant spam problem when I arrived, and until just a few months before I left, had literally none. Howdy, Out of curiosity, what changed a few months before you left? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Level3 and ATT Latency
AS13030 - http://www.init7.net/en/status/ -Chris On Wed, Nov 6, 2013 at 10:10 AM, Siegel, David david.sie...@level3.comwrote: As a matter of pure competitive intelligence gathering (i.e. I do not mean this as a rhetorical question), which providers list peering issues on their portal? Particularly when they might be a bit more of an ongoing nature vs. a concrete outage? Dave -Original Message- From: Tassos Chatzithomaoglou [mailto:ach...@forthnet.gr] Sent: Tuesday, November 05, 2013 11:54 PM To: nanog@nanog.org Subject: Re: Level3 and ATT Latency Unfortunately, many issues don't appear (deliberately?) as network events on their portal. -- Tassos Jason Baugher wrote on 6/11/2013 06:46: For what it's worth, Level3 finally told us they had a peering issue with ATT. They ended up re-routing traffic for the time being until they identify the issue. Of course, for some reason a peering issue doesn't warrant a Network Event on their portal... On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist da...@crmls.org wrote: I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today. They just got it spliced back up. Not sure if it is related to your latency. David -Original Message- From: Eric Williams [mailto:ewilli...@connectria.com] Sent: Tuesday, November 05, 2013 11:49 AM To: nanog@nanog.org Subject: Level3 and ATT Latency Is anybody else seeing or having major latency between Level 3 and ATT today? We are multi-homed with Level 3 being one of our ISP's and had to divert traffic after seeing these issues. http://www.internetpulse.net/ Eric
