Unless I completely missed it, this nut case never did say what sound card he was trying to use or what "XYZ" distrubtion is or what he was doing to confirm operations.
Yes, sound is a difficult thing to setup in linux. The fact that he had it running once is proof that it does indeed work. What ever he did in getting it to work the first time obviously wasn't persistant. I've never had a problem setting up sound under Linux, but I know what I'm doing.
Not anymore... they've abandoned just about everything but i386. And now they've abandoned their "free" distribution. Yes, there is still a freely downloadable version, but it's all a cruel joke to get everyone to debug (and develop) their commercial product for free.
I've switched to debian... if for no other reason than they don't abandon their various architectures.
This is not new by any stretch. Redhat has been dicking with the kernel and almost every package they ship for nearly a decade (possibly longer.) That's why it has always been a matter of policy on my part to build my own kernel from the "blessed" tree the instant a redhat machine is installed. Never, EVER, use the hacked-to-hell Redhat kernel. Kernel developers will generally ignore your bug reports, and redhat will ignore them too without a support contract.
If you have your own domain, then you are essentially acting as a "telco" in this sense. Additionally, everyone cannot have their own domain -- in fact, most will not even understand what a "domain name" is (made worse by registrars calling them "web addresses".)
... oh, like the OpenSSL ident strings. 12.0 used OpenSSH, but they have since stopped using OpenSSH code in IOS -- they either rolled their own or snarfed someone else's. They've removed almost all of the ident strings except for those put there by the compiler: GCC: (GNU) 2.95.3 20010315 (cisco p10 release), etc.
Unless you downloaded and compiled the binaries from the postgresql.org server(s), then you cannot say, for sure, Cisco has not added backdoors to the code.
Besides that, it is possible to recieve only the header, and then refuse to accept the rest of the message. TCP can take care of doing that.
I'll assume you mean the IP ADDRESS (stop using the word "headers"... we aren't talking firewalls here; mail servers don't process raw ip packets, so they cannot see the "TCP/IP headers".) Yes, the SMTP server can refuse to speak with anyone it chooses. It doesn't have to respond with "2xx Howdy"; it can respond with "5xx Take off you spammin' hoser." and close the connection. (Note: it does have to respond or the sender will simply try again or hand the message to someone else to get it to the server.)
As you've indicated yourself ([here]), such means of blocking spam are insufficient. No matter how many hosts you block, you'll eventually have to accept email from someone that's going to present spam -- namely one or more of the worlds major ISPs... you cannot block all email from, say, AOL when there are people on AOL with whom you need to be able to send/receive email. The "obvious" answer to this is to create a "whitelist". Well, those don't work very well either as the "mail from" is easily forged and looking for a key or password within the message *ding* requires receipt of the entire message which defeats the purpose. (Earthlink does this... if someone is not in my addressbook, then the message is dropped in a "suspect" folder.)
SPF (Sender Permitted From) can go a long way to limiting the ammount of forged spams. But it's going to take years to see this put in place.
If the recieving SMTP server recieves the header (finds a blacklisted IP address...
The "headers" aren't part of the SMTP protocol, they are part of the message... 'helo', 'mail from', and 'rcpt to' are the only parts of the protocol invoked before the message begins -- and they are all useless as they can be forged (well, except rcpt to, that one's gotta be right or the message goes nowhere.)
As we are talking about reducing wasted bandwidth, parsing headers isn't going to do it. The only way to parse the headers is the receive the entire message at which point, the bandwidth has been burned.
However, you are correct in that the sender's IP is known "for free". The other end of the tcp connection is known before either side has sent anything. This is the basis for blacklists.
Please pick one side or the other... if you're scanning headers, then you have the entire message and nothing is saved. If you're blacklisting the sender based on ip address, then no protocol interaction is required and bandwidth can be saved. In your original post, you're talking about headers, but now you're pitching sender ip address.
Woa! MTV plays music? I've never see any on any of their channels in the last decade (+/-). Seriously, I've seen more (and better) music videos on WE than MTV.
Next time you decide to belittle me, try actually reading what I posted first...
Do you even know what you wrote?
There are even more solutions I could go through.
Blocking e-mails, based upon the lack of a key in the subject line, would also be very easy on bandwidth if done on the server end. (eg. before downloading the message)
I guess not. You seem to have completely missed the point... the headers are part of the message; no bandwidth savings exist if the message has to be received to scan the headers; and yes, the entire message must be received to return a status code and thus prevent redelivery.
Filtering at the SMTP server does nothing to save the bandwidth already used in the transmission of the e-mail messages in the first place. Blacklists and whitelists both have been shown to be problematic at best for most instances.
You just cannot get it into your fat head... the only way to reduce bandwidth wasted to spam is to never receive the message in the first place which can only be done at the SMTP protocol ("the server") level. At that level, the only viable information for making any decision is the sending machine's IP address (i.e. blacklists.) You cannot reject a message based on the "headers" without having those headers in hand which means you have the whole freakin' message, and thus have not saved any bandwidth at all. (That's technically client side filtering, btw.) Most people don't have any control over their mail server; what might work for one, single, person, will not scale to work for hundreds or thousands of people...
As evilviperpoints out, most (ISP) spam blocking systems have proven insufficient. I would label them as highly ineffective -- many spams necessarily make it through because one cannot block entire ISPs without interfering with a high percentage of valid email, and client side filtering is complex, cumbersome, and does nothing to stem the tide of useless junk flooding the internet. Add to the problem, ISPs are lothe to constrain port 25 traffic within their network(s) to their own farm of mail servers due to the costs and increased liabilities including legal liabilities.
Nope. You're understanding is incorrect. The SMTP server has to receive the entire message in order to scan the headers and indicate to the sender the message was accepted or rejected. Simply dropping the connection as soon as spam is detected from the headers will not work... the sender will see that as incomplete and will reattempt delivery at a later time. The sender's IP address is the only thing that can be trusted (read: not forged by the spammer) prior to receiving the entire message. There's no bandwidth savings if the message gets transmitted.
[Note: The "headers" are not part of the SMTP protocol. They are part of the message.]
You obviously don't know how email works... please do the world a favor and never seek employment from an ISP; with application of such blind logic, your customers will want to kill you.
Here is what actually happens:
220 mail.bar.com ESMTP Sendmail 8.11.7/8.11.7; Mon, 5 Apr 2004 20:07:33 -0400 (EDT) HELO baz.com 250 mail.bar.com Hello localhost [127.0.0.1], pleased to meet you MAIL FROM: <foo@baz.com> 250 2.1.0 <foo@baz.com>... Sender ok RCPT TO: <foo@bar.com> 250 2.1.5 <foo@bar.com>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself message headers [blank line] message body . 250 2.0.0 i3607vD03645 Message accepted for delivery QUIT 221 2.0.0 mail.bar.com closing connection
You cannot base a rejection on the sender ("mail from") as spammers lie. They lie 100% of the time these days. The only thing you can trust is the IP of remote end of the connection. If you're accepting mail from dialup/dsl/cable modem IP ranges, then that's where you should be blocking... In the above quoted sequence, there are *6* points where the message can be properly refused... every response from the server from the initial connection banner to the "250... accepted".
The from:to pair may otherwise be valid. And in light of forged info, cannot safely be used to block messages. It's simply not enough information at hand without the text of the message. In order for your method of blocking to be effective, you'd have to block further email for at least a week. See, mail servers don't immediately attempt to re-deliver the message. (I don't know of any that would retry in less than 15min without explicit administrative changes.) And they will continue to retry until they have a valid status returned from the process -- "helo", "mail from", "rcpt to" can all be denied:
"data" can be immediately denied or it can be refused once it has received the entire message -- OR a set number of retries have been attempted (usually measured in time -- "will continue to retry for 4 days" -- instead of a hard "I tried 8 times")
All your scheme will accomplish is blacklisting an (ISP's) mail server(s) and/or blocking all communications between pairs of email addresses. How would you like it if your server(s) were blocked due to spammers forged headers? How would you like having your incoming emails dropped because the mail server saw a single message it didn't like even though it's from someone withwhom you regularly communicate? I didn't think so.
Better minds than ours (and certainly better than yours) have been pondering the problem of SPAM for years. If the solution were simple, we'd've done it by now. The current best solution is to eat the spam and process it as it goes into the inbox ("a client side filter"), but that does nothing to address all the (increasing) bandwidth wasted by spam -- which, btw, is the whole point of this little flamefest. There isn't a way to authoritatively decide "spam, not spam" without the contents of the entire message -- the various blacklists help, but they tend to create too many false positives. It may take only a small fragment of the text to reach a deciding point, but SMTP requires receipt of the entire message. Good luck getting that protocol changed and then implemented across the globe.
I'll give you half credit. *grin* You had 'em backwards. And it's not something the phone companies what you know about. I think BellSouth is still claiming your number is only portable within the same CO (i.e. I can change my carrier and keep the number, but not if I move out of range of my current CO) -- this is, of course, BS. However, I've not asked lately.
(I guess your phone company isn't scam^Wcharging you for LNP. I've been charged $0.35 per month since 6/99 by BellSouth -- they are allowed to charge me for exactly five years [as per NC PUC ruling].)
READ THE POST. Once the DATA phase has begun, the server is required to accept the entire message. The sender will not process a return code until after it completes delivery. If the connection is broken before then, IT WILL RETRY DELIVERY. The sender will not know the connection was intentionally broken.
(Of course, one could "tar pit" that connection and let sendmail (or whatever) shutdown it's end. But, that's a bit much.)
Soon enough, the costs of bandwidth and pay checks...
First, it takes very little bandwidth to be a huge f'ing spammer -- and bandwidth is extremely cheap these days. Second, there usually aren't any "pay checks" as there's just one idiot. Even the big "institutional" size spam outfits rarely consist of more than a dozen people.
There are a lot of stupid people in the world. Spammers will always be able to find them.
Blocking e-mails, based upon the lack of a key in the subject line...
Too late. Once the (smtp) DATA phase is underway, as would be required to get the "Subject:" header, the server is commited to receiving the entire message. The POP protocol has no support for sending anything but the entire message. IMAP does, but there are very few ISPs that offer IMAP access to your email. (what is it with [censored] webmail these days!) You've saved nothing in bandwidth. If you terminate the smtp connection mid-stream, the sender will eventually try again. And there's no way to tell that same message is coming in. Blocking the entire server is generally a Bad Idea (tm) -- you may end up blocking the mailserver(s) for an entire ISP. (SORBS already has this problem with their "spamtrap senders" blocklist.)
You seem to be stuck thinking the only bandwidth of value is that into your mail client. That's nothing. The true problem with spam is the volume of internet traffic at large being wasted by junk. Some have estimated as much as 25% of ALL the traffic on the internet is junk mail. In my experience, it's much less, but I've never worked for AOL, Mindspring/Earthlink, or any of the dozens of cable ISPs. (But based only on number of emails vs. number blocked, 25% is a bit low.)
I don't know for certain, but my instinct is to believe that email addresses are not going to be portable anytime soon in the way that (thanks to regulation and deregulation) cell phone numbers are, and landline phones may someday be.
First, "landlines" have had local number portability ("LNP") for about 5+ years now. Cell phone LNP was mandated last year (earlier this year?) and is still being rolled out. At this very moment, a landline can be re-ported anywhere within the PSTN (or the telcos involved can be fined.) This is not yet true for all cell sites -- it takes time to update switch software. (At a former employer, it took about a year to upgrade a dozen Lucent 5ESS switches. It's not a simple process by any means.)
As for email address "portability"... (I hate to sound like a lawyer here, because I'm not) that depends on how you read "in the [same] way". If you mean Telcordia maintains a database of email addresses and where they should go, then no, that'll never happen. There are just too many players in the market and none of them will pay the fees like telcordia changes for the LNP database. HOWEVER, e-mail has had the ability to "alias" and thus redirect an address almost from the very first day. The thing is, ISPs don't want to have to maintain a system (read: anything at all) for people who are no longer a paying customer; and those who inherit all these aliases certainly won't.
[Note: LNP is more like an IP routing database than a list of email aliases. The former holder of the number doesn't incure any load in handing the number to someone else... the calls aren't routed through their switch(es) as is the case with an email alias: foo@bar.com->foo@baz.com has to go to the bar.com server to be directed to baz.com.]
If you have a DTivo, those channels will be reactivated everyday. If I didn't know better, I'd say it was intentional -- and may be, but not on the part of the tivo (if DTV turns off the channel, the tivo will enable it when DTV turns it back on.)
DISH and DTV offer "a la cart" service. They just don't advertise it, and make it rather hard to obtain. Oh, and it's f'ing expensive... 4$/channel last time I checked into it. I don't think they can sell you just the local channels (FCC rules.)
Re:Expensive Electronics Cheap Scams, not taken do
on
eBay Fraud Vigilantes
·
· Score: 1
My favorite are the nuts who sell Cisco IOS images. I'm stupified by the people who will pay them money (for something Cisco will give you for free in many cases -- esp. if you're asking for the image it was sold with.) And I'm further amazed that Cisco let's these people do it.
eBay needs to change their feedback reviewing pages to allow limiting to specific types. If a seller has 1500 positive and 38 negative entries, I don't immediately care about the 1500; I want to see the 38 negatives... when were they posted, who posted them, were they all clustered, were they resolved, and exactly what was the problem... these are all better indicators than 1000 "A++++++++++++++", "WILL BUY FROM AGAIN" bulls***.
A friend of mine sent me the engine specs for the 2002 1.8T 150HP and 180HP. The only difference is the compression ratio (9.3:1 vs. 9.5:1 respectively.) They have the same bore, stroke, and displacement. And, as I understand it, they all use the same turbo charger.
I can have the ECU reprogrammed (by various means) to increase my 2001 150hp bug to have 193hp and it's a 100% software change. (I can get a few more horses if I change a few of the engine components.)
(I drive that bug exceedingly fast already. More power would just make me that much worse. *grin*)
delayed ACK and window size are completely independant. The system will only send so many packets before it pauses for an ACK. un-ACK'd packets must be held in memory in the event of a dropped or damaged packet, so there has to be some limit:-) What makes TCP "slow" is it's assumption that the link is unreliable. Thus, only a few packets are "blind transmitted" initially. The delay window can grow once the link reliability increases. 'tho I've not dug through the Linux network stack in some time, so I don't know how far ahead it will transmit.
Thus, an entity is a telecommunications carrier under the Communications Act only if it provides point-to-point transmission of information, "without change in the form or content of the information," on a common carrier basis.(p.11)
This has been true for some time -- even before CALEA. Thus, your ISP is a "telecommunications carrier" as per the Communications Act ("common carrier" aside.) And your e-mail, p2p downloads, VoIP, remote desktop, etc. are all "telecommunications" and thus legally subject to a wire tap. Before you run off complaining that ISP's aren't "telecommunications carriers"...
CALEA's definitions are even broader:
thereby making clear that CALEA is not confined to voice telephony, but rather extends to "any transfer of signs, signals, writing, images, sounds, data, or intelligence of any nature transmitted in whole or in part by a wire, radio, electromagnetic, photoelectronic or photooptical system."[31](p.12)
Further:
Whether broadband access providers are engaged in the transmission of communications on a common carrier basis, and hence whether they qualify as "telecommunications carriers" under the Communications Act, is a matter of ongoing dispute.[46] But as noted above, a provider that is engaged in the transmission or switching of wire or electronic communications need not be doing so on a common carrier basis in order to qualify as a "telecommunications carrier" under CALEA. Instead, as long as the service is a replacement for a substantial portion of the local telephone exchange service, Section 102(8)(B)(ii) of CALEA empowers the Commission to bring the service and its providers within the scope of CALEA where the public interest so warrants.[47](pp.23-24)
As for "backdoors", this is non-sense; CALEA is very specific as to what information is reported and exactly how it is reports (the "J-STD".) The things that would require modification to be CALEA compliant are the hardware and software systems providing the communications service(s)... i.e. the phone switch (software/hardware upgrades), the switch vendor (CALEA reporting capabilities in the switching software), and the service provider (the telco knowing how to setup a CALEA compliant tap.) If the XBox can place direct, non-mediated, point-to-point "phone calls", then yes, it would be subject to CALEA, however this case is absurd as one of the ends would have to know of the tap in order to report on it; and any "backdoor" tap would be pretty obvious. In the mediated case where the XBox (Live) is connected through some server ("a service provider"), there is a clearly deliniated point for a non-obtrusive tap ("the service provider") and thus a need for that SP to be CALEA compliant.
In the end, the chicken little's are reading far too much into this. CALEA pertains to telephony and has nothing to do with the FBI installing a packet sniffer on your cable modem or compeling your ISP to do so. Personally, I'm far more horrified by the "cost recovery" provisions. Never, ever, EVER, let telco's charge the customers for their upgrades; they unfailingly screw the customers for decades. In. Every. Single. Case. (At least the FCC mandated a 5year limit for Local Number Portability cost recovery. And yes, I'm watching my phone bill.)
Actually, all one needs is the web server's SSL cert. Then you can decode every ssl session that uses that cert. However, not all SSL connections will use it (like SSL2, 40bit keys,... they aren't secure in that the key can be recovered in a few hours or days, but much more secure than a compromised ssl cert:-))
They aren't putting "backdoors" in every program. CALEA is about simplifying and standardizing the access methods and data for wire taps. In the sense of IP communications, that's pretty much already within the CALEA spec: packet mode communications. The only difference is the type of data (IP vs. packet voice, IPv4/6 vs. NSAP, etc.) And, by the way, they can ALREADY tap your IP communications -- anyone with access along the path ("man in the middle") can.
I've not read all the BS within the PATRIOT act, but I have read a great deal within CALEA. The parent poster is correct; under CALEA a court order is required. Paperwork must be filed in accordance with the provisions of CALEA before any tap is active. And under these provisions, the telco (ISP) can take up to *60* days to complete the order -- this allows for circuit ordering, provisioning, installation, testing, etc. Seeing as ISPs generally are not telcos, they have no power over physical circuit provisioning. And CALEA requires a direct, point-to-point, connection to the LEA collection facility for CDC (call detail) data. CCC (call content) can be "on demand" (i.e. dialup.)
[I can speak with some authority in this area as one of my duties at my former employer was as the CALEA implementation administrator. I worked with switch admins, techs, and provisioners and the fraud department to "make it all work" -- clearly outlined proceedures, IP address maps for the telco switching network (yes, IP is running inside that 20 year old switch), test proceedures, etc. I basically became a switch tech for a few months:-) (and people say UNIX is cryptic.)]
Slashdot Mirror
Unless I completely missed it, this nut case never did say what sound card he was trying to use or what "XYZ" distrubtion is or what he was doing to confirm operations.
Yes, sound is a difficult thing to setup in linux. The fact that he had it running once is proof that it does indeed work. What ever he did in getting it to work the first time obviously wasn't persistant. I've never had a problem setting up sound under Linux, but I know what I'm doing.
What we have here is a n00b. Please move along.
Not anymore... they've abandoned just about everything but i386. And now they've abandoned their "free" distribution. Yes, there is still a freely downloadable version, but it's all a cruel joke to get everyone to debug (and develop) their commercial product for free.
I've switched to debian... if for no other reason than they don't abandon their various architectures.
This is not new by any stretch. Redhat has been dicking with the kernel and almost every package they ship for nearly a decade (possibly longer.) That's why it has always been a matter of policy on my part to build my own kernel from the "blessed" tree the instant a redhat machine is installed. Never, EVER, use the hacked-to-hell Redhat kernel. Kernel developers will generally ignore your bug reports, and redhat will ignore them too without a support contract.
If you have your own domain, then you are essentially acting as a "telco" in this sense. Additionally, everyone cannot have their own domain -- in fact, most will not even understand what a "domain name" is (made worse by registrars calling them "web addresses".)
... oh, like the OpenSSL ident strings. 12.0 used OpenSSH, but they have since stopped using OpenSSH code in IOS -- they either rolled their own or snarfed someone else's. They've removed almost all of the ident strings except for those put there by the compiler: GCC: (GNU) 2.95.3 20010315 (cisco p10 release), etc.
Unless you downloaded and compiled the binaries from the postgresql.org server(s), then you cannot say, for sure, Cisco has not added backdoors to the code.
- Besides that, it is possible to recieve only the header, and then refuse to accept the rest of the message. TCP can take care of doing that.
I'll assume you mean the IP ADDRESS (stop using the word "headers"... we aren't talking firewalls here; mail servers don't process raw ip packets, so they cannot see the "TCP/IP headers".) Yes, the SMTP server can refuse to speak with anyone it chooses. It doesn't have to respond with "2xx Howdy"; it can respond with "5xx Take off you spammin' hoser." and close the connection. (Note: it does have to respond or the sender will simply try again or hand the message to someone else to get it to the server.)As you've indicated yourself ([here]), such means of blocking spam are insufficient. No matter how many hosts you block, you'll eventually have to accept email from someone that's going to present spam -- namely one or more of the worlds major ISPs... you cannot block all email from, say, AOL when there are people on AOL with whom you need to be able to send/receive email. The "obvious" answer to this is to create a "whitelist". Well, those don't work very well either as the "mail from" is easily forged and looking for a key or password within the message *ding* requires receipt of the entire message which defeats the purpose. (Earthlink does this... if someone is not in my addressbook, then the message is dropped in a "suspect" folder.)
SPF (Sender Permitted From) can go a long way to limiting the ammount of forged spams. But it's going to take years to see this put in place.
- If the recieving SMTP server recieves the header (finds a blacklisted IP address...
The "headers" aren't part of the SMTP protocol, they are part of the message... 'helo', 'mail from', and 'rcpt to' are the only parts of the protocol invoked before the message begins -- and they are all useless as they can be forged (well, except rcpt to, that one's gotta be right or the message goes nowhere.)As we are talking about reducing wasted bandwidth, parsing headers isn't going to do it. The only way to parse the headers is the receive the entire message at which point, the bandwidth has been burned.
However, you are correct in that the sender's IP is known "for free". The other end of the tcp connection is known before either side has sent anything. This is the basis for blacklists.
Please pick one side or the other... if you're scanning headers, then you have the entire message and nothing is saved. If you're blacklisting the sender based on ip address, then no protocol interaction is required and bandwidth can be saved. In your original post, you're talking about headers, but now you're pitching sender ip address.
Woa! MTV plays music? I've never see any on any of their channels in the last decade (+/-). Seriously, I've seen more (and better) music videos on WE than MTV.
- Next time you decide to belittle me, try actually reading what I posted first...
Do you even know what you wrote?I guess not. You seem to have completely missed the point... the headers are part of the message; no bandwidth savings exist if the message has to be received to scan the headers; and yes, the entire message must be received to return a status code and thus prevent redelivery.As Martin Blank posted:You just cannot get it into your fat head... the only way to reduce bandwidth wasted to spam is to never receive the message in the first place which can only be done at the SMTP protocol ("the server") level. At that level, the only viable information for making any decision is the sending machine's IP address (i.e. blacklists.) You cannot reject a message based on the "headers" without having those headers in hand which means you have the whole freakin' message, and thus have not saved any bandwidth at all. (That's technically client side filtering, btw.) Most people don't have any control over their mail server; what might work for one, single, person, will not scale to work for hundreds or thousands of people...
As evilviper points out, most (ISP) spam blocking systems have proven insufficient. I would label them as highly ineffective -- many spams necessarily make it through because one cannot block entire ISPs without interfering with a high percentage of valid email, and client side filtering is complex, cumbersome, and does nothing to stem the tide of useless junk flooding the internet. Add to the problem, ISPs are lothe to constrain port 25 traffic within their network(s) to their own farm of mail servers due to the costs and increased liabilities including legal liabilities.
Nope. You're understanding is incorrect. The SMTP server has to receive the entire message in order to scan the headers and indicate to the sender the message was accepted or rejected. Simply dropping the connection as soon as spam is detected from the headers will not work... the sender will see that as incomplete and will reattempt delivery at a later time. The sender's IP address is the only thing that can be trusted (read: not forged by the spammer) prior to receiving the entire message. There's no bandwidth savings if the message gets transmitted.
[Note: The "headers" are not part of the SMTP protocol. They are part of the message.]
Here is what actually happens:
- 220 mail.bar.com ESMTP Sendmail 8.11.7/8.11.7; Mon, 5 Apr 2004 20:07:33 -0400 (EDT)
You cannot base a rejection on the sender ("mail from") as spammers lie. They lie 100% of the time these days. The only thing you can trust is the IP of remote end of the connection. If you're accepting mail from dialup/dsl/cable modem IP ranges, then that's where you should be blocking... In the above quoted sequence, there are *6* points where the message can be properly refused... every response from the server from the initial connection banner to the "250HELO baz.com
250 mail.bar.com Hello localhost [127.0.0.1], pleased to meet you
MAIL FROM: <foo@baz.com>
250 2.1.0 <foo@baz.com>... Sender ok
RCPT TO: <foo@bar.com>
250 2.1.5 <foo@bar.com>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
message headers
[blank line]
message body
.
250 2.0.0 i3607vD03645 Message accepted for delivery
QUIT
221 2.0.0 mail.bar.com closing connection
The from:to pair may otherwise be valid. And in light of forged info, cannot safely be used to block messages. It's simply not enough information at hand without the text of the message. In order for your method of blocking to be effective, you'd have to block further email for at least a week. See, mail servers don't immediately attempt to re-deliver the message. (I don't know of any that would retry in less than 15min without explicit administrative changes.) And they will continue to retry until they have a valid status returned from the process -- "helo", "mail from", "rcpt to" can all be denied:
- 550 5.7.1 foo@bar.com... Relaying denied. Proper authentication required.
"data" can be immediately denied or it can be refused once it has received the entire message -- OR a set number of retries have been attempted (usually measured in time -- "will continue to retry for 4 days" -- instead of a hard "I tried 8 times")All your scheme will accomplish is blacklisting an (ISP's) mail server(s) and/or blocking all communications between pairs of email addresses. How would you like it if your server(s) were blocked due to spammers forged headers? How would you like having your incoming emails dropped because the mail server saw a single message it didn't like even though it's from someone withwhom you regularly communicate? I didn't think so.
Better minds than ours (and certainly better than yours) have been pondering the problem of SPAM for years. If the solution were simple, we'd've done it by now. The current best solution is to eat the spam and process it as it goes into the inbox ("a client side filter"), but that does nothing to address all the (increasing) bandwidth wasted by spam -- which, btw, is the whole point of this little flamefest. There isn't a way to authoritatively decide "spam, not spam" without the contents of the entire message -- the various blacklists help, but they tend to create too many false positives. It may take only a small fragment of the text to reach a deciding point, but SMTP requires receipt of the entire message. Good luck getting that protocol changed and then implemented across the globe.
I'll give you half credit. *grin* You had 'em backwards. And it's not something the phone companies what you know about. I think BellSouth is still claiming your number is only portable within the same CO (i.e. I can change my carrier and keep the number, but not if I move out of range of my current CO) -- this is, of course, BS. However, I've not asked lately.
(I guess your phone company isn't scam^Wcharging you for LNP. I've been charged $0.35 per month since 6/99 by BellSouth -- they are allowed to charge me for exactly five years [as per NC PUC ruling].)
It'll reconnect, dumbass.
READ THE POST. Once the DATA phase has begun, the server is required to accept the entire message. The sender will not process a return code until after it completes delivery. If the connection is broken before then, IT WILL RETRY DELIVERY. The sender will not know the connection was intentionally broken.
(Of course, one could "tar pit" that connection and let sendmail (or whatever) shutdown it's end. But, that's a bit much.)
- Soon enough, the costs of bandwidth and pay checks...
First, it takes very little bandwidth to be a huge f'ing spammer -- and bandwidth is extremely cheap these days. Second, there usually aren't any "pay checks" as there's just one idiot. Even the big "institutional" size spam outfits rarely consist of more than a dozen people.There are a lot of stupid people in the world. Spammers will always be able to find them.
- Blocking e-mails, based upon the lack of a key in the subject line...
Too late. Once the (smtp) DATA phase is underway, as would be required to get the "Subject:" header, the server is commited to receiving the entire message. The POP protocol has no support for sending anything but the entire message. IMAP does, but there are very few ISPs that offer IMAP access to your email. (what is it with [censored] webmail these days!) You've saved nothing in bandwidth. If you terminate the smtp connection mid-stream, the sender will eventually try again. And there's no way to tell that same message is coming in. Blocking the entire server is generally a Bad Idea (tm) -- you may end up blocking the mailserver(s) for an entire ISP. (SORBS already has this problem with their "spamtrap senders" blocklist.)You seem to be stuck thinking the only bandwidth of value is that into your mail client. That's nothing. The true problem with spam is the volume of internet traffic at large being wasted by junk. Some have estimated as much as 25% of ALL the traffic on the internet is junk mail. In my experience, it's much less, but I've never worked for AOL, Mindspring/Earthlink, or any of the dozens of cable ISPs. (But based only on number of emails vs. number blocked, 25% is a bit low.)
- I don't know for certain, but my instinct is to believe that email addresses are not going to be portable anytime soon in the way that (thanks to regulation and deregulation) cell phone numbers are, and landline phones may someday be.
First, "landlines" have had local number portability ("LNP") for about 5+ years now. Cell phone LNP was mandated last year (earlier this year?) and is still being rolled out. At this very moment, a landline can be re-ported anywhere within the PSTN (or the telcos involved can be fined.) This is not yet true for all cell sites -- it takes time to update switch software. (At a former employer, it took about a year to upgrade a dozen Lucent 5ESS switches. It's not a simple process by any means.)As for email address "portability"... (I hate to sound like a lawyer here, because I'm not) that depends on how you read "in the [same] way". If you mean Telcordia maintains a database of email addresses and where they should go, then no, that'll never happen. There are just too many players in the market and none of them will pay the fees like telcordia changes for the LNP database. HOWEVER, e-mail has had the ability to "alias" and thus redirect an address almost from the very first day. The thing is, ISPs don't want to have to maintain a system (read: anything at all) for people who are no longer a paying customer; and those who inherit all these aliases certainly won't.
[Note: LNP is more like an IP routing database than a list of email aliases. The former holder of the number doesn't incure any load in handing the number to someone else... the calls aren't routed through their switch(es) as is the case with an email alias: foo@bar.com->foo@baz.com has to go to the bar.com server to be directed to baz.com.]
If you have a DTivo, those channels will be reactivated everyday. If I didn't know better, I'd say it was intentional -- and may be, but not on the part of the tivo (if DTV turns off the channel, the tivo will enable it when DTV turns it back on.)
DISH and DTV offer "a la cart" service. They just don't advertise it, and make it rather hard to obtain. Oh, and it's f'ing expensive... 4$/channel last time I checked into it. I don't think they can sell you just the local channels (FCC rules.)
My favorite are the nuts who sell Cisco IOS images. I'm stupified by the people who will pay them money (for something Cisco will give you for free in many cases -- esp. if you're asking for the image it was sold with.) And I'm further amazed that Cisco let's these people do it.
eBay needs to change their feedback reviewing pages to allow limiting to specific types. If a seller has 1500 positive and 38 negative entries, I don't immediately care about the 1500; I want to see the 38 negatives... when were they posted, who posted them, were they all clustered, were they resolved, and exactly what was the problem... these are all better indicators than 1000 "A++++++++++++++", "WILL BUY FROM AGAIN" bulls***.
A friend of mine sent me the engine specs for the 2002 1.8T 150HP and 180HP. The only difference is the compression ratio (9.3:1 vs. 9.5:1 respectively.) They have the same bore, stroke, and displacement. And, as I understand it, they all use the same turbo charger.
I can have the ECU reprogrammed (by various means) to increase my 2001 150hp bug to have 193hp and it's a 100% software change. (I can get a few more horses if I change a few of the engine components.)
(I drive that bug exceedingly fast already. More power would just make me that much worse. *grin*)
delayed ACK and window size are completely independant. The system will only send so many packets before it pauses for an ACK. un-ACK'd packets must be held in memory in the event of a dropped or damaged packet, so there has to be some limit :-) What makes TCP "slow" is it's assumption that the link is unreliable. Thus, only a few packets are "blind transmitted" initially. The delay window can grow once the link reliability increases. 'tho I've not dug through the Linux network stack in some time, so I don't know how far ahead it will transmit.
- Thus, an entity is a telecommunications carrier under the Communications Act only if it provides point-to-point transmission of information, "without change in the form or content of the information," on a common carrier basis.(p.11)
This has been true for some time -- even before CALEA. Thus, your ISP is a "telecommunications carrier" as per the Communications Act ("common carrier" aside.) And your e-mail, p2p downloads, VoIP, remote desktop, etc. are all "telecommunications" and thus legally subject to a wire tap. Before you run off complaining that ISP's aren't "telecommunications carriers"...CALEA's definitions are even broader:
- thereby making clear that CALEA is not confined to voice telephony, but rather extends to "any transfer of signs, signals, writing, images, sounds, data, or intelligence of any nature transmitted in whole or in part by a wire, radio, electromagnetic, photoelectronic or photooptical system."[31](p.12)
Further:- Whether broadband access providers are engaged in the transmission of communications on a common carrier basis, and hence whether they qualify as "telecommunications carriers" under the Communications Act, is a matter of ongoing dispute.[46] But as noted above, a provider that is engaged in the transmission or switching of wire or electronic communications need not be doing so on a common carrier basis in order to qualify as a "telecommunications carrier" under CALEA. Instead, as long as the service is a replacement for a substantial portion of the local telephone exchange service, Section 102(8)(B)(ii) of CALEA empowers the Commission to bring the service and its providers within the scope of CALEA where the public interest so warrants.[47](pp.23-24)
As for "backdoors", this is non-sense; CALEA is very specific as to what information is reported and exactly how it is reports (the "J-STD".) The things that would require modification to be CALEA compliant are the hardware and software systems providing the communications service(s)... i.e. the phone switch (software/hardware upgrades), the switch vendor (CALEA reporting capabilities in the switching software), and the service provider (the telco knowing how to setup a CALEA compliant tap.) If the XBox can place direct, non-mediated, point-to-point "phone calls", then yes, it would be subject to CALEA, however this case is absurd as one of the ends would have to know of the tap in order to report on it; and any "backdoor" tap would be pretty obvious. In the mediated case where the XBox (Live) is connected through some server ("a service provider"), there is a clearly deliniated point for a non-obtrusive tap ("the service provider") and thus a need for that SP to be CALEA compliant.In the end, the chicken little's are reading far too much into this. CALEA pertains to telephony and has nothing to do with the FBI installing a packet sniffer on your cable modem or compeling your ISP to do so. Personally, I'm far more horrified by the "cost recovery" provisions. Never, ever, EVER, let telco's charge the customers for their upgrades; they unfailingly screw the customers for decades. In. Every. Single. Case. (At least the FCC mandated a 5year limit for Local Number Portability cost recovery. And yes, I'm watching my phone bill.)
Actually, all one needs is the web server's SSL cert. Then you can decode every ssl session that uses that cert. However, not all SSL connections will use it (like SSL2, 40bit keys, ... they aren't secure in that the key can be recovered in a few hours or days, but much more secure than a compromised ssl cert :-))
They aren't putting "backdoors" in every program. CALEA is about simplifying and standardizing the access methods and data for wire taps. In the sense of IP communications, that's pretty much already within the CALEA spec: packet mode communications. The only difference is the type of data (IP vs. packet voice, IPv4/6 vs. NSAP, etc.) And, by the way, they can ALREADY tap your IP communications -- anyone with access along the path ("man in the middle") can.
:-) (and people say UNIX is cryptic.)]
I've not read all the BS within the PATRIOT act, but I have read a great deal within CALEA. The parent poster is correct; under CALEA a court order is required. Paperwork must be filed in accordance with the provisions of CALEA before any tap is active. And under these provisions, the telco (ISP) can take up to *60* days to complete the order -- this allows for circuit ordering, provisioning, installation, testing, etc. Seeing as ISPs generally are not telcos, they have no power over physical circuit provisioning. And CALEA requires a direct, point-to-point, connection to the LEA collection facility for CDC (call detail) data. CCC (call content) can be "on demand" (i.e. dialup.)
[I can speak with some authority in this area as one of my duties at my former employer was as the CALEA implementation administrator. I worked with switch admins, techs, and provisioners and the fraud department to "make it all work" -- clearly outlined proceedures, IP address maps for the telco switching network (yes, IP is running inside that 20 year old switch), test proceedures, etc. I basically became a switch tech for a few months