Slashdot Mirror
IETF Approves SPF and Sender-ID
NW writes "According to the records in the IETF's database (here and here), both the SPF and Sender-ID anti-spam proposals were tentatively approved by the IESG (the approval board of the IETF) as experimental standards. It remains to be seen whether any of them will actually put a dent into spam." At the same time, the FTC has opened a central site about email authentication.
But this will help me out tremendously.
Not getting joe jobbed will be a huge step forward. Not to say that everyone's going to instantly adopt these standards but it won't hurt that these are Official now.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
Before the rush of posts about how this won't do anything about spam, this is not about spam. This is about stopping spammers from using your address which results in your email servers dealing with the mass of bounces and spam reports from clueless admins.
...
Of course, only the admins with a clue will correctly implement either of these so
It'll definatley be a nice step in the right direction. I think it promises to be one of those long/gradual changes that eventually will be all the way in place but it will take time. I'm likin it in any case...
I thought the IETF had already rejected Sender-ID because it was MS proprietary.
What's to stop the spammers from using a zombie to fake the sender id? It's a good step forward (you would know where the zombie was), but the bigger challenge would be to have some kind of capability to restrict mail servers to authenticated ones rather than some kind of recipient call-back mechanism. Otherwise the future of email will be "sender ID from mail server ZOMBIE294346.earthlink.net"
"Scientists don't change their minds, they just die." -- Max Planck
It's all well and good that something is being attempted to alleviate spam in this manner, but I think a much bigger problem that needs to be addressed is ISP's selling your email address before you even log in the first time to check your mail. *Cough*Cox*Cough*. I've had 3 seperate email addresses (from 3 seperate accounts) with Cox and each one filled up with junk mail without me giving anyone the email address.
The best thing I have come across so far is Incredimail, but even that is a pain in the ass to right click each spam and choose block sender or bounce to sender. What Incredimail needs to do is come up with an automatically updated block list for known spam. It would help greatly.
In the end, I think that spammers should be beaten, shot, stabbed, hanged, drawn and quartered, eviscerated, castrated, tortured, set ablaze, and be kicked in the shin.
Halitosis - (n.) Halle Berry's Camel Toe.
I dunno, but hasn't this failed with caller ID?
Not at all. If I get a phone call and the CallerID says "unavailable", "out of area" or "private" then I don't even bother to answer it.
If my incoming e-mail doesn't have SPF headers then it bumps up the scores in SpamAssassin. If the score gets too high then the e-mail gets filtered & I never see it.
Hmm... Microsoft announces hotmail will be restricted to user-ID and now it's been passed as an experimental phase. Coincedince? I think not.
Live life to the fullest. It's not that life is short, but that you are dead for so long.
Whey aren't we hearing from the Big Pipes? They should be opposed to the widespread implementation of anti-spam techniques. Indeed, their main financial focus is on the usage of bandwidth. Spam consumes massive amounts of their commodity. They should be against any proposals that will decrease bandwidth usage, as it will hurt their financial bottom line.
Cyric Zndovzny at your service.
"Bounce to sender", what a dumbass feature. You (and Incredimail) don't KNOW who the sender is. That option should be "forward this email to some random person who probably has nothing to do with sending spam".
Example from ASF
Only because caller ID allows telemarketers and the like to come up as UNAVAILABLE. If they had to show an actual number where, when you dial it back, you get a person (probably at his or her home), caller ID would succeed wonderfully. Those telemarketers would receive plenty of callbacks when they're trying to sleep, eat, or might otherwise be involved in some kind of recreational activity. The phone company claims it's because they're behind their own PBX and don't transmit caller ID data. Well, they should at least know who owns the PBX, and could give you a main number for that company, saying that anything coming from there shows up as TELEMRKT CO 555-555-1212.
Someone will figure out a way to get some string past the Sender ID check (or most checks, for that matter). All that use of something like this will do is slow down the spammers for a short while. They'll figure out ways around it.
OCO is Loco
within a couple weeks at most the spammers will find another way arround it as they have everything else.
Do you even understand how SPF works? It sure sounds like you don't. It's meant to prevent spammers from forging domains, not to put an end to all spam. If you own your own domain then something like SPF can be a HUGE help if your domain name is used to forge spam.
Both SPF and Sender-ID solve only one problem: faked sender domains.
;) We can dream.
That's a problem that needs to be solved, but it doesn't account for a lot of spam, and spammers will just stop faking domains in their mass emails.
What we need, and what will NEVER happen, is a central database of mailservers. If you aren't in the "registry" of legit mailservers, then other mailservers won't accept your mail. To get in the registry, you'd have to pay a fee, and prove that your server are secure, and that you aren't a spammer. Obviously, each "legit" server would have to append some kind of digital signature to outgoing emails, so that the verification coudl take place.
In other words, a total revamp of the mail system protocols.
I'd personally love to see the Apache Project coordinate and release a mail server. Considering their expertise in such matters, forming such a project should be well within their means, and the results would be fantastic! Indeed, combining the quality of Apache httpd with the innovation of their other projects, and there would be a winning combination. They could probably even muster up the talent to combat spam in a sensible, community-friendly way.
Cyric Zndovzny at your service.
There is no such thing as an "experimental standard". The term "experimental" is a "non-standards track maturity level".
See "The Internet Standards Process":
The IETF has NOT approved either SPF or Sender-ID as an Internet Standard.
Show me on the doll where his noodly appendage touched you.
Since SPF doesn't even claim to be a method of reducing spam, why would anything think it would?
As it happens, a couple of my bosses have been having email rejected recently by the receiver's ISP because we are SPF compliant.
SPF breaks email forwarding, and most mailing lists. It's a bad idea, poorly conceieved, and poorly implemented.
No matter what we do, SPF will cause some of our email to be rejected.
That is a way to help spammers, not hinder them.
Of course we will never see a central database of mailservers. That has been proposed before, but will always be unsuitable for the Internet. Remember, the Internet is meant to be decentralized. And a centralized database is open to abuse by governments, corporations, and whoever runs it (or provides the funding for it).
There's nothing to stop spammers from infiltrating such a system, via legitimate and illegitmate means. So it just plain won't work.
Between the fact that it is easy to abuse, it just won't work and it won't provide any benefits over existing systems, your system is just a bad idea (no personal offense meant, of course).
Cyric Zndovzny at your service.
Is M$ still asserting patent claims over either or both?
Disinfect the GNU General Public Virus!
Spam = Death penalty.. back to being primitive baby!
www.brido.com : not your average blog..
I honor spf entries on my mail server. It stops about 1000 emails/day. So far no legit mail being bounced.
you obiously have no practical experience...
putting up SPF records has not made any noticable difference in the spam abuse from one of my domains.
obviously, spammers do not (yet) check of a domain they use for joejobs has an SPF listing. this means that little or no receivers are bouncing the spam because of SPF.
Is there anything in particular that made that clear to you?
Education is the silver bullet.
I'm not going to say you're a moron, but how do you allow for legitimate unsolicited email from people?
Currently I receive lots of unsolicited mails from people that I want to hear from. Let's call these people "customers".
Your scheme would have me polling only people I have already talked to.
John.
I've only had the pleasure of one telemarketer bold enough to get through that and my "no solicitation warning". After I got them to give me their information I informed them that my number is on the Fed/State do not call list and I reported them.
It has only happened once. My phone is now forever dead quiet unless it is someone I actually want to talk to.
Let's place the blame where it is due. If the recipient's ISPs are rejecting your bosses' mail on the basis of SPF records (as you claim), it means your boss is sending mail through a SMTP server which is not authorized by the SPF records you have published.
Which means your bosses' machines are misconfigured. It's lame to try to lay the blame for that on SPF, which, while imperfect, should never lead to cases like this.
You challenge them with a response before allowing the email into your inbox.
No really, that's all I wanted to say.
...because "hacker" sounds way sexier than "code drone."
That's right, I can't. Because I have no fucking idea what IP or domain name my email is going to be coming from when I send it, and Verizon can change it anyhow.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
I thought the IETF wouldn't approve patented specs as standards. This MS move to take over the Internet must come bundled with some pretty good checks to "the right people".
--
make install -not war
I must admit, this would be a really great idea if you would like to solve spam problem in the days of ARPANET, when you could count domains on your fingers.
Nowadays??? Just how do you figure you as admin can tell all the servers you're pulling mail from (I seriously hope you didn't think of *). I guess you're either type very fast or you still live on the ARPANET.
p.s. Doesn't matter that I don't agree with you. SPF still sucks.
Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
Re-read my post. :)
:)
Specifically the parts that said that we have two types of email, and where I said that 1) we have what we have today.
In other words, I'm not proposing a replacement for current email - just an additional system with improved trust.
Maybe two parallel systems is unworkable, but I don't think so.
On the other hand, if you've already established communications with someone, you can just use public key cryptography to verify their emails... So, yeah... My idea is probably pretty pointless.
Education is the silver bullet.
In what way is this an improvement over using a client-side whitelist with today's email?
1. Personally maintaining that contact list will be really annoying. Even I, a card-carrying slashdot geek, have enough email correspondants to make that prohibitive.
2. People don't necessarily always use the same email address. Any time someone changes, uses a different address, or whatever, you have to update your polling list.
3. You've just exponentially raised network traffic: everyone polling everyone else for messages? Eek.
4. As JGC pointed out, no unsolicited mail. (I don't consider challenge/response a solution to that, either: I like it when people send me kudos, but they're unlikely to bother if I make it annoying.) If you're thinking of using today-style email for the unsolicited, then you've just hurt the signal-to-noise ratio even more.
5. Something will be maintaining a large database of legitimate email addresses, with trusted relationships -- how long before those databases are themselves exploited and we're back to square one?
That's all I can do off the top of my head.
What I say does not represent the views of my employers, my friends, my cats, or myself.
*shrug*
Polling them would hardly take any time at all.
Thanks for the response. But I should probably just officially retract my idea from discussion - since public key cryptography does all that I want and more... it's just a question of getting my non-nerd friends to use it.
Education is the silver bullet.
The big difference is that you don't poll known addresses. You poll when an event is sent from the sender.
There are other differences, take a look.
My goals were slightly different:
There is ample documentation available. Try this if you've got a PDF viewer.
http://spf.pobox.com/faq.html#whichfield
So, this is implementation specific, but it seems that it will compare published SPF record of the domain in the FROM: or the return path with the fully qualified domain name of the sending machine (zombie123.earthlink.net yields "earthlink.net").
So, if the incoming email claims to be from/return-path taco@slashdot.org and slashdot.org publishes an SPF record, that SPF record had better list zombie123.earthlink.net as a legitimate mail server or it will fail.
What, specifically, happens when it fails is also up to the implementation.
The problem appears when taco@slashdot._org sends an email to my old college which offers forwarding services for alumni.
taco@slashdot._org sends to khasim@example._com
mail.example._com forwards that message to my gmail account.
mail.gmail._com checks the From:/return of slashdot._org and checks their SPF record for slashdot._org.
slashdot._org does not list any example._org boxes as a mail server so the message fails the SPF check.
Again, what happens at this point depends upon the implementation of SPF that is being used. It can range from increasing the SpamAssassin score to dropping the connection attempt.
Yup. I'm going to once again say that my idea is worse than public key cryptography.
:)
3. I responded to this - the sender sends two emails - one a "I've got an email for you" through normal means, and a "trusted email" is kept on the sender side. *shrug* Public key crypto is still better than my idea.
4. I don't see how I've *harmed* the signal to noise ratio, but I guess I agree that I haven't improved it for people who routinely accept unsolicited email.
Meh. Like all lame ideas, they seem really great to the inventor until the fourth person correctly points out that they were being an idiot. Thanks.
Education is the silver bullet.
The Internet was designed such that every endpoint was a valid one. When you require 'authentication' at the server level for the right to be a valid end point (which is what this is) then you are saying that certain endpoints are more valid than others.
That is not the Internet.
There are far simpler ways to lessen our problems with spam that don't damage the basic relational nature of the medium.
I should not be required to be validated by a third party to send mail...regardless of the spam problem.
-Tom
It doesn't hurt to try. If we sit and say spammers will find a way around it everytime some new antispam idea comes out, the spammers will prevail. At least it will drive some spam away.. if not much of it. I don't really care which anstispam technology is going to be used but at least something needs to get implemented and overtime it's going to get imrpoved and better. Nothing starts as perfect the very first time.
-- http://www.dotnet-hosting.com
Free web hosting. Includes asp.net, php, mysql & sql server.
Thanks for the responses, people.
:) Just realized that. I keep checking Slashdot for new articles (or messages), and noticed that Slashdot is acting as my trusted server. I would trust it more, if it were controlled by one of my friends directly... Maybe... :)
But before you burn me in effigy, consider that the system that I just described is basically an RSS feed on my Slashdot mail.
Education is the silver bullet.
That's a problem that needs to be solved, but it doesn't account for a lot of spam, and spammers will just stop faking domains in their mass emails.
Admittedly I don't get a lot of spam by most people's measures, but all the spam I get uses at least some form of impersonation.
-- No matter how great your triumphs or how tragic your defeats, approximately one billion Chinese couldn't care less.
So, at my company users like to send company email from home. If they use Cox, for instance, they use their SMTP servers, as everything else is blocked. They send out an email from my domain from Cox. Someone with SPF checks the registry and finds that Cox is not me, bounces the email. Is this the standard result of SPF? Is the solution to run SMTP servers on random unblocked ports for your users and teach them how to send email through them? Does anyone else find this to be a pain? Am I missing some piece?
I thought the IETF wouldn't approve patented specs [zdnet.com] as standards. This MS move to take over the Internet must come bundled with some pretty good checks to "the right people".
They're not checks, they're stock options.
-- Tigger warning: This post may contain tiggers! --
After the Hotmail announcement the other day, I went poking through the SPF and Sender-ID specs to figure out how I could gain the benefits of SPF without rewarding Microsoft for their attempt to subvert the specification and lock out OSS implementations during the original standards discussion. Their behavior was especially nefarious considering the duplicitous and underhanded way they tried inject the patented PRA algorithm into the standard with a serious of slippery half-truths.
For those of you wanting to thumb your nose at MS and their attempt to "embrace, extend and extinguish" the open source MTA's, you have a couple of options.
1) Only mildly breaking RFC2821, you can add the header
Resent-Sender: goaway@microsoft.com
to all of your outgoing mail. This shouldn't have any detrimental effect on MTA's not implementing the PRA algorithm, but will certainly cause any that do to think your email is coming from a "bad-guy".
2) Add the SPF classic records to your DNS and add a "drop all" record for Sender-ID:
"spf2.0/pra -all"
If you want to be more specific, you can change that to "spf2.0/pra,mfrom -all" to drop everything from any MTA/MUA implementing the Sender-ID specification using either the PRA algorithm or MAIL FROM. I wouldn't recommend doing that, however.
Note that any of these steps will possibly prevent your email from being delivered through weak-willed MTAs (but that's kind of the point...).
Let's hope that there's intelligent life somewhere out in space 'Cause there's bugger-all down here on Earth.
They're late. It's already standardized.
What Smallpond says bears repeating --
when reporting spam to anyone but your own ISP (and even them if you are one of certain large ISPs), use a throw-away account.
SPAMbots use their own servers. They can make their own envelopes.
Until we can afford the processor and network time to put a certificate in every item in the envelope, and the processor/network load to look every certificate up, this only pushes the problems back a few weeks.
IETF: Internet Engineering Task Force
They're the people who maintain the RFC's (Request for Comments) that are the basis for the protocols used on the internet. These include the protocols used for packet transmission, email, telnet, ftp, etc.
Basically, they're similar in purpose to the W3C or the X consortium, except instead of document formats or windowing systems they maintain standards for networking.
Now that you know this, you can google for any other related questions you have.
Those who can't do, teach. Those who can't teach either, do tech support.
I believe he was referring to email from friends and whatnot. Of course business-related email should always get through. But it would be nice if my personal account that's just for email from my friends wasn't full of Viagra spam.
I guess you didn't hear, caller ID can be completely spoofed now. They can put your mother's number on your caller ID. http://www.securityfocus.com/news/9822
.
Arrest the fuckers. Throw Scott Richter in jail for a decade or two for fraud and theft. Break the back of the organised crime syndicates that are profiting. Revoke FDIC/CDIC approval for banks who benefit from mortgage spam. Have the CEOs of explicitly supportive ISPs (MCI, for instance) arrested and fined tens of millions of dollars. Threaten economic sanctions against countries who don't take reasonable action.
Like most crime, the laws exist to stop the small criminals, and have no ability to nail the true sources. Technology is always used to try to fix this problem, and always fails.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
It's a common misconception, that SPF isn't about fighting spam. It is. This is how it works:
SPF is meant to work with other mechanisms. A DNS blacklist is obvious, but internal whitelists are even more obvious. If SPF is used with greylisting, blacklists and bayesian filters, then this is how it can work for specific e-mails:
E-mails from well-known e-mail addresses, that are known not to send spam, are usually automatic whitelisted. If the e-mails are sent from the correct mailservers, they just pass through the entire spamfiltering system. If they are sent from a forged server, they are rejected as part of the SMTP session and never even enter the mailserver.
E-mails from people we don't know, but have SPF records, work like this: If the mailserver is forged, the mail is rejected immediately and doesn't enter the mailserver. If the mailserver is OK, first time they try to deliver the e-mail, the greylisting system activates and delays the delivery. Second time they try to deliver, the sending mailserver and e-mail address is looked up in blacklisting services. If the system is still OK, a bayesian filter is applied. If the e-mail is still OK, it's delivered.
If the e-mail is from a sender that doesn't have SPF at all, greylisting and bayesian filtering is applied as usual, but with greatly increased risk of being marked as spam. Some mailservers may even reject the e-mail immediately because of lack of SPF record.
As you can see, the SPF record is about getting your e-mails through spamfilters. System administrators will experience less load, because the automatic whitelisting in combination with SPF records makes most e-mails pass without running bayesian filtering.
Very obvious domains to whitelist are your own. If you have two or more domains, the mailservers for these should whitelist each other, making all e-mails pass. Since you want to be able to change, which servers you use, SPF records are a good way of communicating to these mailservers, which other mailservers they should trust.
I need to provide a few comments:
- Bad SPF records should be considered as not being there at all. For instance "v=spf1 all" would enable all mailservers in the world, and should therefore be ignored.
- Most spamfighting techniques just put the e-mail into a spam folder. The sender does not know, that the e-mail didn't arrive in the inbox, and that's bad. With SPF, it is much more likely that a non-spammer gets his/her e-mail delivered or bounced because it isn't able to deliver it via smtp to the receiver (misconfiguration).
As long as we want to receive e-mails from people we haven't communicated with before, spam (unwanted e-mails) will exist. SPF just makes it a lot easier to filter them out.
Lars.
What we need to do the SPF thing is a checksum/messageID whatever in every checksum, and then a sender mailserver to contact to verify it has been sent from there. This will allow mail forwarding.
Fighting spam should first be done at the gate, by the receiving mail server. To facilitate that, SMTP should be extended, to create a non-bulk variant of the standard.
This requires a few extensions to SMTP, so that the receiving mail server is allowed to
- limit the number of recipients per message
- limit, per IP-nr and subnet, the total number of messages and recipients per time window (like 24 hours)
- limit the number of concurrent connections, per IP-nr and subnet
- communicate these limits, and the current quota for the specific client, at the initiation phase
Of course, current SMTP implementations can already impose such limits, by rejecting to process the message, like with a 554-reply.> What it WILL do is keep spammers from imitating ...
> existing domains in their "from" headers
It will not and it cannot. It can only stop forging "Sender" headers (Sender-ID) or envelope-from (SPF). The "From" header that is shown to the user of any email client can still be anything,
> Anyone with an SPF record of "every sender is OK"
> probably should be blocked as a probable spammer.
And that is where the current email system starts breaking. You're telling people how to use their eamil. WHere do you stop? What you describe is a system to force people to change their systems. Many would have to change their software or hardware to achieve that, and there's lot of money to be made. That's what MS wants...
> mail.gmail._com checks the From:/return of
> slashdot._org and checks their SPF record
> for slashdot._org
Actually they do not. Neither SPF nor SenderID check the "from" header. SenderID checks the "sender" header and they require forwarders to add/rewrite this header (or use one of the "resent" headers). SPF checks the SMTP envelope from and they expect forwarders to produce one in their own domain and arrange for relaying relayed mail/error messages. The "From" header can be anything. Forwarders complying would get through. So will phishers, using exactly the same methods.
I can answer you this one without a hassle:) ...but as my idea stands, it would definitely work for me - I only have a few hundred people that I repeatedly get email from - only a dozen or so that I particularly care about.
I admit. If you look at this problem from your side as being one user solution could be looking good. Wait a minute.... NOT
I'm admining about 50 servers, few are companies betweeen 30-200 people. And one of my servers has about 5000+ users.
How could I know which and how many people do my customers care about. It could endanger my place in bussines if I would restrict them from being able to send or receive mail.
And better, how do you plan to administer this? Everybody should call their admin when adding new address in their address book???? You can't say that mail software should contact your account on server and update it. Many of my customers use Outlook, and so far I don't know how to patch outlook.
Polling them would hardly take any time at all.
Yep, for your 10 people, not. but my 5000+ with god knows how many people? Yes, very much. Bandwith can be used in a better way than herrasing other servers:)
Thanks for the response. But I should probably just officially retract my idea from discussion - since public key cryptography does all that I want and more... it's just a question of getting my non-nerd friends to use it.
Exactly like that.
Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
Even on my cell phone, I get some calls that are reported as not having an ID, but those are either friends who have something weird about their phone lines (VoIP stuff, sometimes), or are companies I already deal with calling me back about something I sent in an inquiry about.
OCO is Loco
This article advocates a
( ) technical ( ) legislative ( ) market-based (x) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(x) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
(x) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
(x) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
(x) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
(x) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
(x) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(x) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
If they ask for a specific person, just say "No i'm sorry they're dead".
Wow, you certainly wrote a lot. Too bad you didn't read what I wrote.
First, I said that there would be two email systems - the one we currently have, and this new one I'm talking about - so no one is trying to restrict them from being able to send or receive mail.
How do I plan to administer this? You don't think computers can talk to each other? Jeez - what, are you trying to invent problems where none exist?
And finally, I want to point out how it is that I got your reply on Slashdot. I got it as a message that was held for me, by proxy, by a server on your behalf. When I decided that I wanted to check my more trusted email, I logged on to Slashdot, and bam - there it was. What I'm proposing would basically be the same thing as if I had an RSS feed to my Slashdot email, and instead of it being your Slashdot email proxy that I would check, it would be (for instance) your ISP who was holding my email for me on your behalf. That is, if you were someone that I regularly communicated with, and I wanted a slightly better way to ensure that email exchanges with you were slightly more trusted, and also less prone to the lossy nature of our current email system. Take a chill-pill.
Thanks for responding, but geez - you sure had an attitude about it.
And once again, I think public key cryptography is a better approach to guarantee (as much as is possible) the trust relationship - but email is still lossy.
Education is the silver bullet.
My main address is 95% spam. But I've had it since before the telcos even coined the DSL acronym. I don't want to stop using it! I just want the spam to go away.
But since Sender ID, I _still_ receive ever more spam but now I can't send email to, among others, my wife AND come November, I won't be able to email any of the poor souls using Hotmail.
I *will not* use the email address my DSL provider's assigned me. Their mail server has 1/10 the reliability of my regular address.
Sender ID (in my experience) hampers spammers NOT ONE IOTA but it jerks me around. A LOT!
Don't jerk me around; execute spammers!
But that won't happen. They won't even slap their wrists hard.
I'll just stop using the net at the end of the year. It'll just be too useless to bother with by then.
Astro