> I think the facts that Gmail reads your incoming mail to choose which text ads it will show you is a very bad precedent.
The word reads is misleading. Google's computers will scan the message for keywords. No human is going around reading the mail, not even pieces deemed juicy by the scan (ignoring government-imposed requirements, as on any service's computers).
> Isn't it the first time someone offers a communication service and they tell you that they will know the content of every message you get?
"know the content"? -- They say they will store the mail on their servers. A mail system that stores actual mail text? It doesn't sound too outrageous to me.
But they will scan the text! -- Not the first time I've heard of this kind of thing. I think many mail systems these days actually scan the text of all mail messages under the guise of "detecting spam". I haven't heard such outcry about that.
A lot of people seem to be misapprehending some important aspects of how.mail
is to work. Probably the opaque language of the proposal document is at the
root.
Let's take some of those points:
OK,... this proposal would just boil down to keeping a list of...
trusted mailservers...
While true, the.mail proposal would make use the DNS service, which is
relatively secure, distributed, reliable, and fairly efficient. That helps
avoid problems with DOS attacks, which spammer-listing sites have suffered
from.
Also, it gives an immediately obvious and effective place to complain about
abuse. You just complain about foobar.com to abuse@foobar.com.mail, and the
arbiters at.mail get the message, not the perpetrators at foobar.com.
What happens when spam originates from a.mail address? Because it
will, if only from a virus-compromised machine. It seems the only recourse
would be the revocation of the.mail domain.
Yes, that's the penalty - if you allow spam to be sent from the mailserver you
promised to never send spam from, the mailservers for that domain will no
longer be publicized as being spam-free (because they're not).
And if so, what is to stop a spammer from signing up, sending off a
one-shot spam run, and losing the domain? It will just raise the cost of each
spam run by the cost of registering the.mail domain. That certainly might
*help* reduce spam, but it depends on the amount of spam they could send
through before losing the domain.
Several things slow the spammer down, if not stop him. First he must have
already owned the "key" domain (e.g. "foobar.com") for six months before he is
allowed to get the corresponding.mail domain ("foobar.com.mail"). Second,
the WHOIS info for both foobar's is investigated by the.mail organization for
validity (in several ways unclear to me). Third, the anti-spammers
controlling.mail may use measures like spam honeypots and being eagle-eyed to
make sure that $2000 doesn't get him much return. The economics of buying
throwaway.mail domains aren't likely to pay off.
I assume each ISP will have a.mail domain of the sort isp.com.mail,
and their customer's email will be routed through it. So what happens when a
customer of an ISP decides to spam?
They hedge some on whether ISPs will do this. They suggest the ISP will have
to have tight limits on the number of emails that can be sent by their
customers (at least through the ISP's trusted mailserver).
It is already known that there are a number of
less-than-entirely-responsible ISPs and even some that are explicitly
spam-friendly. For a sufficiently large organization, they could afford to go
through.mail domains at a fairly high rate.
The vetting of the WHOIS info is meant in part to make this difficult. You're
not going to get many.mail domains under the same or similar registrations.
I don't know the extent of the checking, but maybe a spammer would have to set
up a new front-person and address as well as domain every three days and
maintain each set for 6 months to get a pipeline of throwaway.mail domains.
That doesn't seem too likely, especially by a spam-friendly ISP.
The cost also seems to be a problem. It seems that this proposal can
ONLY work if the cost of the.mail domain is fairly high. It seems that the
cost will probably be somewhere between $200 and $2000. This seems prohibitive
for individuals, non-profits, and third-world orgs.
Yes, but I don't think anyone views this as the only way to send mail or fight
spam. You can always send without involving.mail; your message w
He suggests that you type "request catalog name address city state zip" into Google whereupon Google will kick back some 250,000 pages with online web forms to fill out.
A few extensions to SMTP clients could be the basis for a workable low-spam mail environment.
The basic idea is that an enhanced receiving mailbox requires that a payment token of adequate size be part of the mail message (or else it bounces it). There might be several forms of token, but the basic form would be an encrypted transfer authorization (specific to the receiver, not generally negotiable). This can be handed by the receiver to a clearing house, which credits her account (if valid). The mail can then be given to the human.
There are several things that could be done make the transition from existing SMTP to the new form reasonably smooth. The payment token might be a new kind of X-header line and/or a MIME type. The bounce might direct the sender to a web page which will ask for a simple (for a human) challenge, which correctly answered allows mail to go through (if non-monetary-payment mail is allowed by user option); likely the web site would then provide a "payment" token to attach to the message, or attach it and forward the mail itself.
It would be good if the user could have a white-list of senders whose mail will be accepted without the new payment token. The receiver might also set the level of the payment required for (non-white-listed) mail. If you're getting too much spam from DaimlerChrysler or whoever, up your threshold; at some point ($2, $3 per message?) your spam will dry up.
One main point is that you want sender-pays-receiver, not sender-pays-ISP, since the latter will likely cause _more_ spam in some situations, since it would then be economically attractive for ISPs to encourage spam.
I don't know if this Intel buying Alpha rumor has any truth to it, but it does make some sense.
Alpha is the only viable competitive 64-bit microprocessor architecture to IA-64 (maybe the last possible mass-produced alternative to Intel-based architectures of any width). It has been working for a long time and it will be a very long time before IA-64 can catch up with it, at least if Alpha remains reasonably well funded.
Intel would substantially consolidate the market and remove the largest visible threat to its dominance by taking over Alpha, whatever it did with it afterwards.
There's a nontrivial chance that the Justice Dept would quash the deal on anti-trust grounds, though. That's still not a bad outcome for Intel; just by going through the buyout motions it will weaken Alpha whether Alpha stays with Compaq or goes elsewhere.
The Justice Dept. probably does have an idea what outcome they'd like to see; they're just not letting us know what it is. And they won't get everything they want, even if the judge does agree with their main assertions.
Now what I'd like to see is to have MS broken up into 3 pieces, each with identical rights to their existing software. As with antitrust breakups generally, any large owner would have to dispose of ownership of all but one of the pieces within a certain time (you'll have to sell 2 of your children, Bill, but you'll have plenty of dollar Bills to wipe away the tears).
The outcome will get rid of the monopoly, and with three owners of the software, we'd actually see some innovation as well as competition in the marketplace. Three threads of OS (and app) extensions would be fewer than in the xnix arena, and the common base (Win as existing at the breakup) would be the target for development.
Slashdot Mirror
> I think the facts that Gmail reads your incoming mail to choose which text ads it will show you is a very bad precedent.
The word reads is misleading. Google's computers will scan the message for keywords. No human is going around reading the mail, not even pieces deemed juicy by the scan (ignoring government-imposed requirements, as on any service's computers).
> Isn't it the first time someone offers a communication service and they tell you that they will know the content of every message you get?
"know the content"? -- They say they will store the mail on their servers. A mail system that stores actual mail text? It doesn't sound too outrageous to me.
But they will scan the text! -- Not the first time I've heard of this kind of thing. I think many mail systems these days actually scan the text of all mail messages under the guise of "detecting spam". I haven't heard such outcry about that.
While true, the .mail proposal would make use the DNS service, which is
relatively secure, distributed, reliable, and fairly efficient. That helps
avoid problems with DOS attacks, which spammer-listing sites have suffered
from.
Also, it gives an immediately obvious and effective place to complain about abuse. You just complain about foobar.com to abuse@foobar.com.mail, and the arbiters at .mail get the message, not the perpetrators at foobar.com.
Yes, that's the penalty - if you allow spam to be sent from the mailserver you promised to never send spam from, the mailservers for that domain will no longer be publicized as being spam-free (because they're not).
Several things slow the spammer down, if not stop him. First he must have already owned the "key" domain (e.g. "foobar.com") for six months before he is allowed to get the corresponding .mail domain ("foobar.com.mail"). Second,
the WHOIS info for both foobar's is investigated by the .mail organization for
validity (in several ways unclear to me). Third, the anti-spammers
controlling .mail may use measures like spam honeypots and being eagle-eyed to
make sure that $2000 doesn't get him much return. The economics of buying
throwaway .mail domains aren't likely to pay off.
They hedge some on whether ISPs will do this. They suggest the ISP will have to have tight limits on the number of emails that can be sent by their customers (at least through the ISP's trusted mailserver).
The vetting of the WHOIS info is meant in part to make this difficult. You're not going to get many .mail domains under the same or similar registrations.
I don't know the extent of the checking, but maybe a spammer would have to set
up a new front-person and address as well as domain every three days and
maintain each set for 6 months to get a pipeline of throwaway .mail domains.
That doesn't seem too likely, especially by a spam-friendly ISP.
Yes, but I don't think anyone views this as the only way to send mail or fight spam. You can always send without involving .mail; your message w
He suggests that you type "request catalog name address city state zip" into Google whereupon Google will kick back some 250,000 pages with online web forms to fill out.
Google now kicks back one hit
- Try it without the quotes: about 256,000 hits.
A few extensions to SMTP clients could be the basis for a workable low-spam mail environment.
The basic idea is that an enhanced receiving mailbox requires that a payment token of adequate size be part of the mail message (or else it bounces it). There might be several forms of token, but the basic form would be an encrypted transfer authorization (specific to the receiver, not generally negotiable). This can be handed by the receiver to a clearing house, which credits her account (if valid). The mail can then be given to the human.
There are several things that could be done make the transition from existing SMTP to the new form reasonably smooth. The payment token might be a new kind of X-header line and/or a MIME type. The bounce might direct the sender to a web page which will ask for a simple (for a human) challenge, which correctly answered allows mail to go through (if non-monetary-payment mail is allowed by user option); likely the web site would then provide a "payment" token to attach to the message, or attach it and forward the mail itself.
It would be good if the user could have a white-list of senders whose mail will be accepted without the new payment token. The receiver might also set the level of the payment required for (non-white-listed) mail. If you're getting too much spam from DaimlerChrysler or whoever, up your threshold; at some point ($2, $3 per message?) your spam will dry up.
One main point is that you want sender-pays-receiver, not sender-pays-ISP, since the latter will likely cause _more_ spam in some situations, since it would then be economically attractive for ISPs to encourage spam.
>> My question is, why?
I don't know if this Intel buying Alpha rumor has any truth to it, but it does make some sense.
Alpha is the only viable competitive 64-bit microprocessor architecture to IA-64 (maybe the last possible mass-produced alternative to Intel-based architectures of any width). It has been working for a long time and it will be a very long time before IA-64 can catch up with it, at least if Alpha remains reasonably well funded.
Intel would substantially consolidate the market and remove the largest visible threat to its dominance by taking over Alpha, whatever it did with it afterwards.
There's a nontrivial chance that the Justice Dept would quash the deal on anti-trust grounds, though. That's still not a bad outcome for Intel; just by going through the buyout motions it will weaken Alpha whether Alpha stays with Compaq or goes elsewhere.
The Justice Dept. probably does have an idea what outcome they'd like to see; they're just not letting us know what it is. And they won't get everything they want, even if the judge does agree with their main assertions.
Now what I'd like to see is to have MS broken up into 3 pieces, each with identical rights to their existing software. As with antitrust breakups generally, any large owner would have to dispose of ownership of all but one of the pieces within a certain time (you'll have to sell 2 of your children, Bill, but you'll have plenty of dollar Bills to wipe away the tears).
The outcome will get rid of the monopoly, and with three owners of the software, we'd actually see some innovation as well as competition in the marketplace. Three threads of OS (and app) extensions would be fewer than in the xnix arena, and the common base (Win as existing at the breakup) would be the target for development.