That's understandable. I've been in the anti-spam race for a long time now. I wish I had as much time to contribute to the fight as I one did. For my MTA I use Canit-Pro. That gives me a good window in the SMTP dialog as it's happening thanks to good old Sendmail's milter options. I'm needing something that's more network-centric though. I need something that can listen on a promisc port and listen for network reconnaissance scans and actual network-based attacks so it can alert me and I can react. I was watching traffic on a couple span ports tonight between my ISP core and the border routers. Based on relatively simple observations I saw malicious horse shit and added the sources to our RTBH. If only I could automate that process...
Out of curiosity, what tools or methods are you using to detect bad behavior and then block it? I'm always on the lookout for new tools for my toolkit. I use Fail2ban for SSH scanners. I've used Port Sentry for port scanners. I haven't found any good tools for blocking SMTP bots guessing email addresses with Rumplestilskin attacks, though I would love to employ one. Currently I'm in search of a method to tie such tools into my RTBH trigger router to blackhole bad hosts at my network edges. I could script something together but I'd at least be interested in looking at an existing tool if for no other reason than to get ideas.
How about improving the filtering capabilities? I'd like to have what Eudora and Claris Emailer had 10+ years ago. Let me play a different sound file when certain rules are matched. Let me not generate a popup alert when messages match certain rules (ie I want to archive them but I don't care to see them). Even Outlook can do that.
How about email archiving abilities built into Thunderbird? That would be nice. I use Thunderbird for my mailing list account. I get a couple thousand messages a day and I never delete mail. Archiving options would be nice.
By far the absolute biggest, largest, most grand and lacking feature is the ability to store Thunderbird settings on the damn server so I can fire up Thunderbird from multiple locations and still have full access to my configured filters. Please!!! I would pay good money for that feature.
I'll keep you on my list. So far we've only been doing internal testing. We have a lot of fiber work to do in the plant before external testing can proceed. I'll see if I can't get you included in a beta program when the plant is ready though. Have a good weekend.
The speed issue is definitely something we're tackling right now. The previous DSL speeds were just atrocious. We have raised the speeds on all DSL customers in our Western areas. We can't do much for those in the Eastern areas with our existing infrastructure I'm afraid. We are replacing the entire DSL infrastructure over East with a distributed ADSL2+ solution to remedy the situation. In your neck of the woods I have good news. We will be deploying FTTH in our Western rural areas which should include your area (I don't know your exact location but I know that you're on DSL which we only deploy in the countryside). I don't have an exact timeframe for you but I expect it to be available by mid to late summer. The initial offering will be voice & data only. Video will come in a future project.
Hopefully that will give our users the "fat pipe" they need for the next generation of Internet technologies. The bandwidth estimates for online content like Netflix online movie downloads are unreal. I don't believe we've decided what speed options to offer but I imagine that it would at least be comparable to the cable speeds in our CLEC communites: 4, 7, 12.
So basically you have to provide both the key for the outer volume and the key for the hidden volume to prevent damage to the hidden volume. Essentially it is trivially easy to damage the hidden volume. That's not the page I was looking for but it essentially talks about the same thing. I wasn't aware of the 2nd-key trick to prevent damage though. That helps but I can easily see that being forgotten; I'm sure I'd forget it if I used the hidden partition.
he hidden-partition feature is the bees knees, especially for those extra secret documents, just hide them behind some porn, financial data or something else which you access and make changes to regularly (to hide if you are making changes to the hidden volume).
I could be mistaken here but I could have sworn that the install docs/HOWTO unequivocally said to never ever ever write data to the dummy volume once you've started using the real hidden volume. Something about overwriting blocks of the hidden volume because TC and the dummy volume has no idea where the dummy volume ends and the real hidden volume begins. It's been a while since I read the docs when I implemented this on my new laptop (2 weeks back) but I was pretty sure that's what they said.
Not all ISPs abuse the USF like the RBOCs. I work for a small independent telco which covers a number of rural exchanges. We were offering DSL in towns of 200 people long before many of the larger metropolitan areas like Kansas City. We're currently deploying ADSL2+ and FTTH in areas to ramp up our bandwidth offering, provide triple-play and reach further into the farthest most confines out of exchanges to offer service to customers that previously had only POTS. All of this is being paid for by the USF in a cost-recovery manner. The town we CLEC with cable services are all ROI-based.
So, in short, not all ILECs abuse the USF. Some of us actually use it for the purposes in which it was intended.
Oh, and I'm working on having IPv6 deployed this year. Good luck finding more than a handful of residential ISPs offering IPv6 in this country.
While I think this is great I have another gripe that I wish ICANN would address. We resell domains to our ISP customers. We had one expire yesterday which isn't that uncommon of an occurrence. We had sent the customer an email alerting to the impending expiration and they never acted and the domain expired. As expected they noticed the problem the next morning and now it's a big deal; they were no longer receiving email from their customers and email was mission critical to them (interesting considering that they couldn't be bothered to read an email from their Internet provider). We renewed the domain at about 11am. I told them that it would probably be about half a day before the NS change was pushed to the root servers and the cached records expired on their customers' NSs. This morning it is still apparently a problem. I checked one of our NSs and sure enough it still had the registrar's temporary NSs instead of the NSs we use for customer zones. I queried a few NSs of other providers and they had the right info. I flushed my cache and the records fixed themselves. My earlier dig that showed the wrong NSs also showed two TTL counters. At the time the counter on the NSs was at just under 14hrs. The other was just under 48hrs. The registrar apparently set the TTL value on the domain to somewhere between 24 and 72 hours.
The significance of this may not be obvious to everyone so let me explain. The TTL (Time To Live) value is part of the SOA (Start of Authority) in a DNS zone file. The TTL value is how the administrator of the authoritative NS tells the client's DNS resolver to cache the DNS responses. Ie, if I lookup the MX for blah.com and the TTL is 300 then I will cache that response for 5 minutes and I'll use that cached response for any subsequent queries until the TTL expires. I won't bug you or waste your bandwidth until then. It's a way of reducing load on the authoritative NSs and keep from wasting bandwidth across the Internet for redundant queries (think of a caching HTTP proxy).
The effect of the registrar's taking this step manifests itself when the domain gets renewed. The domain is renewed as soon as service is interrupted and the problem is discovered. The registrar submits updates to Verisign for the COM zone file twice a day. Depending on when the domain was renewed with respect to when the registrar sends the updates as well as the SOA values (that control caching) dictate how long it will be before the domain is functional again. The registrar, Spirit Domains, chose to set the TTL to something between 24 and 72 hours. That's 1-3 days for the math challenged among us. That's absurdly long. I contend that most renewals of expired domains happen within 1-12 hours of the expiration for domains that are actually used. Why any registrar would choose to use a TTL longer than an hour or two is beyond me. I can understand the concern of the load this would put on their NSs. The answer is simple though. For the first day set the TTL to 1hr. On the second day set the TTL to 6 hours. On day 3 set it to 12 hours. On day 7 set it to whatever you want. 98% of expired domains that are going to be renewed would surely be done within 3 days. That would keep the MTTR for the function of the domain down to a reasonable level. 24-72hrs is not a reasonable level.
I called Spirit Domains to chew on them earlier this morning. The guy I spoke with said that he didn't know why that TTL value was chosen but that it was what they always used. He said it was definitely between 24 and 72 hours. That's horse shit. On top of that, in the temp zone they created also had a MX record. It was the MX record that had the extra high TTL of +48hrs. Even if the NS records expired in 24 hours the MX records would have still been cached and would have still been pointed at Spirit Domains SMTP blackhole: grey-area.mailhostingserver.com.
In short I would like to see ICANN address the problem of what registrars put in their expired domain zone files. The TTLs should be kept low and increment slowly. Their should not be a MX record under any circumstances.
Isn't that what I implied? Why else would I have asked about ASNs and RIR allocations? I'm going to add Zango to my network sinkhole. With their ASN or netblocks I can define the next-hop as my sinkhole. The domain names will be used to let me pretend that they don't even exist on my NSs. Zero client config involved.
I'm sure I'm not the only one that would like to block Zango at the network level. Does anyone have the repository of information needed to create an effective block? I'm talking about RIR assignments, ASNs, SWIPed allocations, domain names, etc. Does anyone know of such a source? With this information I can ensure that none of my users ever have to put up with this Zango horse shit again.
Think about what you're saying. These are backup batteries and will ideally never get used.
The batteries are not just for backup purposes. They are in service 24/7/365. The cabinets themselves run off of -48VDC provided by the string of batteries. The cabinets do not run off of VAC or unregulated VDC. Therefore the batteries are always in production, not just when you VAC input is unavailable. I work for a telco.
Slashdot Mirror
That's understandable. I've been in the anti-spam race for a long time now. I wish I had as much time to contribute to the fight as I one did. For my MTA I use Canit-Pro. That gives me a good window in the SMTP dialog as it's happening thanks to good old Sendmail's milter options. I'm needing something that's more network-centric though. I need something that can listen on a promisc port and listen for network reconnaissance scans and actual network-based attacks so it can alert me and I can react. I was watching traffic on a couple span ports tonight between my ISP core and the border routers. Based on relatively simple observations I saw malicious horse shit and added the sources to our RTBH. If only I could automate that process...
Out of curiosity, what tools or methods are you using to detect bad behavior and then block it? I'm always on the lookout for new tools for my toolkit. I use Fail2ban for SSH scanners. I've used Port Sentry for port scanners. I haven't found any good tools for blocking SMTP bots guessing email addresses with Rumplestilskin attacks, though I would love to employ one. Currently I'm in search of a method to tie such tools into my RTBH trigger router to blackhole bad hosts at my network edges. I could script something together but I'd at least be interested in looking at an existing tool if for no other reason than to get ideas.
How about email archiving abilities built into Thunderbird? That would be nice. I use Thunderbird for my mailing list account. I get a couple thousand messages a day and I never delete mail. Archiving options would be nice.
By far the absolute biggest, largest, most grand and lacking feature is the ability to store Thunderbird settings on the damn server so I can fire up Thunderbird from multiple locations and still have full access to my configured filters. Please!!! I would pay good money for that feature.
Moderators, please mod up the parent and not my post. He's the guy who provided the needed info. I just asked the question.
Could someone please post info or a link to info on how each senator voted? I'm in the mood for sending a few flaming emails.
is where's my damn 50" TV? Come on, at least hold up your end of the bargain!
I'll keep you on my list. So far we've only been doing internal testing. We have a lot of fiber work to do in the plant before external testing can proceed. I'll see if I can't get you included in a beta program when the plant is ready though. Have a good weekend.
Hopefully that will give our users the "fat pipe" they need for the next generation of Internet technologies. The bandwidth estimates for online content like Netflix online movie downloads are unreal. I don't believe we've decided what speed options to offer but I imagine that it would at least be comparable to the cable speeds in our CLEC communites: 4, 7, 12.
Hello, David. It's been a while. How are things?
"In order to clamp down on the practice of tit-for-tat feedback, eBay will begin preventing sellers from leaving negative feedback on buyers."
I was going to summarize this but that one sentence is about as basic as it gets.
I would suggest one that you aren't afraid to lose or have destroyed in transit.
Protection of Hidden Volumes Against Damage
So basically you have to provide both the key for the outer volume and the key for the hidden volume to prevent damage to the hidden volume. Essentially it is trivially easy to damage the hidden volume. That's not the page I was looking for but it essentially talks about the same thing. I wasn't aware of the 2nd-key trick to prevent damage though. That helps but I can easily see that being forgotten; I'm sure I'd forget it if I used the hidden partition.
I could be mistaken here but I could have sworn that the install docs/HOWTO unequivocally said to never ever ever write data to the dummy volume once you've started using the real hidden volume. Something about overwriting blocks of the hidden volume because TC and the dummy volume has no idea where the dummy volume ends and the real hidden volume begins. It's been a while since I read the docs when I implemented this on my new laptop (2 weeks back) but I was pretty sure that's what they said.
Hit me offline: routerstud at the Google Mail domain dot com. (don't laugh; I didn't pick it...) We actually do consulting for service providers too.
So, in short, not all ILECs abuse the USF. Some of us actually use it for the purposes in which it was intended.
Oh, and I'm working on having IPv6 deployed this year. Good luck finding more than a handful of residential ISPs offering IPv6 in this country.
Insert obligatory statements about why NAT is bad and why people who argue in favor of NAT don't know a damn thing about networking.
phew! What's that smell?
USS Jimmy Carter replaced the USS Parche
The significance of this may not be obvious to everyone so let me explain. The TTL (Time To Live) value is part of the SOA (Start of Authority) in a DNS zone file. The TTL value is how the administrator of the authoritative NS tells the client's DNS resolver to cache the DNS responses. Ie, if I lookup the MX for blah.com and the TTL is 300 then I will cache that response for 5 minutes and I'll use that cached response for any subsequent queries until the TTL expires. I won't bug you or waste your bandwidth until then. It's a way of reducing load on the authoritative NSs and keep from wasting bandwidth across the Internet for redundant queries (think of a caching HTTP proxy).
The effect of the registrar's taking this step manifests itself when the domain gets renewed. The domain is renewed as soon as service is interrupted and the problem is discovered. The registrar submits updates to Verisign for the COM zone file twice a day. Depending on when the domain was renewed with respect to when the registrar sends the updates as well as the SOA values (that control caching) dictate how long it will be before the domain is functional again. The registrar, Spirit Domains, chose to set the TTL to something between 24 and 72 hours. That's 1-3 days for the math challenged among us. That's absurdly long. I contend that most renewals of expired domains happen within 1-12 hours of the expiration for domains that are actually used. Why any registrar would choose to use a TTL longer than an hour or two is beyond me. I can understand the concern of the load this would put on their NSs. The answer is simple though. For the first day set the TTL to 1hr. On the second day set the TTL to 6 hours. On day 3 set it to 12 hours. On day 7 set it to whatever you want. 98% of expired domains that are going to be renewed would surely be done within 3 days. That would keep the MTTR for the function of the domain down to a reasonable level. 24-72hrs is not a reasonable level.
I called Spirit Domains to chew on them earlier this morning. The guy I spoke with said that he didn't know why that TTL value was chosen but that it was what they always used. He said it was definitely between 24 and 72 hours. That's horse shit. On top of that, in the temp zone they created also had a MX record. It was the MX record that had the extra high TTL of +48hrs. Even if the NS records expired in 24 hours the MX records would have still been cached and would have still been pointed at Spirit Domains SMTP blackhole: grey-area.mailhostingserver.com.
In short I would like to see ICANN address the problem of what registrars put in their expired domain zone files. The TTLs should be kept low and increment slowly. Their should not be a MX record under any circumstances.
You mean it's an effort to stem the problem of other domain tasters, not the domain taster called NSI.
Well, I guess I'm not going to be buying any U2 CDs. Oh wait, I never have! Seriously I wouldn't recognize a single one of their songs.
Oh, osrry. I couldn't tell with this new Slashdot CSS beta format. It makes it really hard to follow the threads, especially with AC comments hidden.
Isn't that what I implied? Why else would I have asked about ASNs and RIR allocations? I'm going to add Zango to my network sinkhole. With their ASN or netblocks I can define the next-hop as my sinkhole. The domain names will be used to let me pretend that they don't even exist on my NSs. Zero client config involved.
I'm sure I'm not the only one that would like to block Zango at the network level. Does anyone have the repository of information needed to create an effective block? I'm talking about RIR assignments, ASNs, SWIPed allocations, domain names, etc. Does anyone know of such a source? With this information I can ensure that none of my users ever have to put up with this Zango horse shit again.
The batteries are not just for backup purposes. They are in service 24/7/365. The cabinets themselves run off of -48VDC provided by the string of batteries. The cabinets do not run off of VAC or unregulated VDC. Therefore the batteries are always in production, not just when you VAC input is unavailable. I work for a telco.