Keep in mind that if you short the stock, you end up driving up the stock price and making the company's CEOs, CTOs, etc (both past and present) fucking rich.
If you short stock, you start off by selling it, which would tend to drive down the price. Of course, when you close out the trade you buy the stock, pushing back up a bit, but I fail to see why selling then buying, drives the stock up any more than buying then selling. If anything, buying stock would make the CxO's richs, as it balances their stocking dumping, keeping the price up. However, if you are selling, you are in competition with them, which makes them poorer.
In short, shorting a stock just makes the rich richer and you can see exactly how that corporate greed is destroying the United States economy right now.
Rubbish! All shorting is basically doing is doing a buy low/sell high in reverse. Granted, it's more risky, as the losses are unlimited, but regardless of whether go long or short, once you close out that sale, you have bought and sold the same amount of stock, and have no net effect on price, except for for the time while the trade is open, (and if you are short, you have a net contibution to market sellers, and there is now more stock on the market, so this drives the price down anyway)
Re:I have been working on another one
on
Replacing SMTP?
·
· Score: 1
I see that you propose a "hash key". But where does this key get stored where it is accessable by ANY receiver to verify against, but not by spammers to be forged? The operator of an SMTP server or a hacker who can write a quick script to emulate one, could simply forge the header "sender address" and hash key that was retrieved from the lookup location.
The hash key could contain a hash of multiple things: the sender, the recipient the md5 of the email, so if a spammer got a hold of this hash, this would severly limit what they could send, in the case of all three being set (and checked) he could only basically send the same message to the same person, not much use for spamming! Also, the key could periodicaly expire, so even if they reversed the hash key, by the time that happened, the key would have expired.
How does this eliminate spammers using disposable accounts (or spam friendly ISPs) to send messages that fit all the rules?
It doesn't eliminate it, it just makes it accountable, and therefore easily reportable (in the case of disosable accontes, and easily blockable in the latter case). The problem now is that it's impossible to set up a simple rule to block all email "from" spammer-isp.com, or accept all email "from" trusted-isp.com, because it's imposssible to verify where it came from.
Re:I have been working on another one
on
Replacing SMTP?
·
· Score: 1
The basic premise of my general transport is that all messages are addressed to a public key and come from a public key. All messages are signed by their supposed source ID, and most messages are encrypted to the destination ID.
The main failure of SMTP is that you can't trust the envelope address. If, however, the envelope address became more like the RL equilavent of a postmark on a letter, then it more be more useful - change the from and reply-to all you like, but the sender address will always be from the ISP which injected the email into the system.
Looks like a case of a rapid fix from MS and a kneejerk editor at Slashdot. How about this spin? "Notified of critical bug, MS immediately issues fix". Nah, wouldn't play to this crowd.
New slashdot poll:
A flaw is announced in MS products, what happens next and why?
a) Microsoft release a fix slowly - that would never happen in open source!
b) Microsoft release a fix quickly - they must have known about it already and not told anyone!
c) MS product are a flaw in themselves, recursion not allowed.
d) They should have implemented CoyboyNeal
e) Crappy of options/all of the above
Sure, because it takes no time to sort your documents into shred and no-shred, shred them, then empty the shredder into the trash, rather than just lobbing everything in there.
For the same reason that all email should be encrypted to the same level, you should shred everything, not just items that you consider condifential. Otherwise you're doing some of the work of the attacker for him, by sorting out the data into important and not-important.
How long do you have to ordinarily hold a stock before receiving a dividend? Could I buy M$ stock now and get the dividend?
When a dividend is announce, the share is regarded as cum-dividend, i.e. the shares also have the dividend right. On a predefined day, the shares go ex-div, which means that they no longer have the dividend right attached. The person who owns the share at close of play before they go ex-div is the person who is entitled to the dividend.
What I'm wondering is if I could make better profits from buying and selling at dividend time than the crappy 3% I get from the bank.
No, you won't, because on the day the shares go ex-div, they normally drop by the amount of the dividend, as prior to that you are paying for the share+dividend, afterwards you're just buying the share.
Rough example: if MS have 1B shares, worth $28 each (total market cap of $280B), and the dividend is $10B, then the market cap after the dividend is paid out will be rought $270B, so the shares are currently worth about $27, but you're paying the extra $1 for the dividend rights.
So, if you bought shares beforehand, you'd end up buying a $28 share, getting $1 income and selling the share for $27. Result, $1 income, $1 captial loss, which isn't the best tax situation to be in!
In the US, there are anti-trust laws that say that you can not (under specific rules) force people to buy one less desireable product in order to get a more "desireable" product. It is called bundling and in some cases it is a violation of anti-trust law.
Not quite. According to the artists, they regard the complete album as the product, not individual tracks. If you accept that point of view, it's sounds like a reasonable request.
So I put a 5XX level reject on the SMTP server so that anything from amazon gets rejected. 3 years later, amazon STILL tries to connect to my server, and Still gets rejected.
Make it a 4XX level delay, and include a comment about the temperature of hell being currenlty too high for you to accept any emails from them.
No. The reply-to field is for directing replies to an address different from your own, not for indicating who sent the e-mail. Mailing list servers and private whitelists generally check against the From field
Hence why they have three fields:
Sender: Who posted the email - the foreign isp
From: Who sent the email, your home isp address
Reply to: who you want to reply to.
I regard the Sender/envelope address as a electronic postmark - if you post a letter abroad, you can put your own return address on it, but it will always have a foreign postmark.
For instance, I'm now at home, and I would like to send mail with my University address. I can not do that, because the University blocks relaying from external IPs. So I send mail with my ISP account, but with the headers of my University account. If my University implemented a RMX record, I could no longer to that. And unless I can authenticate with the University servers to send mail through them, I can't send mail with my own mail address on it!
I believe you'll find that's what Sender/From/Reply to address are there for. The envelope address is supposed to be an electronic equivalent of a postmark - on a real letter you can write any return address you like, but don't expect your home post office to stamp it with the university post office mark.
So what needs to be developed is a backwards-compatible mail transfer protocol that authenticates the user to the sending server and forwards the message to the receiving server, who contacts the sending server back and verifies the user's identity.
I've proposed this idea before, not on the user level, but on the domain level. Every email that gets sent from say, example.com also has a hash key. When a enabled server receives this, it can check whether the key is correct, and if not reject it. This would be backwardly compatible, as the only case it would matter is if two enabled servers were talking to each other (all other cases are unchanged). It would also have the benefit of example.com's rep going up, as there would be no forged emails from that domain, and any spams that were received from that domain could be dealt with (I wonder how much ISP time is wasted by people complaining to the wrong ISP?)
There would be an enticement to hosters to upgrade, as their domain would then become "100% spam unforgable" and clients would see it as a plus as they could now trust those domains and not need to filter that domain.
If it became a situation where spammers couldn't use yahoo.com as a return addres, they'd change to a new one, and pressure would be on the new forged-from victim to upgrade.
A a previous poster said, this would also transfer the spam problem from a type 1 (forged headers) to all type 2 (relible headers), making it easier to track.
For those that say this would ruin smtp, and you need to set different from headers - that's what sender and reply to fields are for. Leave the envelope from header as a "postmark" and put whatever return address in the email itself you like.
Its no secret that spam is hard to identify. If it were easy to identify, we wouldn't even have this duscussion. BUT, if you can't identify it well enough to filter effectively,
So step one should be to be able to identify it correctly, so consider the following:
(Firstly, I assuming it is possible to add commands (like ESMTP) on top of SMTP that will be ignored by non aware servers, and hence be backwardly compatible.) Now, take company example.com
Example.com has a DNS record (say type MXC) with its public key, and all emails sent from its servers include a dated confirmation key.
A non aware smtp server receiving email this way from example.com (or anyone else) doesn't recognise the ESMTP command, and works as today.
A MXC-aware server receiving email from a non-MXC-enabled server, also works as normal.
However, a MXC-aware server that receives email from example.com domain can check whether it was really sent from example.com, and if not reject it.
From that one change, you can be assured that any mail with the envelope from address of example.com came from example.com, and example.com should deal harshly with valid complaints (as that should be the only type they receive). Result: No spam at all comes with example.com as the return address, example.com gets a good name. (considering the amount of people that do a wildcard refuse from certain domains, this should be popular with those providers.
For those that say that this will ruin smtp, and you need to set from address differently, that's what the sender/reply-to headers are there for. Use the envelope-from address as the postmark, you can put whatever return address you like, so long as the postmark isn't forged.
Make spam easier and focused to complain about, and give companies a way to "look 100% clean" and competition and market forces should do the rest.
Besides, eventually Linux will not be 'allowed' to run on this processor.
_That_ would be an antitrust suit that would sail through the courts.
IANAL, but I thinkI was taught that when one company tells you what other companies you _must_ do business with, it's much more clearly illegal (in the USA) than having market dominance.
Actually it's not hard to see how it could be done. If the processer requires a "secure" OS to run, this does not specify which one, or from whom, but it does set a minimum requirement, and if Linux is unable to meet this requirement e.g. because of licencing, then what could you do?
Just look at what happened with DVD's under Linux. Any disk with CSS on it will only be played with a player that understands CSS and has a key. If you don't have a key, you can't play it. With the DMCA et al, you can't write your own CSS app, and you have to licence it. Although with DVD's it could be possible to licence CSS and write a player under Linux, you wouldn't be able to release the player under the GPL.So, what happens if the equipment is more low level, and the "player" is the OS? With the same situation, you couldn't release the player (OS) under the GPL, ergo, linux can't support it.
No part of the organization's purposes or activities may be illegal or violate fundamental public policy.
So one of the requirements to be classed as a religion, is that it has 100% legal activities? Does this mean that if the governement outlaws one of those religious activities, then it might stop being a religion? Or would the government be unable to pass this law due to the constitution?
In either case, it could create difficulties, you could end up with the ability to outlaw certain religions, or alternatively, be unable to legistate against certain actions because they are part of a currently valid religion
We've just started authoring dvd's here at the office and I've recently found out that I can set different parts of the dvd to different region codes. Basically what this means is that if we build content for spain and we encode it for the spaniards' region, so they only see the spanish content, and we can also have a sperately encoded section (completely different content) for the USA in all english.
That's a bit of a pain for those Spanish people in the US, and those living in Spain who speak perfect english, isn't it?
This also enables us to specify content for different cultures, cause some people aren't down with the american way of life
And if you happen to be interested in a culture that's different to the one you're living in, you're out of luck, eh? Isn't learning about new cultures a good thing to do?
Here's an idea: What about having all the content available to all regions, and let the user choose? Bit too radical, eh?
Re:Piece of advice...
on
Minority Report
·
· Score: 3, Funny
In the first paragraph of the summary say: "Go see this movie" or "Don't go see this movie".
You mean, "We know you were going to see this movie. We know you won't enjoy it. We're going to stop you before you go".
In projects, there are always choices to be made which are neither right or wrong, but have to be made and stuck to. How will these conflicts be decided, and, more importantly, ensure that these (often apparently arbitary) decisions are followed by everyone?
(One example of this is driving on roads, it's not "better" to drive on the right or left, so long as everyone drives on the _same_ side)
This addition allows the government to get the permission of the owner of the computer to listen in on what someone is saying.
And who do you think owns the equipment at your ISP? You or the ISP? With this addition could not the FBI get permission from the computer owner (the ISP), and read _your_ emails without the need for a warrent?
To place a tap, the FBI need to get a warrent, requiring a judge be convinced. With this addition, to place a tap, the FBI now just need to get the owners permission, requiring only the ISP to be convinced.
IMHO you're allowed to port a GPL project to another programming language, eg. C to Pascal. But what if you port it to Assembler?
Question: What happens if you port a GPL product from 'C' to language 'I' where 'I' is an internal, never released language. The source in now in 'I', which is the preferred source for editing, but no one else can actually compile it, because there is no available 'I' compiler'. What happens then? Are they required to release the source to 'I' as well?
Or what if your source contains scripts for internal tools, without which you can't compile the GPL code into the binary? Or if you have to use a certain compiler to get the exact binary as shipped. Would releasing a GPL program compiled with a non-free C compiler cause any issues?
So how about this: every time my computer receives an email, it initiates a connection to the sender and tries to send a reply message.
And what happens if you are receiving an email from someone who has the same rules applied to their server?
Have a look at "man hosts.allow" and read the section under "booby traps" referring to infinite finger loops
Of course, spammers might start to make the return addresses random (but valid) return addresses at yahoo, etc.
You mean like spammers do already?
What about the following? This assumes that only yahoo.com sends out addresses with yahoo.com as the _envelope_ address (as opposed to having yahoo.com as the from/sender fields, which anyone should be able to do to set return addresses. In the latter case, but the envelope address should be your isp address in this case.)
...Welcome to server.isp.com. This mail service is brought to you today by the random number "rand_num" and the letter Q.
1) HELO Yahoo.com (date) (date-key+rand)
2) MAIL FROM: (user@yahoo.com)
(check_mail rule:
a)is date correct?
b)do we have yahoo.com's current (not expired) public mailkey?
b-1) No? query dns record type "MK" for yahoo.com)
c) Does record MK exist?
c-1) Yes. Is f(date-key, "yahoo.com", date, rand_num) = key?
c-1-1) yes? - accept.
c-1-2) No - reject.
c-2)Domain not verified, accept for backward compatiblty (current situation)
I think the above could be useful, as most solutions I've seen rely on the network effect of everyone switching over, and getting people to reject all non-verified address. however, the above would allow even one isp to change over (by adding a dns record) to say, "we've changed over, if you getunverified email "from" us, it's not - reject it. Result? Zero forged emails from isp, isp rep goes up. Other ISP's get interested. Keys can be expired periodicly where "key expiry time" < "time to crack key"
The third requires that one intentionally cause damage (exceeding $5000, in most cases) to a protected computer, where "protected computer" means US Government, financial institutions, interstate and foreign commerce and communications.
Emphasis mine. In other words, a "protected computer" is any computer on the internet worldwide. Every computer on the internet is "used in interstate communication", isn't it?
Defacing websites is not a terrorist act unless the computer belongs to one of the above categories
Can you list any web site that *doesn't* belong in the "protected computer" category as outlined above?
Also, that under this act it won't be "defacing a web site", with the overtones of "graffati", it will now be defined as "attacking a protected computer", with the overtones of "terrorism".
It's all about perception in the public eye, the ordinary person will hear "attacked a protected computer", gasp, and call for a severe punishment, even if he has no idea what the wrongdoing entailed.
Slashdot Mirror
If you short stock, you start off by selling it, which would tend to drive down the price. Of course, when you close out the trade you buy the stock, pushing back up a bit, but I fail to see why selling then buying, drives the stock up any more than buying then selling. If anything, buying stock would make the CxO's richs, as it balances their stocking dumping, keeping the price up. However, if you are selling, you are in competition with them, which makes them poorer.
In short, shorting a stock just makes the rich richer and you can see exactly how that corporate greed is destroying the United States economy right now.
Rubbish! All shorting is basically doing is doing a buy low/sell high in reverse. Granted, it's more risky, as the losses are unlimited, but regardless of whether go long or short, once you close out that sale, you have bought and sold the same amount of stock, and have no net effect on price, except for for the time while the trade is open, (and if you are short, you have a net contibution to market sellers, and there is now more stock on the market, so this drives the price down anyway)
I see that you propose a "hash key". But where does this key get stored where it is accessable by ANY receiver to verify against, but not by spammers to be forged? The operator of an SMTP server or a hacker who can write a quick script to emulate one, could simply forge the header "sender address" and hash key that was retrieved from the lookup location.
The hash key could contain a hash of multiple things: the sender, the recipient the md5 of the email, so if a spammer got a hold of this hash, this would severly limit what they could send, in the case of all three being set (and checked) he could only basically send the same message to the same person, not much use for spamming! Also, the key could periodicaly expire, so even if they reversed the hash key, by the time that happened, the key would have expired.
How does this eliminate spammers using disposable accounts (or spam friendly ISPs) to send messages that fit all the rules?
It doesn't eliminate it, it just makes it accountable, and therefore easily reportable (in the case of disosable accontes, and easily blockable in the latter case). The problem now is that it's impossible to set up a simple rule to block all email "from" spammer-isp.com, or accept all email "from" trusted-isp.com, because it's imposssible to verify where it came from.
If you see my past messages, (e.g. http://ask.slashdot.org/comments.pl?sid=56973&cid= 5506309 and http://ask.slashdot.org/comments.pl?sid=27728&cid= 2981955 ) I've been bouncing around an idea like this too, which is backwardly compatible and has a positive network effect for adopters.
The main failure of SMTP is that you can't trust the envelope address. If, however, the envelope address became more like the RL equilavent of a postmark on a letter, then it more be more useful - change the from and reply-to all you like, but the sender address will always be from the ISP which injected the email into the system.
Well, if you can patent a process, I'm sure you can sue one!
Looks like a case of a rapid fix from MS and a kneejerk editor at Slashdot. How about this spin? "Notified of critical bug, MS immediately issues fix". Nah, wouldn't play to this crowd.
New slashdot poll:
A flaw is announced in MS products, what happens next and why?
a) Microsoft release a fix slowly - that would never happen in open source!
b) Microsoft release a fix quickly - they must have known about it already and not told anyone!
c) MS product are a flaw in themselves, recursion not allowed.
d) They should have implemented CoyboyNeal
e) Crappy of options/all of the above
For the same reason that all email should be encrypted to the same level, you should shred everything, not just items that you consider condifential. Otherwise you're doing some of the work of the attacker for him, by sorting out the data into important and not-important.
When a dividend is announce, the share is regarded as cum-dividend, i.e. the shares also have the dividend right. On a predefined day, the shares go ex-div, which means that they no longer have the dividend right attached. The person who owns the share at close of play before they go ex-div is the person who is entitled to the dividend.
What I'm wondering is if I could make better profits from buying and selling at dividend time than the crappy 3% I get from the bank.
No, you won't, because on the day the shares go ex-div, they normally drop by the amount of the dividend, as prior to that you are paying for the share+dividend, afterwards you're just buying the share.
Rough example: if MS have 1B shares, worth $28 each (total market cap of $280B), and the dividend is $10B, then the market cap after the dividend is paid out will be rought $270B, so the shares are currently worth about $27, but you're paying the extra $1 for the dividend rights.
So, if you bought shares beforehand, you'd end up buying a $28 share, getting $1 income and selling the share for $27. Result, $1 income, $1 captial loss, which isn't the best tax situation to be in!
Not quite. According to the artists, they regard the complete album as the product, not individual tracks. If you accept that point of view, it's sounds like a reasonable request.
Make it a 4XX level delay, and include a comment about the temperature of hell being currenlty too high for you to accept any emails from them.
Actually it's 67%.
Jeez, it's the 10% of people like you that misquote statistics that cause all the problems for the other 95%.
No. The reply-to field is for directing replies to an address different from your own, not for indicating who sent the e-mail. Mailing list servers and private whitelists generally check against the From field
Hence why they have three fields:
Sender: Who posted the email - the foreign isp
From: Who sent the email, your home isp address
Reply to: who you want to reply to.
I regard the Sender/envelope address as a electronic postmark - if you post a letter abroad, you can put your own return address on it, but it will always have a foreign postmark.
I believe you'll find that's what Sender/From/Reply to address are there for. The envelope address is supposed to be an electronic equivalent of a postmark - on a real letter you can write any return address you like, but don't expect your home post office to stamp it with the university post office mark.
Anyone find it amusing to see a comment about job layoffs moderated "Redundant"?
I've proposed this idea before, not on the user level, but on the domain level. Every email that gets sent from say, example.com also has a hash key. When a enabled server receives this, it can check whether the key is correct, and if not reject it. This would be backwardly compatible, as the only case it would matter is if two enabled servers were talking to each other (all other cases are unchanged). It would also have the benefit of example.com's rep going up, as there would be no forged emails from that domain, and any spams that were received from that domain could be dealt with (I wonder how much ISP time is wasted by people complaining to the wrong ISP?)
There would be an enticement to hosters to upgrade, as their domain would then become "100% spam unforgable" and clients would see it as a plus as they could now trust those domains and not need to filter that domain.
If it became a situation where spammers couldn't use yahoo.com as a return addres, they'd change to a new one, and pressure would be on the new forged-from victim to upgrade.
A a previous poster said, this would also transfer the spam problem from a type 1 (forged headers) to all type 2 (relible headers), making it easier to track.
For those that say this would ruin smtp, and you need to set different from headers - that's what sender and reply to fields are for. Leave the envelope from header as a "postmark" and put whatever return address in the email itself you like.
So step one should be to be able to identify it correctly, so consider the following:
(Firstly, I assuming it is possible to add commands (like ESMTP) on top of SMTP that will be ignored by non aware servers, and hence be backwardly compatible.) Now, take company example.com
- Example.com has a DNS record (say type MXC) with its public key, and all emails sent from its servers include a dated confirmation key.
- A non aware smtp server receiving email this way from example.com (or anyone else) doesn't recognise the ESMTP command, and works as today.
- A MXC-aware server receiving email from a non-MXC-enabled server, also works as normal.
- However, a MXC-aware server that receives email from example.com domain can check whether it was really sent from example.com, and if not reject it.
From that one change, you can be assured that any mail with the envelope from address of example.com came from example.com, and example.com should deal harshly with valid complaints (as that should be the only type they receive). Result: No spam at all comes with example.com as the return address, example.com gets a good name. (considering the amount of people that do a wildcard refuse from certain domains, this should be popular with those providers.For those that say that this will ruin smtp, and you need to set from address differently, that's what the sender/reply-to headers are there for. Use the envelope-from address as the postmark, you can put whatever return address you like, so long as the postmark isn't forged.
Make spam easier and focused to complain about, and give companies a way to "look 100% clean" and competition and market forces should do the rest.
_That_ would be an antitrust suit that would sail through the courts.
IANAL, but I thinkI was taught that when one company tells you what other companies you _must_ do business with, it's much more clearly illegal (in the USA) than having market dominance.
Actually it's not hard to see how it could be done. If the processer requires a "secure" OS to run, this does not specify which one, or from whom, but it does set a minimum requirement, and if Linux is unable to meet this requirement e.g. because of licencing, then what could you do?
Just look at what happened with DVD's under Linux. Any disk with CSS on it will only be played with a player that understands CSS and has a key. If you don't have a key, you can't play it. With the DMCA et al, you can't write your own CSS app, and you have to licence it. Although with DVD's it could be possible to licence CSS and write a player under Linux, you wouldn't be able to release the player under the GPL.So, what happens if the equipment is more low level, and the "player" is the OS? With the same situation, you couldn't release the player (OS) under the GPL, ergo, linux can't support it.
So one of the requirements to be classed as a religion, is that it has 100% legal activities? Does this mean that if the governement outlaws one of those religious activities, then it might stop being a religion? Or would the government be unable to pass this law due to the constitution?
In either case, it could create difficulties, you could end up with the ability to outlaw certain religions, or alternatively, be unable to legistate against certain actions because they are part of a currently valid religion
It has to be in Scotland, of course, the only nation that can talk directly to modems, Ach, eeeeiiiieee....
We've just started authoring dvd's here at the office and I've recently found out that I can set different parts of the dvd to different region codes. Basically what this means is that if we build content for spain and we encode it for the spaniards' region, so they only see the spanish content, and we can also have a sperately encoded section (completely different content) for the USA in all english.
That's a bit of a pain for those Spanish people in the US, and those living in Spain who speak perfect english, isn't it?
This also enables us to specify content for different cultures, cause some people aren't down with the american way of life
And if you happen to be interested in a culture that's different to the one you're living in, you're out of luck, eh? Isn't learning about new cultures a good thing to do? Here's an idea: What about having all the content available to all regions, and let the user choose? Bit too radical, eh?
In the first paragraph of the summary say: "Go see this movie" or "Don't go see this movie".
You mean, "We know you were going to see this movie. We know you won't enjoy it. We're going to stop you before you go".
(One example of this is driving on roads, it's not "better" to drive on the right or left, so long as everyone drives on the _same_ side)
This addition allows the government to get the permission of the owner of the computer to listen in on what someone is saying.
And who do you think owns the equipment at your ISP? You or the ISP? With this addition could not the FBI get permission from the computer owner (the ISP), and read _your_ emails without the need for a warrent?
To place a tap, the FBI need to get a warrent, requiring a judge be convinced. With this addition, to place a tap, the FBI now just need to get the owners permission, requiring only the ISP to be convinced.
IMHO you're allowed to port a GPL project to another programming language, eg. C to Pascal. But what if you port it to Assembler?
Question: What happens if you port a GPL product from 'C' to language 'I' where 'I' is an internal, never released language. The source in now in 'I', which is the preferred source for editing, but no one else can actually compile it, because there is no available 'I' compiler'. What happens then? Are they required to release the source to 'I' as well?
Or what if your source contains scripts for internal tools, without which you can't compile the GPL code into the binary? Or if you have to use a certain compiler to get the exact binary as shipped. Would releasing a GPL program compiled with a non-free C compiler cause any issues?
Anyone care to guess?
And what happens if you are receiving an email from someone who has the same rules applied to their server?
Have a look at "man hosts.allow" and read the section under "booby traps" referring to infinite finger loops
Of course, spammers might start to make the return addresses random (but valid) return addresses at yahoo, etc.
You mean like spammers do already?
What about the following? This assumes that only yahoo.com sends out addresses with yahoo.com as the _envelope_ address (as opposed to having yahoo.com as the from/sender fields, which anyone should be able to do to set return addresses. In the latter case, but the envelope address should be your isp address in this case.)
...Welcome to server.isp.com. This mail service is brought to you today by the random number "rand_num" and the letter Q.
1) HELO Yahoo.com (date) (date-key+rand)
2) MAIL FROM: (user@yahoo.com)
(check_mail rule:
a)is date correct?
b)do we have yahoo.com's current (not expired) public mailkey?
b-1) No? query dns record type "MK" for yahoo.com)
c) Does record MK exist?
c-1) Yes. Is f(date-key, "yahoo.com", date, rand_num) = key?
c-1-1) yes? - accept.
c-1-2) No - reject.
c-2)Domain not verified, accept for backward compatiblty (current situation)
I think the above could be useful, as most solutions I've seen rely on the network effect of everyone switching over, and getting people to reject all non-verified address. however, the above would allow even one isp to change over (by adding a dns record) to say, "we've changed over, if you getunverified email "from" us, it's not - reject it. Result? Zero forged emails from isp, isp rep goes up. Other ISP's get interested. Keys can be expired periodicly where "key expiry time" < "time to crack key"
Comments? Is this currently possible with esmtp?
Emphasis mine. In other words, a "protected computer" is any computer on the internet worldwide. Every computer on the internet is "used in interstate communication", isn't it?
Defacing websites is not a terrorist act unless the computer belongs to one of the above categories
Can you list any web site that *doesn't* belong in the "protected computer" category as outlined above?
Also, that under this act it won't be "defacing a web site", with the overtones of "graffati", it will now be defined as "attacking a protected computer", with the overtones of "terrorism".
It's all about perception in the public eye, the ordinary person will hear "attacked a protected computer", gasp, and call for a severe punishment, even if he has no idea what the wrongdoing entailed.