Yeah, I never understood the appeal of Ubuntu and am diehard Fedora. The sudo business was very odd to me. You can run a command as root by using "sudo", but you enter your *own password? What gives? Since when is sudo an Ubuntu thing? I've never used Ubuntu or Fedora and I use sudo every day. It even comes on my Mac by default.
I think this type of system will again simply cause the spammers to look for alternate delivery systems, i.e. as more ISPs take a tougher line against spam, more and more spammers will start to take extreme measures to propagate their product.
That may actually happen. It's human nature.
My goal in writing AMTP was simply to provide a way to protect email. I love email, I've been using it for 20+ years. It's becoming unwieldy for me to wade through hundereds, and sometimes thousands, of UBE messages in my inbox every day. I just want to solve that problem.
So cable modem users with big bandwidth and vulnerable machines will be used to send the spam. The spammer uses a worm to find vulnerable machines and piggybacks the users connection and sends the spam, it still goes through the ISP's mail server and so will get validated and delivered.
Today that is possible, with AMTP it will be far more difficult. Today, a machine can look up an MX record and connect to the associated SMTP server and will (usually) get a message delivered. With AMTP that message won't be accepted unless several conditions are met: 1) a valid certificate from a recognized CA; 2) Reverse DNS that matches the subject of the certificate; and 3) an EHLO argument that matches the reverse DNS. In order to accomplish all of that the virus writer would have to hijack the appropriate DNS server and crack the encryption keys of a recognized CA. Not impossible, but extremely difficult.
Can the virus writer hijack Outlook to send the message on its behalf using the ISP's self-signed cert and bouncing through the ISP's mail server? Sure, but that's a well-contained threat. All the ISP has to do to stop that is to add the hijacked user's cert to their local CRL and it's over.
Also, unless I missed something (possible) even though the recipient can specify what type of email he will accept, there's nothing to stop the sender simply specifying whatever they feel like.
True, people can and will lie. That is why AMTP includes authentication. It is more difficult to lie when your identity is easily discovered.
... believe it or not I got a response within an hour telling me that they didn't appreciate me "SPAM"ing their email addresses and I should just email "abuse@"! Oh and the virus flood is still going on. Ho hum.
I belive it, I've had similar experiences. Actually this kind of response is part of the reason for the codification part of AMTP. Most people define spam as "mail that I don't want". Unfortunately, that's not an enforcable criteria. With reliable codification of mail policies we can hope to resolve something.
1. Security does not go any further then the TLS extension to ESMTP. If you force TLS in ESMTP you get the same result.
The TLS extension to ESMTP does not require authentication by a trusted third party. AMTP's authentication requirement is intended to authenticate servers in order to provide a path of recourse in the event a server should abuse the system. Such recourse demands authentication.
2. There is a plethora of "codes" for SPAM which will be abused the same as now and will require regulation.
Yes, the system will be abused. The difference is that with authenticated servers you will be able to stop the abuse.
3. It suffers from the same problem of SMTP as it is hop per hop, not end-to-end.
This was a design choice. I have chosen to change as little as is necesarry in order to make implementation as trivial as possible. If you have suggestions as to how that can be improved, I welcome your feedback.
4. It breaks country laws in many countries which are still being anal-retentive on encryption.
This is something that will need close consideration. I belive that server authentication is vital to solving the problem. I am not aware of countries where TLS is illegal, but that doesn't mean there aren't any. If TLS violates laws in some countries, then I am open to suggestions for avoiding that problem.
Instead of this horrid garbage all that is needed is the following simple fix/extension to SMTP:
Your implication that my solition is "horrid garbage" and that the problem of stopping UBE, which has baffled great minds for years, is trivially solved by a "simple fix/extension to SMTP", is duly noted.
1. Messages should be signed by every gateway on the way with the sertificate of the gateway.
A cryptographic signature does not solve your own problem #4 (above).
It also does not solve the problem of a lack of uniform definitions of "spam".
2. Gateways should no longer modify any headers prior to the ones they add (some do - see spamassassin for example).
Spamassasin is not a gateway. It's a user-space program that some people use to filter or block mail at both MUA and MTA levels. RFC-2821 (section 3.8.2) already proscribes modification of previous gateways' "Received" headers.
What I would like to see is a Mail server with some memory of its history with other mail servers. Histogram of SMTP transations, by IP, sender id and domain, and recipient id and doamin.
You have described how many current RBLs work, which is also why spammers now use a network of millions of hijacked desktops. It's a moving target.
AMTP associates certificates with reverse-DNS so that histographic ideas like your suggestion can be effective.
I've been working on a proposal to replace SMTP for a few weeks now. It's called AMTP and it addresses two concerns in tandem: Authentication and Classification/Policies. I have a web site set up at http://amtp.bw.org/ for the project. There's an announcement list available if you want to find out when the draft is ready for comment.
As mentioned in other posts many mailer servers are able to prematurely reject an email once they've received the subject line and drop the connexion and the rest of the content.
In practice, that just doesn't work very well. Most SMTP clients will continue to retry a message that fails after DATA and before <CRLF>.<CRLF>. I don't see it directly addressed, but section 4.2.5 of RFC-2821 implies that a hard failure (e.g., 5xy) is not really valid in the middle of DATA.
The bill has nothing to do with the location of the sender. Everyone is subject to the laws of whatever jurisdiction they do business.
If a recipient lives in Mich and the sender is in Calif, the recipient can still sue the sender. If the sender fails to respond, the recipient can get a default judgement and attach the assets of sender.
Any law that says you must label spam (e.g., put ADV: in the subject) has two major flaws:
1) It only addresses half the problem, and it's not the important half. It does nothing to ease the burden on the mail servers that must transport the spammer's trash.
2) It sanctions what would otherwise be an illicit act.
As it is today, the act of spamming may or may not be illegal, but once a law is enacted that says "label it", the spam becomes sanctioned by law. Without that law, a hosting company can dump a user for spamming. With the law, it becomes more difficult because the spammer can say "I followed the law!"
Even with a major label, artists rarely make any money from record sales. The 10% or so that most deals pay is based on wholesale (minus all sorts of wild deductions) and is then divided between bandmembers, managers, engineers and other assorted staff and crew. A few pennies per sale is very little money -- even with millions of sales. Most of the money that the major stars earn are from performances, endorsements, promotions, publication, and other things incidental to the music.
It takes more luck than talent to get the majors' attention, so every little bit of exposure helps. While the freeware-music movement may not bring actual $$ to the artists, it does give us a small amount of exposure that we were not getting otherwise.
Slashdot Mirror
Google makes their living selling ads. This may not be a priority for them.
In fact, here's one on a comic: http://xkcd.com/c149.html
--B
I think this type of system will again simply cause the spammers to look for alternate delivery systems, i.e. as more ISPs take a tougher line against spam, more and more spammers will start to take extreme measures to propagate their product.
That may actually happen. It's human nature.
My goal in writing AMTP was simply to provide a way to protect email. I love email, I've been using it for 20+ years. It's becoming unwieldy for me to wade through hundereds, and sometimes thousands, of UBE messages in my inbox every day. I just want to solve that problem.
So cable modem users with big bandwidth and vulnerable machines will be used to send the spam. The spammer uses a worm to find vulnerable machines and piggybacks the users connection and sends the spam, it still goes through the ISP's mail server and so will get validated and delivered.
Today that is possible, with AMTP it will be far more difficult. Today, a machine can look up an MX record and connect to the associated SMTP server and will (usually) get a message delivered. With AMTP that message won't be accepted unless several conditions are met: 1) a valid certificate from a recognized CA; 2) Reverse DNS that matches the subject of the certificate; and 3) an EHLO argument that matches the reverse DNS. In order to accomplish all of that the virus writer would have to hijack the appropriate DNS server and crack the encryption keys of a recognized CA. Not impossible, but extremely difficult.
Can the virus writer hijack Outlook to send the message on its behalf using the ISP's self-signed cert and bouncing through the ISP's mail server? Sure, but that's a well-contained threat. All the ISP has to do to stop that is to add the hijacked user's cert to their local CRL and it's over.
Also, unless I missed something (possible) even though the recipient can specify what type of email he will accept, there's nothing to stop the sender simply specifying whatever they feel like.
True, people can and will lie. That is why AMTP includes authentication. It is more difficult to lie when your identity is easily discovered.
I belive it, I've had similar experiences. Actually this kind of response is part of the reason for the codification part of AMTP. Most people define spam as "mail that I don't want". Unfortunately, that's not an enforcable criteria. With reliable codification of mail policies we can hope to resolve something.
--Bill (Author of AMTP)
1. Security does not go any further then the TLS extension to ESMTP. If you force TLS in ESMTP you get the same result.
The TLS extension to ESMTP does not require authentication by a trusted third party. AMTP's authentication requirement is intended to authenticate servers in order to provide a path of recourse in the event a server should abuse the system. Such recourse demands authentication.
2. There is a plethora of "codes" for SPAM which will be abused the same as now and will require regulation.
Yes, the system will be abused. The difference is that with authenticated servers you will be able to stop the abuse.
3. It suffers from the same problem of SMTP as it is hop per hop, not end-to-end.
This was a design choice. I have chosen to change as little as is necesarry in order to make implementation as trivial as possible. If you have suggestions as to how that can be improved, I welcome your feedback.
4. It breaks country laws in many countries which are still being anal-retentive on encryption.
This is something that will need close consideration. I belive that server authentication is vital to solving the problem. I am not aware of countries where TLS is illegal, but that doesn't mean there aren't any. If TLS violates laws in some countries, then I am open to suggestions for avoiding that problem.
Instead of this horrid garbage all that is needed is the following simple fix/extension to SMTP:
Your implication that my solition is "horrid garbage" and that the problem of stopping UBE, which has baffled great minds for years, is trivially solved by a "simple fix/extension to SMTP", is duly noted.
1. Messages should be signed by every gateway on the way with the sertificate of the gateway.
A cryptographic signature does not solve your own problem #4 (above).
It also does not solve the problem of a lack of uniform definitions of "spam".
2. Gateways should no longer modify any headers prior to the ones they add (some do - see spamassassin for example).
Spamassasin is not a gateway. It's a user-space program that some people use to filter or block mail at both MUA and MTA levels. RFC-2821 (section 3.8.2) already proscribes modification of previous gateways' "Received" headers.
--Bill (author of AMTP)
You have described how many current RBLs work, which is also why spammers now use a network of millions of hijacked desktops. It's a moving target.
AMTP associates certificates with reverse-DNS so that histographic ideas like your suggestion can be effective.
--Bill (author of AMTP)
I've been working on a proposal to replace SMTP for a few weeks now. It's called AMTP and it addresses two concerns in tandem: Authentication and Classification/Policies. I have a web site set up at http://amtp.bw.org/ for the project. There's an announcement list available if you want to find out when the draft is ready for comment.
"M class planets"!?? "tachyon fields"!?? "large-breasted Borgs in stiletto heals"!??
Tell ya what, you head on over there, at warp factor 9, and send us a message over sub-space when you get there. Let us know what you find.
Don't forget to wrap your head in foil to prevent them from stealing your essence.
(grumblegrumble it's wackos like this give SETI a bad name)
--Bill
As mentioned in other posts many mailer servers are able to prematurely reject an email once they've received the subject line and drop the connexion and the rest of the content.
In practice, that just doesn't work very well. Most SMTP clients will continue to retry a message that fails after DATA and before <CRLF>.<CRLF>. I don't see it directly addressed, but section 4.2.5 of RFC-2821 implies that a hard failure (e.g., 5xy) is not really valid in the middle of DATA.
--Bill
The bill has nothing to do with the location of the sender. Everyone is subject to the laws of whatever jurisdiction they do business.
If a recipient lives in Mich and the sender is in Calif, the recipient can still sue the sender. If the sender fails to respond, the recipient can get a default judgement and attach the assets of sender.
--Bill
Any law that says you must label spam (e.g., put ADV: in the subject) has two major flaws:
1) It only addresses half the problem, and it's not the important half. It does nothing to ease the burden on the mail servers that must transport the spammer's trash.
2) It sanctions what would otherwise be an illicit act.
As it is today, the act of spamming may or may not be illegal, but once a law is enacted that says "label it", the spam becomes sanctioned by law. Without that law, a hosting company can dump a user for spamming. With the law, it becomes more difficult because the spammer can say "I followed the law!"
IMHO: We're better off without laws like this.
--Bill
It takes more luck than talent to get the majors' attention, so every little bit of exposure helps. While the freeware-music movement may not bring actual $$ to the artists, it does give us a small amount of exposure that we were not getting otherwise.
Methinks that's a good thing.
--Bill
Home: http://bw.org/