I doubt that the increasing popularity of WebMail has much of anything to do with "voting with your checkbook".
I doubt anything would by your definition. To be straightforward: People who buy internet service from an ISP are generally buying it for the connection to the internet. The fact that it comes with email is nice, but it's not the central product. Most people would rather switch to a web based email service rather than stop using their ISP altogether.
That is the ONLY place where spam can be properly rejected. If a given
piece of mail traffic is *not* stopped there, there is little or
nothing more which can be done to combat it, because the lion's share
of the damage is already done as soon as the server issues the "250 OK"
message. At that point, there is nothing else for the server to do
except deliver it, or silently drop it on the floor (which is
problematic in a number of ways), or generate and issue an NDR (which
is usually a VERY bad idea, as this most often constitutes
"backscatter" spam -- which can get you blacklisted in a hurry).
Yeah, I've been saying all along that SMTP is broken, and that (preferably) a new protocol is badly needed. If you want to break your servers supporting a broken protocol, go ahead.
Simple... You have yet to show how such a "solution" could be workably implemented.
Depends on how much you care about man-in-the-middle attacks, and whether you are comfortable with a web of trust. Skype uses encryption extensively, and the user never knows about it. Wireless routers use a key that is typed once and never needs to be bothered with after that.
The simplest system is to establish a connection using encryption based on an asymmetric key, perform a key exchange for symmetric encryption, and send the email with a digital signature attached. There are stronger solutions involving certificates and webs of trust as well.
The "Bottom Line" here is, no client-side "solution" is or can ever be
a *real* solution, simply because it comes too late in the
mail-delivery process.
Whether the server drops the email or the client does, the spammer never gets money from emails that never reach their destination. If you really, honestly want a server side solution, you'll create a new protocol that works better and start introducing it into servers.
If you don't want a server side solution, then don't whine if I come up with solutions that don't involve the server.
What does it matter if you, as an individual end-user, can determine with 100% accuracy that a given message which has already been delivered to your inbox is or is not actually from whomever it purports to be from?
I most certainly would not place an email that has failed a digital signature test into a client side inbox.
Yes, there is some processing that clients generally do after the server stuff is finished and before it appears on the user's screen under their inbox icon. The server side inbox is not necessarily the same as the client side inbox.
*I* am not making that requirement; it is simply a fact of life
given the way internet e-mail works -- a process which, frankly, I am
becoming ever-more convinced you simply do not understand.
What I understand is that the entire email system is currently running on SMTP, a protocol that did not anticipate the spam problem and continues to struggle with it to this very day.
The root of the problem is that spammers send spam (cue reference to "The Scorpion and the Frog"
http://allaboutfrogs.org/stories/scorpion.html).
Whether or not they properly identify themselves in the process (some
do, some don't) is merely a side issue -- and one which doesn't even
apply much of the time.
Problem is, we can't even tell if it's a scorpion. We can't even tell if it has venom. Will there be some people who are frogs, who carry scorpions despite the danger? Sure. But why should we punish everybody just because there are a few frogs?
But *your* idea of "unwanted" mail may or may not be the same thing as
my idea of "unwanted" mail or the next guy's idea of "unwanted" mail.
Precisely. This is one of the areas where it makes sense to give the user control over their own filtering and do some things client side.
But per your comments, it's a "problem" of purely your own invention,
and of importance solely to you. See what happens when you ignore
prior art?
"Those who cannot learn from history are doomed to repeat it."
-- George Santayana, 1863-1952
I'm sorry - did I ever deny that other people were getting spam? I know that this is not a new problem. If you want to talk about people not learning from history - look at those who have been running SMTP servers repeating the same failed "solutions."
How utterly presumptuous of you. You not only ignore what I've already
said about this, you go on to claim my motives are somehow suspect
simply because *you* don't understand how e-mail works! In point of
fact, *every* e-mail user (save those who use *only* web-based "front
ends" such as Yahoo Mail for example) not only "have access to" SMTP,
they use it every time they send a message!
It's about time they used something else IMHO. Yes, clients would have to implement a new protocol if we created one. Yes, initial support for it will probably be on shaky ground. Yes, we'll have a time of transition. Yes there are some logistics problems to overcome.
So now you're proposing the wholesale abandonment of SMTP -- one of
*the* most ubiquitous, long-standing and well-entrenched communications
protocols extant, developed and refined over *literally* decades, and
in use at millions of sites world-wide which depend on it for serious
day-to-day operations -- in favor of some as-yet-undefined (and thus of
completely unknown value) replacement.
Yes, it is very well-entrenched, and will be very difficult to replace. I'm not seeing any major "development of refinement." Certainly not much that is helping our spam situation. No, I do not have a new protocol all written out. I'm just throwing around some ideas.
I suppose I could work on an implementation, but I'd have to get a lot of resources together and for all practical purposes give up on my college education for such a large scale project. I'd have to pretty much do what David Harris does with Pmail: Make it my entire life.
Define *exactly* what you mean by "piggyback" and "end to end protocol".
Encrypt it before it even touches the SMTP envelope, and wrap it in the envelope. Basically, attach a file that is encrypted and signed. Which is possible now, but not really integrated into email clients.
In the headers, you can exchange information not visible to the user: That information can include a flag that says "I support encrypted/signed attachments." If one client detects that another supports it, it can make a note of it. Now let's say the user wants to send an email to a person that the email client knows supports it. It attaches the encrypted/signed file and sends it. The other client, which supports it, can reverse the process. The email can use that to make a list of verified senders.
Now let's say that eBay starts using this. The users of eBay that have a compatible client can receive a visual confirmation of the signature, verifying the authenticity of the email and the sender.
Now let's say a phisher sends emails out to somebody with the client and pretends to be eBay. They can do one of two things: They can send an email with no digital signature, or they can send an email with a false digital signature. Either way, they client can positively say that it was not sent from eBay, because it doesn't have eBay's signature on it. This could really hurt phishing.
Then consider what it takes to get *any* standard (or modification to
an existing standard) codified and published even as "Internet-Draft"
status, let alone a "Proposed Standard" (see RFC 2026 for some hints).
HTML existed ten years before the W3C even existed to standardize it, and I'd wager that most other protocols are the same: The protocol is established before, not after, it is standardized. If some company stops by and standardizes the new protocol, great! But I wouldn't stop developing a protocol simply because standards for it don't exist yet.
By the time ANY client-side "spam solution" has a chance to do
*anything*, it's already too late, for the spam has already been
delivered -- which is precisely the thing we're trying to stop.
Good luck on trying to stop spam from being delivered. Remember that frog story you told me? It's the nature of spammers to deliver spam. Client side solutions may place more burden on the servers, but that may be the price we have to pay.
then there is some "Transaction Level Expression" filtering against
some of the SMTP headers; then there is an active virus scan to which
ALL incoming mail is subjected; and finally, there are a small handful
of Global Filtering Rules which any incoming message must NOT trip in
order to be delivered.
Cryptographic hashes (such as MD5) can be used to verify the integrity of the headers. Digital signatures can be used to detect tampering with them and ensure the identity of the sender. Same can be done with the entire envelope. DomainKeys already does some of this stuff, if I remember correctly.
but given that you apparently proposed the complete abandonment of SMTP
as we know it, that certainly seems "mutually exclusive" to me.
I'm saying that IF you don't what I've already discussed, then there are other options. Would I prefer something completely new? Yes. That does not mean, however, that I am saying that a hybrid solution is impossible.
How is that different from the current situation?
Other than the fact that the current situation has almost nothing in the way of verifying senders?
Since crypto-signing has not, even after all this time, achieved wide
adoption, it is useless as a determinant of the "legitimacy" of
incoming mail, simply because the vast majority of legitimate mail does
NOT carry such a signature.
Yes, adoption is an issue. I prefer to see it as a challenge to overcome rather than an unsurmountable obstacle. We didn't become a technologically advanced society by giving up every time we see a problem. Obviously with SPF and DomainKeys not catching on, there is a lot of work to be done in encouraging widespread deployment of this stuff. I'd prefer not to give up, though. I'd rather look for a solution to the adoption problem.
Not really. The page you cite shows that those low-cost keys are
ONLY "for personal use" -- which leaves out the vast majority of e-mail
senders.
Thanks for not seeing the forest though the trees. Who says it has to stay that way forever?
"Some complexity"?!? Try, "It would require rewriting every MUA and MTA in common use."
Most of them were fine implementing SPF and DomainKeys. Sendmail adopted them pretty quickly. I thought getting ISPs to use the new MUAs/MTAs was problematic?
You want them all to understand enough about cryptography to actually make effective use of this "feature"
Heavens, no! Do all the crypto stuff in the background, and do what browsers do: Display a lock, or green or red on the screen, or something else that is user friendly. I'm certainly not advocating exposing the users to the raw crypto stuff.
The reality is that *most* "home user" PCs are hung DIRECTLY off either
dial-up lines or raw residential broadband connections, with NO
intervening "firewall".
Well, that's slowly changing. I'm talking to more and more people with routers, and the DSL modem I got from my ISP has a built in firewall. There may be some discussion about what the exact percentages are, but I'm certain that the number of home users with hardware routers/firewalls is growing, and will continue to grow in the foreseeable future. Cisco has an entire division aimed at creating network products for home users - Linksys.
What *has* been said is that attempting to mail direct-->MX from dynamic or generic-reverse-DNS IP space . . .
Remind me again: How much would it cost to get me a static IP address? You think this is available to every average joe? Would the average joe even know where to start with all of this stuff we're talking about??? You may not have said it directly, but that's basically what the result is. Very few people would have the finances or knowledge of networking to even try something like this.
You're dreaming again. There is no way that a fixed *software* routine
built into the ROM of a generic consumer-grade router could possibly
distinguish between legitimate and illegitimate mail traffic, let alone
do so without seriously disrupting the legitimate use of the
connection. It's not even looking at the traffic at that level. You
obviously need to bone up on the OSI Model (cf.
http://en.wikipedia.org/wiki/OSI_model).
You're right, a hardware router has no idea what happens in its own firmware, and it would be silly of me to think that Cisco has experience designing devices that work at the lower layers of the OSI model.
Surely you are joking.
FYI, it's not "fixed" software, it's got plenty of flexibility. And being software might mean it may not be fast enough for a large corporate network - but it's plenty fast enough for a small home network, which probably has only one or two computers on it.
Here are some of the features of our DSL modem at home, given to us by our ISP:
- DHCP
- Dynamic/Static routing
- Port forwarding
- Firewall
- NAT
- QoS
- Website blocking
I dunno about you, but the ability to block certain websites indicates it can do some sort of packet inspection, and that it's not just handing around packets blindly.