Yes, but blacklisting works when you know who the sender actually is. The current problem with blacklisting is that the spammers make up email addresses.
No anti-spam solution works in isolation. There are several levels needed. SPF provides authentication for the sending server *i.e. the domain). SMTP Auth provides authentication for the username (person). Blacklisting blocks emails from bad (but authenticated senders). Content recognition helps when you have a sender from whom you would like to get email but who is now compromised.
I don't need to know the people to get them to fix their machine. I just need to know how to reach them (I have the email address) and their ISP (abuse@theirdomain -- I have their domain from their email address). If that is not sufficient, then I can blacklist. Because I have their actual identity, I can blacklist effectively (i.e. once they are on my blacklist, they have to compromise a new machine).
Look at virus outbreaks for a good example of why this is better. When someone who has my email gets a virus, I get loads of emails from various other people in my address book. With this, I only get emails from one person. I can then blacklist them or run their email through Bayesian filtering. Now I don't have to worry about false positives from other email addresses, just this one.
To me, false positives (ham identified as spam) are the worst part about spam. SPF, etc. help reduce the possibility of false positives by helping you divide your emails into four groups: someone you know and trust (bypasses content filter); someone you know but do not trust (content filter); someone who you know to be bad (refuse all email); someone you do not know (bypass content filter with first email -- use that to allocate them to one of the other groups). Now you only have to worry about false positives in the second group (and possibly the fourth if that becomes a problem area).
If you really want, you can set SPF ( spf.pobox.com ) to authorize your ISP mail server to relay mail from your own domain (this is useful if your domain does not have its own mail server). However, a better solution is generally to SMTP AUTH to the mail server for your domain (rather than the mail server for your bandwidth, i.e. your ISP). SPF will support both though; it is your responsibility to make sure that this secures you from relaying.
Not sure if the Microsoft/sendmail suggestions work the same way.
I don't disagree that in the way that it is used *now*, that it is not overkill. What I'm saying is that a public key system would not be a good general system. I.e. when I get an email from a stranger (which is when it matters; other than virus outbreaks, very little spam comes from friends), I would have to find someone I trusted to verify the stranger. This is where you get long chains (I won't speculate as to length again).
Public keys work great when you want to verify someone you know (although I think that they would work less well if *everyone* used them; the technical difficulty keeps out many of the people who would get virus infected, etc.). The problem is that spam is usually from someone you do *not* know. Now, you could reject all email from those that you do not know, but the effect of that would be to eliminate some email you might want to receive (I do a lot of PHP contract work; a stranger contacting me is a *good* thing).
The more you automate the system, the more vulnerable it is to assault. If everyone used public keys, then all spam would be created by viruses and crackers. Yes, you could revoke the key, etc., but all that takes time. Especially if you cache results (my ISP can take up to a week to update DNS). Further, I have had people take two or three *days* to fix their virus infected computer (which is essentially a stolen key situation), even after I told them what the problem was. End result, a lot of people would have their keys revoked because someone down chain was misusing it (and someone up chain is not willing to wait until they correct it). Until they figure it out, this means that their *valid* email is getting rejected.
A two level verification system (with SPF as one level) is better as a general system. SPF verifies that the machine (IP) is authorized to send mail for that domain. The machine (which can be an SMTP server or just a workstation -- limiting to SMTP servers is more secure; the domain owner can set this) is then responsible for verifying the identity of the person sending the email (in whatever fashion). Now, they either need to crack an SMTP server or a DNS server to send mass emails.
In a public key system, cracking an individual computer can give you access to a key which would allow the spammer to send emails from a separate machine or machines until the key was cancelled (and the cache clears). After the key is cancelled, you lose valid email until a new verification path is created.
The SPF method involves no changes in MUAs (except possibly the introduction of something like SMTP auth, but common MUAs already support this); no extra key signing software; puts the burden on domain *owners* to secure their domain; is easy for ISP tech support to help people set up. Compare to public key situation: tech support says, "you need to send your key to us to get signed." A couple days later they get a letter in the mail with the person's house key. Silly? Yes. Something that would actually happen? You betcha. The majority of users require an abstractable method where someone else does the heavy lifting.
A public key interface is great when everyone involved is motivated to maintain it. However, this is not generally extensible IMO. If everyone used it, we would be continually managing stupid key problems (e.g. Jane revokes John's key because John didn't call her the next day, which shows up the same as if she revoked his key because he sent spam) caused by relying on non-technical users. This is not to say that public keys are a bad idea (they aren't); merely to say that they are not a universally scalable idea. At least not IMO.
We don't need to trust the *person* sending the mail. It would be sufficient to trust the machine that is doing so.
Look at http://spf.pobox.com/ which is sufficient. With SPF, you know that if you are getting SPAM saying it is from @ultraviolet.org, then it really is from @ultraviolet.org (or at least someone who ultraviolet.org trusts).
Your solution requires a certain level of technical proficiency (setting up and managing the key) of *all* participants. SPF's solution only requires technical proficiency from those who manage DNS settings and those who manage email servers (in particular the person who manages your email server).
Also, what about *stolen* keys? And who handles key checking? SSL certificates are restricted to a few root signers, but you don't want a central certificate authority. PGP/GPG work well because they only involve small numbers of people. In general, you know the person directly. Occasionally it will be a friend of a friend message. What do you do when the chain is 10 or a 100 or a 1000 keys long? How long will it take for you to find out that 978 has since revoked their signature for 977 (counting in steps from you, i.e. you are 0 and 1000 is the original signer of this chain)? Or how long will it take you to verify all 1000 keys if you try to do it real time (i.e. when you get the message)?
username+filtername@domain.com should go to username@domain.com as per the RFC (the +filtername is carried but not used by servers, or at least it shouldn't be). Some email clients will allow you to use this for such things as folder sorting (i.e. username+foldername goes into foldername automatically). If this worked consistently, it would be good for people who don't have the ability to make more usernames.
AFAIK, username-filtername will still just go to username-filtername, i.e. you have to configure your mail server to handle username-filtername separately from username. This works great when you can specify as many usernames as you want (i.e. if you manage your own server or have a catch-all on your domain).
Maybe you are talking about something different than the original poster?
One reason why the - would work when the + does not is that the - can appear multiple times, so it just another valid character (like a letter, number, or underscore). The + can only appear once, so many servers can ignore it, drop it, or puke on it.
Interestingly enough, while the (optional) challenge/response system is what gets the press, the main purpose of TMDA is to create aliases like username-filter (and then filter based on them). Thus the name: *Tagged* Message Delivery Agent. The -filter is the tag of Tagged.
No, I put two and two and two together and realized that it could be made *into* a SCO joke. Without saying SCO (or making any reference to an outside entity that might be SCO), it is not at all obvious that it refers to SCO.
The way the original post reads, *you* believe that Linux steals IP and think it is the same thing as Festival (regardless of what you actually believe, this is how it reads). That's not funny to people who don't agree with the position that Linux steals IP (the majority of the/. readership).
I'm not claiming that you were trolling by posting flamebait. What I am saying is that that post speaks in a way that is flamebait (by assuming that Linux steals IP). There is *nothing* in the post to indicate that we should have been looking for someone other than you who would hold that position. As posted, it looks like something that would be posted by Darl McBride (or whatever his name is).
It's like the following exchange:
Knock, Knock. Who's there? Orange. Orange who? Orange you glad it's not banana?
It makes no sense unless you already know the joke. Why? It's missing the whole prep of the repeated Banana sequence and skips straight to the punch line. Punch lines are not funny without the prep.
If the message had said, "When the Festival arrives, SCO will sue it saying, 'It's just like Linux; it gives us technological gifts in exchange for stealing IP,'" then it would have been satire, humor, social commentary, and geek humor.
Innocent? Like Open Relays are innocent? Domains that are unwilling to do a minimal amount of authentication support are not innocent IMO. Simply reckless and dangerous.
I'll take your bet with the following modifications: SPF or another reverse DNS method that does the same thing (authenticate IP addresses as valid senders for a domain); take hold defined as more than 50% of the domains with MX records have SPF records.
I hear that AOL is adopting SPF. If Hotmail and Yahoo follow, the pressure will build. Particularly with ISPs like EarthLink adopting TMDA-like challenge response systems (plus the Microsoft version that is currently being contemplated). SPF helps one of the biggest problems with the SMTP protocol: the lack of sender authentication. The biggest obstacle to its adoption is the pressure from Microsoft, et. al. to develop a more expensive solution (remember the proposal to create SSL-like ID certificates?).
If you are on the whitelist, you can spam (no challenge). If *everyone* used TMDA, that would be the only kind of spam (whitelisted spam), and there is no point in sending spam if it is not going to be received. Whitelisted spam will not be challenged; it's already whitelisted. Also, whitelist spam will be relatively rare, as it would put the burden on the spammer to get an address you whitelisted.
If *everyone* used TMDA, then there would not be a user level problem with challenges for messages that you did not send, as TMDA can drop challenges from people to whom you have not sent mail.
Even at the ISP level, remember that we now have 60% of the email bandwidth with which to play (the reduction from current spam). That should more than cover sending a challenge for every email message much less the trivial number of legitimate messages that actually get challenged (6%) by a TMDA system.
TMDA works really well with a system like SPF. With SPF compliant domains, you can identify the sender (or at least the sending domain) accurately. If you can do that, no fake challenges to SPF compliant domains with solid authentication of SMTP users (of whatever form: SMTP Auth, etc.). Now, the fake challenges (i.e. those to people to whom you did not send mail) encourage faster adoption of SPF (and thus more authenticated senders).
The error that you are getting is telling you that you are trying to relay through a mail server, i.e. that the To email address is not associated with that mail server and that you haven't met its standards to send from the From email (in your case, it sounds like it requires you to have appropriate DNS records for the sending IP; it could also use SMTP authentication as well--same concept). All correctly configured mail servers will do this in some manner. In fact, one of the spam blocking techniques is to set the server to reject email from any server that is on one of the lists as an "open relay" (meaning that it is not properly configured to reject unproven senders to outside domains). You won't get that error if you try to send from an outside domain to one that Verizon manages.
A more common method is to check for a PTR record for the IP that is sending you the email. If it doesn't have a PTR record, then your mail server rejects the mail. Checking for an MX record is overly restrictive and will blacklist many large organizations.
There is also a method called SPF that actually does allow organizations to "whitelist" their mail servers as appropriate senders for their domain. I just found out about it today, but I have my host looking into adding the appropriate DNS entry for me. The great part about it is that it is a whitelist method at the domain level, i.e. it makes individual domains responsible for authenticating their mail sending servers. Combined with a blacklist of open relays, this allows you to at least apportion blame. If spam is sent, then that domain can fix it, because it is caused by a failure in their authentication system.
If everyone used TMDA, then there wouldn't be non-whitelisted spam. That 60% reduction in email would more than cover the bandwidth for the once per sender authentication that TMDA requires (actually less than that, since it auto-whitelists people to whom you send email and allows you to just whitelist people). Especially considering that a TMDA challenge is relatively small if you don't return the original message.
Combine TMDA with something like SPF sender validation ( spf.pobox.com ) and you won't even have the bounce problem unless someone's actual account was used to send the email.
You give the mailing list a special email that always goes through, or you just whitelist (i.e. add them to your "buddy" list before they send you email) the mailing list. Whitelisting is better but doesn't work if your list sends from people you've never seen previously. If the list always sends from itself (i.e. listname@listserv.com), then a whitelist is the way to go.
TMDA also supports throwaway email addresses that you can use to register at a site that sends an email confirmation. The email address will stop working after a while and the site can't spam you. Think real.com for an example of why this is necessary. You can also get throwaway email addresses from spamgourmet.com without TMDA.
As someone who used to sysadmin a mail server, I can tell you that this (saving info about who emailed who) is already required. I forget what the limit was, but we were supposed to keep the mail logs (which carry from who to who info) for at least six months. We actually archived them to our write only backup system on a regular basis. AFAIK, they stayed there forever (of course, it's anyone's guess whether or not we would have been able to retrieve them; our backup system had issues--thus the write only tag).
This proposal does not involve collecting or saving new info. It involves *using* the existing info at a summary data level. Also, understand that it would be the *recipient's* ISP who would do this, not your ISP. This means that they could only collect info on what you send to email addresses on that server, not cross reference it with all the email that you send.
It's also worth noting that other ISP-level SPAM filters already process this info as well. This isn't a new concept. The new part is that it is trying to use the patterns *before* putting it in the receiver's mail box rather than after it is identified as SPAM by the receiver.
No, don't pay your ISP; pay the *receiver's* ISP. Paying your ISP is just silly (unless they then transfer it to the receiver).
Then your ISP can credit you for the amount of email you receive. If you receive more than the cost of providing you services (not just email but bandwidth), then you get free internet that month (a hundred pieces of SPAM a day would pay for $30 of internet a month; easily cover dial-up and cover at least half of most broadband options).
Note that this changes everything. Now, spammers will only want to send to people who will buy what they are peddling. Plus, they will have to be vigilant about ensuring this as people will want to receive filterable email (pays you money but you still don't have to read it).
Mailing lists would work through an opt-in system with the receivers' ISPs. You pay $.01 per email sent by the list who pays $.01 to send it. Net result: no money transfers. You can whitelist individuals the same way.
Then how do you explain Nimda and SQL Slammer? Both of those affect Microsoft products (and their vulnerabilities) that are in the *minority* of those available. Apache trounces IIS in usage numbers (both because more web sites using it and because higher traffic web sites use it), and any of MySQL, Oracle, or IBM (I forget the actual name) outnumbers Microsoft SQL Server.
IMnsHO, exploit authors prefer Microsoft Windows products because they are buggy (note that the posted exploit actually affects a discontinued product, it lasted that long), because they are based on a buggy security model (oh, you are code? I'll run you automatically and save asking the user if he/she wants to run something from "MLM will make you millions!"), and because they are commonly used by people who don't know what they are doing. Any twit can install IIS--it's just a matter of following prompts. With Apache, you need a certain level of knowledge; particularly if you are not happy with the default settings and want to change them (especially the compiled in settings, which can obviously only be changed by recompiling the software; Microsoft writes that stuff out and makes it configurable, since they don't allow you to compile things).
No, they'd lose that. If Windows is a valid trademark in the software industry, then Lindows is *not* available as a name. Trademark law is pretty clear on this. Note that MikeRoweSoft could not be used *even though* his name was actually Mike Rowe.
The only way that Lindows.com, Inc. can win is to invalidate Windows as a trademark. They are *not* sufficiently different to win the case. That said, this is not as difficult as it sounds. All they have to establish is that Windows was a generic term that could be trademarked as *part* of Microsoft Windows but could not be trademarked *alone* and Microsoft is out of luck. In the meantime, they can continue to use the name.
If Microsoft really had a case, they would be pushing for a decision, as that would grant them injunctive relief (making Lindows.com, Inc. change their name) and possibly damages (i.e. Lindows.com, Inc. might have to pay them money).
Microsoft would have never received the original trademark? As it is confusing to the market to call your windowing system Windows when other companies can also release windowing systems (and had at that point; X-Windows was already around by '93; I used an early version of it in '89). Understand that this is the crux of the case at the moment: the question of Microsoft's ability to trademark Windows *at all*.
It is reasonable for your (presumably not native English speaking) mother to associate windows with buttons, menus, and blinking cursors...those are all characteristics of a windowing system. That does not translate to mean that she should associate those things with the *Microsoft* OS that includes those. Both MacOS and KDE (a Linux windowing manager; in fact, the one used by LindowsOS) also include buttons, menus, and blinking cursors.
Also, the product is called LindowsOS, not Lindows. Get the difference? It is the Lindows OS. OS being a generic term in the software industry; Lindows being the firm's name.
In regards Telnor, what would happen if someone called their upstart ISP Webnor or Teloslo? Both those names are assembled in similar fashion to Telnor (or Lindows: LINux, winDOWS) but are distinctive. Would Telnor have a case against either of those? I think that you are simplifying this far more than one can.
The point is that Microsoft is *dragging* out the case. They wouldn't do this if they thought that they could win. Then they would just get their ruling and go home. Remember that the basis of a trademark claim is that they are suffering ongoing damages by the confusion of their trademark. If that is so, they should be trying to *hurry* the trial and get injunctive relief as soon as possible.
The only point in dragging out the case is to hope that Lindows will decide it is cheaper to settle than to continue the case. As such, the moves to drag out the case are themselves evidence of the weakness of the Microsoft case in the US.
If Red Hat were suing a software company that named itself Blue Hat, I would expect them to expedite the trial as much as possible. They would base their claim on the identification of themselves as the Linux distro named after a colored hat, and I expect that they would win. The difference being that Red Hat is unique to them and has nothing to do with their actual business -- it is just a label that they made famous through their actions. By contrast, if they had named their company Red Disk, I expect that they would lose a suit against a company calling itself Blue Disk as a disk is a generic term related to what they actually do. I would also expect them to lose against Blue Hat if Blue Hat were in another industry (consider Blue Bonnet butter/margarine for example).
Microsoft's problem is that they pick non-trademarkable terms (in their industry): Disk Operating System, Windows, Office, etc. Even Excel is a play on the word Cell. Yes, they can keep people from using Excel but could they keep someone from using (for example) EasyCell?
Re:What "cheap, high speed cable access" ?
on
Copyright Defeats?
·
· Score: 1
In general, residential internet access in the US has no caps on usage (and thus no fees for excess usage).
Traditionally, cable internet providers lost money (e.g. @Home). Prices have increased somewhat from then and the situation now seems stable. People don't understand how much fiber costs to run (and broadband needs fiber--the last leg can be coax or phone line, but the distance runs need to be over fiber; too much signal loss/distortion otherwise).
The real reason why Residential internet prices in the US have been increasing is that there are no measures to hold down bandwidth usage. This results in an increasing average bandwidth used (as more and more people run at full speed). Businesses have always paid more because they share their connections more, which causes greater bandwidth usage. Business cable benefits from the fact that it doesn't run over the same circuits as phones, so it is not competing for space with them during the busy day.
Re:Sure. As of yesterday even.
on
Copyright Defeats?
·
· Score: 2, Insightful
You missed the point. The idea is not to support widows and orphans in general. The idea is that if your primary income is from sales of copyrighted works, that income should be able to continue for a time after you die to support *your* widow and orphans. The main reason to do this is to give authors a financial incentive to keep writing up till the day that they die. It's also worth noting that the net effect of this particular proposal would be to reduce copyright length by at least 50 years.
By your argument, we should also get rid of alimony and palimony--after all, they only go to divorcees and children where the husband/father has some sort of income (i.e. is alive and working). This discriminates against those cases where the father is dead, disabled, or otherwise not working.
Yes, they could produce the source transferred to IBM, but how do they prove it was original to them? Further, the IBM part of this is a sideshow. Even if IBM loses the case based on their contract with SCO, that does not necessarily mean diddly squat to Linux. Otoh, the question of who originally wrote the code in question is very important to Linux. For example, if it turns out that OSS code was included in SCO's product (that they licensed to IBM), then it would be SCO who was in violation of the OSS copyrights, not vice versa.
Btw, I wouldn't be surprised at all if much of the code that is in both places turns out to be from sources such as Stevens' TCP/IP Illustrated books and other such public places (including academic papers). I find it far more likely that both SCO and Linux were sourcing the same places for algorithms, etc. than that someone was deliberately taking SCO code and putting it in Linux without anyone noticing before this.
This would probably be obvious if the Linux code in question were highlighted (i.e. people could provide the actual source of the code snippet, showing that it was not SCO).
Rather than selling the stock outright, a better move is to *short* the stock. In this situation, what you would be doing is promising to sell the stock at some low price ($.01, just like the CEO pays would be good) in the future. This reduces the current stock price, because people who might consider buying the stock buy the option from you instead.
In the meantime, you would still maintain your ownership position and could assert your rights as a stockholder.
Btw, you don't have to own SCO stock to short it. If you don't mind the liability (if the option is called, you have to buy enough shares to cover it), you can short stock with no ownership--just a cash deposit.
If I had any money, that is what I would be doing.
The SCUM are SCAMming us. They don't even own the trade secrets about which they are suing. They just want to SCIM a little money by selling their stock while it is high. Of course, maybe they didn't realize that corporate officers have certain honesty requirements under the law. I hope they enjoy their cushy jail cells with their soul mates from Enron.
I think that they are wiping the hard drive as much to keep the thief from *using* the computer as to hide the data. If the hard drive gets wiped every time they connect to the internet, what's the point of having the computer?
I had this happen once. A VP was getting laid off (which we didn't know) and wanted to copy the data off of his hard drive. We hooked the hard drive to another computer and it ate itself. Fortunately, he wasn't mad, since he knew he was trying to circumvent his company's rules. However, we didn't know that it was intentional, so we were very apologetic. I found out that he (and lots of other people) were laid off a week or two later when one of his employees applied for a job. It all made sense then...
That assumes that you are using an ISP that is small enough that a single T3 is sufficient. Instead, consider a company like godaddy.com which is much larger. I hardly bother to read my ISP email address. Instead, I maintain a Yahoo address (for spam collection) which I use to sign up for services, and a permanent address for which I pay an annual fee. That fee is based purely on email server management. That is what I expect to drop by a 1/3 if their spam burden is lower.
Also, spam periodically has the effect of DOSing email servers. This also increases their costs. Along with filtering, letters to abuse, etc. All that requires more personnel, space, and servers than they would otherwise need.
You are correct, at an ISP with spare resources price will not be affected by this. However, larger ISPs do not have slack resources. Increased traffic means that they have to increase resources (spending). Since they are highly competitive (I can use any email server on the internet), these costs will be passed on to the consumer.
Slashdot Mirror
Yes, but blacklisting works when you know who the sender actually is. The current problem with blacklisting is that the spammers make up email addresses.
No anti-spam solution works in isolation. There are several levels needed. SPF provides authentication for the sending server *i.e. the domain). SMTP Auth provides authentication for the username (person). Blacklisting blocks emails from bad (but authenticated senders). Content recognition helps when you have a sender from whom you would like to get email but who is now compromised.
I don't need to know the people to get them to fix their machine. I just need to know how to reach them (I have the email address) and their ISP (abuse@theirdomain -- I have their domain from their email address). If that is not sufficient, then I can blacklist. Because I have their actual identity, I can blacklist effectively (i.e. once they are on my blacklist, they have to compromise a new machine).
Look at virus outbreaks for a good example of why this is better. When someone who has my email gets a virus, I get loads of emails from various other people in my address book. With this, I only get emails from one person. I can then blacklist them or run their email through Bayesian filtering. Now I don't have to worry about false positives from other email addresses, just this one.
To me, false positives (ham identified as spam) are the worst part about spam. SPF, etc. help reduce the possibility of false positives by helping you divide your emails into four groups: someone you know and trust (bypasses content filter); someone you know but do not trust (content filter); someone who you know to be bad (refuse all email); someone you do not know (bypass content filter with first email -- use that to allocate them to one of the other groups). Now you only have to worry about false positives in the second group (and possibly the fourth if that becomes a problem area).
If you really want, you can set SPF ( spf.pobox.com ) to authorize your ISP mail server to relay mail from your own domain (this is useful if your domain does not have its own mail server). However, a better solution is generally to SMTP AUTH to the mail server for your domain (rather than the mail server for your bandwidth, i.e. your ISP). SPF will support both though; it is your responsibility to make sure that this secures you from relaying.
Not sure if the Microsoft/sendmail suggestions work the same way.
I don't disagree that in the way that it is used *now*, that it is not overkill. What I'm saying is that a public key system would not be a good general system. I.e. when I get an email from a stranger (which is when it matters; other than virus outbreaks, very little spam comes from friends), I would have to find someone I trusted to verify the stranger. This is where you get long chains (I won't speculate as to length again).
Public keys work great when you want to verify someone you know (although I think that they would work less well if *everyone* used them; the technical difficulty keeps out many of the people who would get virus infected, etc.). The problem is that spam is usually from someone you do *not* know. Now, you could reject all email from those that you do not know, but the effect of that would be to eliminate some email you might want to receive (I do a lot of PHP contract work; a stranger contacting me is a *good* thing).
The more you automate the system, the more vulnerable it is to assault. If everyone used public keys, then all spam would be created by viruses and crackers. Yes, you could revoke the key, etc., but all that takes time. Especially if you cache results (my ISP can take up to a week to update DNS). Further, I have had people take two or three *days* to fix their virus infected computer (which is essentially a stolen key situation), even after I told them what the problem was. End result, a lot of people would have their keys revoked because someone down chain was misusing it (and someone up chain is not willing to wait until they correct it). Until they figure it out, this means that their *valid* email is getting rejected.
A two level verification system (with SPF as one level) is better as a general system. SPF verifies that the machine (IP) is authorized to send mail for that domain. The machine (which can be an SMTP server or just a workstation -- limiting to SMTP servers is more secure; the domain owner can set this) is then responsible for verifying the identity of the person sending the email (in whatever fashion). Now, they either need to crack an SMTP server or a DNS server to send mass emails.
In a public key system, cracking an individual computer can give you access to a key which would allow the spammer to send emails from a separate machine or machines until the key was cancelled (and the cache clears). After the key is cancelled, you lose valid email until a new verification path is created.
The SPF method involves no changes in MUAs (except possibly the introduction of something like SMTP auth, but common MUAs already support this); no extra key signing software; puts the burden on domain *owners* to secure their domain; is easy for ISP tech support to help people set up. Compare to public key situation: tech support says, "you need to send your key to us to get signed." A couple days later they get a letter in the mail with the person's house key. Silly? Yes. Something that would actually happen? You betcha. The majority of users require an abstractable method where someone else does the heavy lifting.
A public key interface is great when everyone involved is motivated to maintain it. However, this is not generally extensible IMO. If everyone used it, we would be continually managing stupid key problems (e.g. Jane revokes John's key because John didn't call her the next day, which shows up the same as if she revoked his key because he sent spam) caused by relying on non-technical users. This is not to say that public keys are a bad idea (they aren't); merely to say that they are not a universally scalable idea. At least not IMO.
We don't need to trust the *person* sending the mail. It would be sufficient to trust the machine that is doing so.
Look at http://spf.pobox.com/ which is sufficient. With SPF, you know that if you are getting SPAM saying it is from @ultraviolet.org, then it really is from @ultraviolet.org (or at least someone who ultraviolet.org trusts).
Your solution requires a certain level of technical proficiency (setting up and managing the key) of *all* participants. SPF's solution only requires technical proficiency from those who manage DNS settings and those who manage email servers (in particular the person who manages your email server).
Also, what about *stolen* keys? And who handles key checking? SSL certificates are restricted to a few root signers, but you don't want a central certificate authority. PGP/GPG work well because they only involve small numbers of people. In general, you know the person directly. Occasionally it will be a friend of a friend message. What do you do when the chain is 10 or a 100 or a 1000 keys long? How long will it take for you to find out that 978 has since revoked their signature for 977 (counting in steps from you, i.e. you are 0 and 1000 is the original signer of this chain)? Or how long will it take you to verify all 1000 keys if you try to do it real time (i.e. when you get the message)?
username+filtername@domain.com should go to username@domain.com as per the RFC (the +filtername is carried but not used by servers, or at least it shouldn't be). Some email clients will allow you to use this for such things as folder sorting (i.e. username+foldername goes into foldername automatically). If this worked consistently, it would be good for people who don't have the ability to make more usernames.
AFAIK, username-filtername will still just go to username-filtername, i.e. you have to configure your mail server to handle username-filtername separately from username. This works great when you can specify as many usernames as you want (i.e. if you manage your own server or have a catch-all on your domain).
Maybe you are talking about something different than the original poster?
One reason why the - would work when the + does not is that the - can appear multiple times, so it just another valid character (like a letter, number, or underscore). The + can only appear once, so many servers can ignore it, drop it, or puke on it.
Interestingly enough, while the (optional) challenge/response system is what gets the press, the main purpose of TMDA is to create aliases like username-filter (and then filter based on them). Thus the name: *Tagged* Message Delivery Agent. The -filter is the tag of Tagged.
No, I put two and two and two together and realized that it could be made *into* a SCO joke. Without saying SCO (or making any reference to an outside entity that might be SCO), it is not at all obvious that it refers to SCO.
/. readership).
The way the original post reads, *you* believe that Linux steals IP and think it is the same thing as Festival (regardless of what you actually believe, this is how it reads). That's not funny to people who don't agree with the position that Linux steals IP (the majority of the
I'm not claiming that you were trolling by posting flamebait. What I am saying is that that post speaks in a way that is flamebait (by assuming that Linux steals IP). There is *nothing* in the post to indicate that we should have been looking for someone other than you who would hold that position. As posted, it looks like something that would be posted by Darl McBride (or whatever his name is).
It's like the following exchange:
Knock, Knock.
Who's there?
Orange.
Orange who?
Orange you glad it's not banana?
It makes no sense unless you already know the joke. Why? It's missing the whole prep of the repeated Banana sequence and skips straight to the punch line. Punch lines are not funny without the prep.
How does Linux "steal IP?"
If the message had said, "When the Festival arrives, SCO will sue it saying, 'It's just like Linux; it gives us technological gifts in exchange for stealing IP,'" then it would have been satire, humor, social commentary, and geek humor.
Without SCO, it's trolling flamebait.
Innocent? Like Open Relays are innocent? Domains that are unwilling to do a minimal amount of authentication support are not innocent IMO. Simply reckless and dangerous.
I'll take your bet with the following modifications: SPF or another reverse DNS method that does the same thing (authenticate IP addresses as valid senders for a domain); take hold defined as more than 50% of the domains with MX records have SPF records.
I hear that AOL is adopting SPF. If Hotmail and Yahoo follow, the pressure will build. Particularly with ISPs like EarthLink adopting TMDA-like challenge response systems (plus the Microsoft version that is currently being contemplated). SPF helps one of the biggest problems with the SMTP protocol: the lack of sender authentication. The biggest obstacle to its adoption is the pressure from Microsoft, et. al. to develop a more expensive solution (remember the proposal to create SSL-like ID certificates?).
If you are on the whitelist, you can spam (no challenge). If *everyone* used TMDA, that would be the only kind of spam (whitelisted spam), and there is no point in sending spam if it is not going to be received. Whitelisted spam will not be challenged; it's already whitelisted. Also, whitelist spam will be relatively rare, as it would put the burden on the spammer to get an address you whitelisted.
If *everyone* used TMDA, then there would not be a user level problem with challenges for messages that you did not send, as TMDA can drop challenges from people to whom you have not sent mail.
Even at the ISP level, remember that we now have 60% of the email bandwidth with which to play (the reduction from current spam). That should more than cover sending a challenge for every email message much less the trivial number of legitimate messages that actually get challenged (6%) by a TMDA system.
TMDA works really well with a system like SPF. With SPF compliant domains, you can identify the sender (or at least the sending domain) accurately. If you can do that, no fake challenges to SPF compliant domains with solid authentication of SMTP users (of whatever form: SMTP Auth, etc.). Now, the fake challenges (i.e. those to people to whom you did not send mail) encourage faster adoption of SPF (and thus more authenticated senders).
The error that you are getting is telling you that you are trying to relay through a mail server, i.e. that the To email address is not associated with that mail server and that you haven't met its standards to send from the From email (in your case, it sounds like it requires you to have appropriate DNS records for the sending IP; it could also use SMTP authentication as well--same concept). All correctly configured mail servers will do this in some manner. In fact, one of the spam blocking techniques is to set the server to reject email from any server that is on one of the lists as an "open relay" (meaning that it is not properly configured to reject unproven senders to outside domains). You won't get that error if you try to send from an outside domain to one that Verizon manages.
A more common method is to check for a PTR record for the IP that is sending you the email. If it doesn't have a PTR record, then your mail server rejects the mail. Checking for an MX record is overly restrictive and will blacklist many large organizations.
There is also a method called SPF that actually does allow organizations to "whitelist" their mail servers as appropriate senders for their domain. I just found out about it today, but I have my host looking into adding the appropriate DNS entry for me. The great part about it is that it is a whitelist method at the domain level, i.e. it makes individual domains responsible for authenticating their mail sending servers. Combined with a blacklist of open relays, this allows you to at least apportion blame. If spam is sent, then that domain can fix it, because it is caused by a failure in their authentication system.
If everyone used TMDA, then there wouldn't be non-whitelisted spam. That 60% reduction in email would more than cover the bandwidth for the once per sender authentication that TMDA requires (actually less than that, since it auto-whitelists people to whom you send email and allows you to just whitelist people). Especially considering that a TMDA challenge is relatively small if you don't return the original message.
Combine TMDA with something like SPF sender validation ( spf.pobox.com ) and you won't even have the bounce problem unless someone's actual account was used to send the email.
You give the mailing list a special email that always goes through, or you just whitelist (i.e. add them to your "buddy" list before they send you email) the mailing list. Whitelisting is better but doesn't work if your list sends from people you've never seen previously. If the list always sends from itself (i.e. listname@listserv.com), then a whitelist is the way to go.
TMDA also supports throwaway email addresses that you can use to register at a site that sends an email confirmation. The email address will stop working after a while and the site can't spam you. Think real.com for an example of why this is necessary. You can also get throwaway email addresses from spamgourmet.com without TMDA.
As someone who used to sysadmin a mail server, I can tell you that this (saving info about who emailed who) is already required. I forget what the limit was, but we were supposed to keep the mail logs (which carry from who to who info) for at least six months. We actually archived them to our write only backup system on a regular basis. AFAIK, they stayed there forever (of course, it's anyone's guess whether or not we would have been able to retrieve them; our backup system had issues--thus the write only tag).
This proposal does not involve collecting or saving new info. It involves *using* the existing info at a summary data level. Also, understand that it would be the *recipient's* ISP who would do this, not your ISP. This means that they could only collect info on what you send to email addresses on that server, not cross reference it with all the email that you send.
It's also worth noting that other ISP-level SPAM filters already process this info as well. This isn't a new concept. The new part is that it is trying to use the patterns *before* putting it in the receiver's mail box rather than after it is identified as SPAM by the receiver.
No, don't pay your ISP; pay the *receiver's* ISP. Paying your ISP is just silly (unless they then transfer it to the receiver).
Then your ISP can credit you for the amount of email you receive. If you receive more than the cost of providing you services (not just email but bandwidth), then you get free internet that month (a hundred pieces of SPAM a day would pay for $30 of internet a month; easily cover dial-up and cover at least half of most broadband options).
Note that this changes everything. Now, spammers will only want to send to people who will buy what they are peddling. Plus, they will have to be vigilant about ensuring this as people will want to receive filterable email (pays you money but you still don't have to read it).
Mailing lists would work through an opt-in system with the receivers' ISPs. You pay $.01 per email sent by the list who pays $.01 to send it. Net result: no money transfers. You can whitelist individuals the same way.
Then how do you explain Nimda and SQL Slammer? Both of those affect Microsoft products (and their vulnerabilities) that are in the *minority* of those available. Apache trounces IIS in usage numbers (both because more web sites using it and because higher traffic web sites use it), and any of MySQL, Oracle, or IBM (I forget the actual name) outnumbers Microsoft SQL Server.
IMnsHO, exploit authors prefer Microsoft Windows products because they are buggy (note that the posted exploit actually affects a discontinued product, it lasted that long), because they are based on a buggy security model (oh, you are code? I'll run you automatically and save asking the user if he/she wants to run something from "MLM will make you millions!"), and because they are commonly used by people who don't know what they are doing. Any twit can install IIS--it's just a matter of following prompts. With Apache, you need a certain level of knowledge; particularly if you are not happy with the default settings and want to change them (especially the compiled in settings, which can obviously only be changed by recompiling the software; Microsoft writes that stuff out and makes it configurable, since they don't allow you to compile things).
No, they'd lose that. If Windows is a valid trademark in the software industry, then Lindows is *not* available as a name. Trademark law is pretty clear on this. Note that MikeRoweSoft could not be used *even though* his name was actually Mike Rowe.
The only way that Lindows.com, Inc. can win is to invalidate Windows as a trademark. They are *not* sufficiently different to win the case. That said, this is not as difficult as it sounds. All they have to establish is that Windows was a generic term that could be trademarked as *part* of Microsoft Windows but could not be trademarked *alone* and Microsoft is out of luck. In the meantime, they can continue to use the name.
If Microsoft really had a case, they would be pushing for a decision, as that would grant them injunctive relief (making Lindows.com, Inc. change their name) and possibly damages (i.e. Lindows.com, Inc. might have to pay them money).
Microsoft would have never received the original trademark? As it is confusing to the market to call your windowing system Windows when other companies can also release windowing systems (and had at that point; X-Windows was already around by '93; I used an early version of it in '89). Understand that this is the crux of the case at the moment: the question of Microsoft's ability to trademark Windows *at all*.
It is reasonable for your (presumably not native English speaking) mother to associate windows with buttons, menus, and blinking cursors...those are all characteristics of a windowing system. That does not translate to mean that she should associate those things with the *Microsoft* OS that includes those. Both MacOS and KDE (a Linux windowing manager; in fact, the one used by LindowsOS) also include buttons, menus, and blinking cursors.
Also, the product is called LindowsOS, not Lindows. Get the difference? It is the Lindows OS. OS being a generic term in the software industry; Lindows being the firm's name.
In regards Telnor, what would happen if someone called their upstart ISP Webnor or Teloslo? Both those names are assembled in similar fashion to Telnor (or Lindows: LINux, winDOWS) but are distinctive. Would Telnor have a case against either of those? I think that you are simplifying this far more than one can.
The point is that Microsoft is *dragging* out the case. They wouldn't do this if they thought that they could win. Then they would just get their ruling and go home. Remember that the basis of a trademark claim is that they are suffering ongoing damages by the confusion of their trademark. If that is so, they should be trying to *hurry* the trial and get injunctive relief as soon as possible.
The only point in dragging out the case is to hope that Lindows will decide it is cheaper to settle than to continue the case. As such, the moves to drag out the case are themselves evidence of the weakness of the Microsoft case in the US.
If Red Hat were suing a software company that named itself Blue Hat, I would expect them to expedite the trial as much as possible. They would base their claim on the identification of themselves as the Linux distro named after a colored hat, and I expect that they would win. The difference being that Red Hat is unique to them and has nothing to do with their actual business -- it is just a label that they made famous through their actions. By contrast, if they had named their company Red Disk, I expect that they would lose a suit against a company calling itself Blue Disk as a disk is a generic term related to what they actually do. I would also expect them to lose against Blue Hat if Blue Hat were in another industry (consider Blue Bonnet butter/margarine for example).
Microsoft's problem is that they pick non-trademarkable terms (in their industry): Disk Operating System, Windows, Office, etc. Even Excel is a play on the word Cell. Yes, they can keep people from using Excel but could they keep someone from using (for example) EasyCell?
In general, residential internet access in the US has no caps on usage (and thus no fees for excess usage).
Traditionally, cable internet providers lost money (e.g. @Home). Prices have increased somewhat from then and the situation now seems stable. People don't understand how much fiber costs to run (and broadband needs fiber--the last leg can be coax or phone line, but the distance runs need to be over fiber; too much signal loss/distortion otherwise).
Some typical US prices (in US$):
Dial up: $20/month for unlimited access
ADSL, 384K: $40/month
Cable, 1.5 Mb: $55/month
Now compare these to US business prices:
Dial up: $20/month
ADSL, 768K: $200/month
Cable: $90/month
T1 (1.5 Mb): $1000/month
The real reason why Residential internet prices in the US have been increasing is that there are no measures to hold down bandwidth usage. This results in an increasing average bandwidth used (as more and more people run at full speed). Businesses have always paid more because they share their connections more, which causes greater bandwidth usage. Business cable benefits from the fact that it doesn't run over the same circuits as phones, so it is not competing for space with them during the busy day.
You missed the point. The idea is not to support widows and orphans in general. The idea is that if your primary income is from sales of copyrighted works, that income should be able to continue for a time after you die to support *your* widow and orphans. The main reason to do this is to give authors a financial incentive to keep writing up till the day that they die. It's also worth noting that the net effect of this particular proposal would be to reduce copyright length by at least 50 years.
By your argument, we should also get rid of alimony and palimony--after all, they only go to divorcees and children where the husband/father has some sort of income (i.e. is alive and working). This discriminates against those cases where the father is dead, disabled, or otherwise not working.
Yes, they could produce the source transferred to IBM, but how do they prove it was original to them? Further, the IBM part of this is a sideshow. Even if IBM loses the case based on their contract with SCO, that does not necessarily mean diddly squat to Linux. Otoh, the question of who originally wrote the code in question is very important to Linux. For example, if it turns out that OSS code was included in SCO's product (that they licensed to IBM), then it would be SCO who was in violation of the OSS copyrights, not vice versa.
Btw, I wouldn't be surprised at all if much of the code that is in both places turns out to be from sources such as Stevens' TCP/IP Illustrated books and other such public places (including academic papers). I find it far more likely that both SCO and Linux were sourcing the same places for algorithms, etc. than that someone was deliberately taking SCO code and putting it in Linux without anyone noticing before this.
This would probably be obvious if the Linux code in question were highlighted (i.e. people could provide the actual source of the code snippet, showing that it was not SCO).
Rather than selling the stock outright, a better move is to *short* the stock. In this situation, what you would be doing is promising to sell the stock at some low price ($.01, just like the CEO pays would be good) in the future. This reduces the current stock price, because people who might consider buying the stock buy the option from you instead.
In the meantime, you would still maintain your ownership position and could assert your rights as a stockholder.
Btw, you don't have to own SCO stock to short it. If you don't mind the liability (if the option is called, you have to buy enough shares to cover it), you can short stock with no ownership--just a cash deposit.
If I had any money, that is what I would be doing.
The SCUM are SCAMming us. They don't even own the trade secrets about which they are suing. They just want to SCIM a little money by selling their stock while it is high. Of course, maybe they didn't realize that corporate officers have certain honesty requirements under the law. I hope they enjoy their cushy jail cells with their soul mates from Enron.
I think that they are wiping the hard drive as much to keep the thief from *using* the computer as to hide the data. If the hard drive gets wiped every time they connect to the internet, what's the point of having the computer?
I had this happen once. A VP was getting laid off (which we didn't know) and wanted to copy the data off of his hard drive. We hooked the hard drive to another computer and it ate itself. Fortunately, he wasn't mad, since he knew he was trying to circumvent his company's rules. However, we didn't know that it was intentional, so we were very apologetic. I found out that he (and lots of other people) were laid off a week or two later when one of his employees applied for a job. It all made sense then...
That assumes that you are using an ISP that is small enough that a single T3 is sufficient. Instead, consider a company like godaddy.com which is much larger. I hardly bother to read my ISP email address. Instead, I maintain a Yahoo address (for spam collection) which I use to sign up for services, and a permanent address for which I pay an annual fee. That fee is based purely on email server management. That is what I expect to drop by a 1/3 if their spam burden is lower.
Also, spam periodically has the effect of DOSing email servers. This also increases their costs. Along with filtering, letters to abuse, etc. All that requires more personnel, space, and servers than they would otherwise need.
You are correct, at an ISP with spare resources price will not be affected by this. However, larger ISPs do not have slack resources. Increased traffic means that they have to increase resources (spending). Since they are highly competitive (I can use any email server on the internet), these costs will be passed on to the consumer.