Forgot your password?
typodupeerror
Security The Internet

Replacing SMTP? 539

Posted by Cliff
from the redesigning-the-protocol dept.
dousette asks: "In reading over one of the RFC's governing the SMTP protocol, and other RFC's as well, it's interesting to note that you see some big names and big companies from time to time. With all the loopholes in the current SMTP specification, is it possible for the Slashdot collective to come up with another one? Would it stand a chance in making it into a standard, or do they just listen to Cisco, AT&T, etc? I realize that a lot of people have a lot of ideas how things should be done (and they haven't been shy about posting them to Slashdot), but has anyone tried to write the RFC for a replacement protocol? As a side note (where I won't be shy about posting how things should be done), if there were a replacement trusted protocol, one could have mail received via that protocol bypass spam filtering, id checking, or whatever checks might be in place (saving processor cycles, etc). The regular checks could still be done on other mail received via the 'older' SMTP protocol. If more and more ISP's make use of this, SMTP could be gradually phased out... or if you are one for a sudden cut-over, just cut to the new one at the same time as the IPv6 upgrade!"
This discussion has been archived. No new comments can be posted.

Replacing SMTP?

Comments Filter:
  • by Bryan Ischo (893) * on Monday August 04, 2003 @06:44PM (#6610355) Homepage
    D. J. Bernstein, the author of the supremely reliable and secure qmail mail server, wrote a proposal for a new Internet mail system a couple of years ago. It's called Internet Mail 2000. Check it out at:

    http://cr.yp.to/im2000.html [cr.yp.to]

    The basic premise is this:

    "IM2000 is a project to design a new Internet mail infrastructure around the following concept: Mail storage is the sender's responsibility."

    It's an interesting concept and worth a read.

    Unfortunately it doesn't look like it would do much to stop spamming, which is the major problem with the current internet mail infrastructure. For that, we need some way to make sending bulk email costly to spammers. Actually I'd say that this could be done already with current technologies, it's just that ISPs and large network providers are not being responsible in ensuring that the users of their networks pay the appropriate price for sending out SPAM.

    Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email ...
    • by letxa2000 (215841) on Monday August 04, 2003 @06:51PM (#6610436)
      Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email ...

      I wish people would stop inviting rate increases or new charges as an answer to spam. It's not the answer. It might be inexpensive for you, but many of us DO send a lot of email and it'd get expensive really quick. You'd get rid of a lot of good and valid email communication along with the spam.

      I'm even opposed to the "pay a dime, but I'll give it back if I wanted to hear from you" approach. Those of us running a mailing list would run the risk of having some idiot sign-up a bunch of accounts only to have that person say "No, I didn't want that" and collect the money.

      I believe we need a trusted protocol. This might be as simple as having all emails PGP signed and everything else being sent to the bit-bucket (if you want to be aggressive) or only passed through to the user if the unsigned message had an extremely low spam score.

      But if everyone were to use Bayesian I swear we wouldn't even have to propose a new protocol, talk about new legislation, etc.

      *SIGH*

      • The "pay for email" approach would only work if it was possible to whitelist addresses who would then not have to pay. The mailing list problem then would not exist -- you simply require that anyone who signs up whitelists the mailing list address.
      • by Tumbleweed (3706) on Monday August 04, 2003 @07:02PM (#6610539)
        > I wish people would stop inviting rate increases or new charges as an answer to spam. It's not the answer.

        And the perfect example is regular junk snail mail. It costs them to send it, yet even in the Internet Age(tm), I still get a ton of it. Obviously that's NOT the answer, so "Don't Go There"(tm). :)

        I think locking down SMTP servers and requiring verified & correct return addresses would go a long way toward curbing spam. Then when you disallow someone to send you mail, it could really work.

        A combination of white lists/black lists, and Baysian filtering stops so close to 100% of spam that it's really silly for anyone to be bitching about spam these days. I don't GET any spam anymore - 0. Not 0.001%, 0 - the integer 0, as in none. If I ever get another piece of spam, then I'll change my email address (I can do that more easily than most as I have my own domain.), though this isn't the answer for everyone - lots of people have e-mail addresses printed up on lots of expensive cards & letterhead, etc. For them, the white list / black list / Baysian filtering solution should suffice way more than anyone should practically need.

        Stop yer bitchin', people, and implement the technologies that are already out there and work great. Plus use yer freakin' brains for a change, and don't spew out your real e-mail address to everybody who asks for it. Use your friend's! :)
        • I think locking down SMTP servers and requiring verified & correct return addresses would go a long way toward curbing spam. Then when you disallow someone to send you mail, it could really work.

          In that case, who would define "correct" addresses, the ISP? And how would they be defined? I have at least 1-2 email accounts that I retrieve mail from with POP3, but send outgoing mail with the same domain through my ISPs mail server because there is currently no other way. I own (or, more correctly, lease
          • by Tumbleweed (3706) on Monday August 04, 2003 @07:31PM (#6610760)
            > In that case, who would define "correct" addresses, the ISP? And how would they be defined? I have at least 1-2 email accounts that I retrieve mail from with POP3, but send outgoing mail with the same domain through my ISPs mail server because there is currently no other way. I own (or, more correctly, lease) the domains myself, so no one can legally tell me tell me that I can't send email using those domains. The fact that I send outgoing mail through my ISPs mail server happens to be a necessary evil.

            ---

            Aye, there's the rub. I do the same thing, what with having about 5 domains and various e-mail addresses for each.

            There needs to be:

            1) A way of verifying if you're allowed to use said mail server. Easy. Simple login/password over encrypted connection - technology already in place.
            2) A way of verifying what e-mail addresses & domains are allowed on outgoing e-mails from said mail sever. That would be new, but should be easy to develop.
            3) A way of destination server contacting the originating server and verifying the e-mail it received is from an authorized and stated e-mail account. That would be new, too, and would be a bit more complicated, but still fairly simple.
            4) While you're at it, you might as well encrypt the whole frigging process. The saying, "E-mail is not like a letter; it's like a postcard." should be obsolete. It should be like a letter written in a language only the sender and receiver can understand. By default. Every time. The technology is around, but needs to be standardized and integrated and something the user never has to set up or think about. I loved a recent commercial that said that something was really private, "as secret as your e-mail password." Yikes. People _really_ don't understand e-mail technology.

            Also, a way to have a mail server respond to a confirmation request only by servers it's sent mail to recently would be a good thing - that would cut down on trying to scan a server with a dictionary attack to get valid e-mail addresses to spam to.

            The problem is not that these are difficult technical challenges - they're not, and the technologies exist in fairly decent form already. The problem is getting this done in a standard and accepted way and out into the field for everyone to use. _That's_ gonna be a real bitch.
            • by Strepsil (75641) <mike@bremensaki.com> on Monday August 04, 2003 @07:59PM (#6610956) Homepage

              2) A way of verifying what e-mail addresses & domains are allowed on outgoing e-mails from said mail sever. That would be new, but should be easy to develop.

              There is a proposal for this [ietf.org], which was covered here [slashdot.org] a while back. I like the idea, although it's going to mean more ISPs will have to offer authenticated SMTP relays for roaming users (not exactly a bad thing, in any case).

              Also, to those people saying Bayesian filtering is so great, this doesn't solve my problems. To filter a message on content means I have to accept the damned thing first, and I don't know about anyone else but my inbound traffic costs me money. If I accepted every piece of mail destined for my server, the costs would have me off the net in no time - I have a pretty low-budget operation. Blacklisting servers and not accepting connections from them (and accepting the collateral damage) is the only practical option I have.

              • by letxa2000 (215841) on Monday August 04, 2003 @08:29PM (#6611131)
                Also, to those people saying Bayesian filtering is so great, this doesn't solve my problems. To filter a message on content means I have to accept the damned thing first, and I don't know about anyone else but my inbound traffic costs me money.

                Sure, but for most of us the *time* involved in dealing with spam is a greater cost than the bandwidth involved in receiving it. Bayesian does a great job at solving the "waste of time" problem. And, as I said, if everyone used it I believe spam would disappear quite quickly because the response rate would fall too low for even spammers to have an interest.

                Blacklisting servers and not accepting connections from them (and accepting the collateral damage) is the only practical option I have.

                In the case of a few a spamhauses, sure. But as an effective spam-fighting measure that's a useless approach. You (or someone) has to keep up to date with the latest servers to blacklist (and then whitelist them when they become clean), or you have to deal with an annoying level of false positives that you don't even see. Sure, you can say that that's the price of users dealing with an ISP that is spam-tolerant. But some of us want to do business with those users even if they chose their ISP poorly--or if they don't have any local choice of ISP.

            • by Zocalo (252965) on Monday August 04, 2003 @08:00PM (#6610965) Homepage
              A way of verifying what e-mail addresses & domains are allowed on outgoing e-mails from said mail sever. That would be new, but should be easy to develop.

              This has already been developed by the IETF anti-spam working group, well, kind of. They propose that an additional DNS record type (RMX IIRC) is added to your domain that lists all the trusted IPs that may originate email for that domain. That would include your own outbound mailserver IPs, and/or your ISPs depending on the situation, email that doesn't come from one of the listed IPs is highly likely to be spam.

              The good points:

              • DNS *should* already support arbitrary record types and needs no modifications, according to the RFCs anyway, your vendor's code may not!
              • It's simple to implement in SMTP software, and the IETF was hopeful they would have this up and running RSN.
              The bad points:
              • Something else to manage
              • Not to good if you have users who are very promiscuous in their choice of sending IP: cybercafe's, numerous dial-up ISPs, home DSLs and so on. The proposed workaround is to use subdomains with different server lists, falling back on an unrestricted list if required, but such use of subdomains in email addresses is not always desirable.
              • Why does the very original IP need to matter.

                If the fear is people faking mail, you simply need to require it went through the mail smtp server for that domain. Then the smtp server needs to authenticate all the clients. This would mean that the client IP is irrelavent, it just had to authenticate to a listed address/server.

                You still have a problem with open/insecure releys, but that will always be a problem, an insecure system will always be crackable, and people who intentionally set stuff up to allow
        • Clear as mud. (Score:4, Insightful)

          by HiggsBison (678319) on Monday August 04, 2003 @08:43PM (#6611234)
          I think locking down SMTP servers and requiring verified & correct return addresses would go a long way toward curbing spam.

          A combination of white lists/black lists, and Baysian filtering...

          Stop yer bitchin', people, and implement the technologies that are already out there and work great.

          This doesn't sound like a general solution for J. Random Homeowner.

          It sounds alot like "Well, shoot! Quit yer bitchin' an just put in some tuned ports and performance cam! Hell, my grandmother could do that!"

        • A combination of white lists/black lists, and Baysian filtering stops so close to 100% of spam that it's really silly for anyone to be bitching about spam these days. I don't GET any spam anymore - 0. Not 0.001%, 0 - the integer 0, as in none.

          Have you done the power-curve analysis on that? My mother works at a law firm, and they once tried to install a spam filter. It was state-of-the-art, with Bayesian filtering, and white/black lists, and additional whitefilters on top. It blocked most (not all) of
          • by thrillseeker (518224) on Monday August 04, 2003 @11:27PM (#6612352)
            Even if you have the (extremely impressive) power curves of Paul Graham's Plan for Spam -- and that was on a very well-trained Bayesian filter written by a coding genious -- it is Not Good Enough when missing a legit email could get you sued for millions.

            Email is not a guaranteed service - no one is ever going to be sued for millions for not receiving an email. Things that *must* be delivered will continue to be put into a hard copy format and delivered by courier with a signature required.

          • by 1u3hr (530656) on Tuesday August 05, 2003 @03:21AM (#6613312)
            it is Not Good Enough when missing a legit email could get you sued for millions.

            Email can fail to arrive, or be read, for any number of reasons. It passes through several servers, each of which could fail and lose mail. Same for snail mail -- you require assurance/proof snail mail was delivered, you use registered mail, and get a receipt. There are few if any circumstances you could claim in court someone was liable for not receiving an email that you had sent and not verified had been received.

            If something is in the "millions" category, you fly there and do it in person.

        • A combination of white lists/black lists, and Baysian filtering stops so close to 100% of spam that it's really silly for anyone to be bitching about spam these days. I don't GET any spam anymore - 0. Not 0.001%, 0 - the integer 0, as in none. If I ever get another piece of spam, then I'll change my email address
          [...]
          Stop yer bitchin', people, and implement the technologies that are already out there and work great. Plus use yer freakin' brains for a change, and don't spew out your real e-mail address to
        • I think locking down SMTP servers and requiring verified & correct return addresses would go a long way toward curbing spam.

          OK, so imagine (in a perfect world) that everybody has 100% locked down SMTP servers, and there is an addition to SMTP that requires verified and correct return addresses on every email (regardless of the problems that such verification would cause.)

          What's to stop a spammer from running his/her own mailserver (you know, like they do today), and providing 100% verified and correc
      • by smiff (578693) on Monday August 04, 2003 @07:29PM (#6610744)
        I believe we need a trusted protocol. This might be as simple as having all emails PGP signed and everything else being sent to the bit-bucket

        That's not the answer either. Microsoft, Yahoo, et al have been lobbying for this approach, and for good reason. They want to function as the certificate authority (CA). They want to determine who can or cannot send email. They can use that power to literally sell the ability to send spam. They can also use that ability to censor their opponents.

        Microsoft also wants a new patented standard that can't be legally implement with open source software.

        • by MemRaven (39601) <kirk@[ ]kwylie.com ['kir' in gap]> on Monday August 04, 2003 @08:24PM (#6611099)
          Oh, come on now. You're being just a little bit crazy/paranoid/Slashdotty here.

          First of all, they're applying a common practice used elsewhere (i.e. the use of PKI and trust metrics to control authentication and non-repudiation) to email. It's not like they've invented the special Microsoft Email System which is radically different from everything that's happened before.

          Second of all, PGP and its web of trust are designed explicitly to avoid CA issues like you're describing. If the system is based on X509V3 certs and your web MUA controls your trusted roots, then yeah, they'd be in charge of what you'd be able to see (but presumably you'd have the ability to at least specify that you trust particular certificates).

          Third of all, even if they then "sell the ability to send spam," it'd be pretty easy to tell that they've done it, tell who sent the spam, and take your business elsewhere! The whole point of authenticated, non-repudiatable email is that you actually CAN determine WHO sent the email in the first place, so that you can then track said person down and tell them (politely of course) not to do that anymore. Spam becomes much less of an issue if everybody has to legitimately say who sent every email.

          So stop trying to bring about some type of scare tactic about what is probably the only real way to combat spam anyway.

    • YOU CAN'T RUN A PAY BY THE EMAIL SYSTEM UNLESS THERE IS *1* EMAIL SERVER (or network of servers run by the same entity) FOR THE WORLD.

      you don't realize that IM is a form of email? you are just sending packets of text... the second someone charges for SMTP, i'll just run my own. you could just charge the end users for data transfered instead of flat monthly fee, but most wouldn't go for that.
      • This from a guy whose .sig is only one step above spam.

        -a
      • You're not correct. If the payment is charged by the email recipient, and the email recipient is willing to reject email that doesn't have attached payments (not universally true...), then ANYBODY can start pay-by-email system Right Now, and it'll protect them from unwanted email, just as anybody can implement "reply-to-my-turing-test-response" right now without anybody else being in control. Centralized systems are only needed if you want to force senders to pay non-economics-based amounts to somebody o
    • by gid (5195) on Monday August 04, 2003 @07:01PM (#6610532) Homepage
      Hrm, never seen that before, im2000 has some good idea for simplifiying things, but it seems like it would just be unreliable and unfeasible.

      With the current system, an smtp server can go down, and no one would notice because no one was received their email yet, but with im2000, if the sending machine goes down, then no one can read their mail from there. This would create a lot of unknowns, "why can't I read my email?". Also what about people that don't have a full on connection, you don't want to require those people to be connected just to read their mail. Sure you can queue it for downloading offline somehow, but that's going to be much slower than normal because you have to connect to say 30 different servers where your email is hosted.

      Also there's the case of somesmallcompany.com sending out a mailer/advertisement to millions of people, because the email is hosted on their machine, their connection/server might become overwhelmed, causing heaches for everyone wanting to read their mail. "Why does my mail load so slow?"

      It's a nice try, but it'll never work.

      Another thing, what happens when the message is done being read? Is it deleted on the sender's machine? If so, then how will the user remember that they sent the email to check if it's been read. If not, when will the message get deleted? Obviously it can't stay there forever.

      The great thing about the current system, is that you just send and forget. If it bounces, you get a new email message saying hey, something went wrong. But with im2000, if the message hasn't been read yet, WHY? Did the user just not check their mail yet? Is there connection/routing problem where they suddenly occurred after the hosting server sent the notification, etc.

    • Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email ..

      Do you suppose the ISP that is owned by SpamCo, Inc. would actually charge its users the fee?
    • For that, we need some way to make sending bulk email costly to spammers
      This argument has been used over and over again, and it's just plain wrong. Think about it. Telemarketers have the cost of using the phone, fax-spammers (network marketers) use phone lines also. Bulk snail-mailers pay postage. For some reason, they're all still surviving. Why?

      Because the cost becomes built in to their business model. it won't stop, it will only hurt regular users to charge for email/services. Sure, their profits may be cut a little bit, but that's not going to stop them. if anything, they'll do it more, because if their profit margin is smaller, they'll have to spam harder... right?
      • That is a very good point. Making spamming costly will not stop all spammers. Those with a legitimate business will still spam because there will still be enough legitimate customers out there who buy based on their spamming.

        But making spam costly will indeed stop the majority of spam that is sent today, which is useless, annoying stuff that far less than 1/100 of 1 percent of people actually make a purchase based on.

        That is the kind of spam that I really want to stop, and I think that making spamming
    • by Angst Badger (8636) on Monday August 04, 2003 @07:18PM (#6610664)
      Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email ...

      John Dvorak suggested a scheme along these lines, and in theory, it's a good one, though I'd suggest a tenth of a cent, which would still make sending a million emails prohibitively expensive.

      In practice, though, it's not workable. Spammers aren't using the SMTP server their ISP provides; they're using their own, just like most desktop Linux users are. As far as the ISP is concerned, Spammer X is making a bunch of outbound connections, but they're streaming out through the ISP's switches and routers, not through their SMTP server.

      To impose a tax on certain kinds of TCP connections would require detailed inspection of outbound packets. This is because a single SMTP connection can involve the transfer of many messages. To be reliable, the ISP would have to parse every outbound packet bound for port 25 on a remote system in order to count the number of emails sent. I don't think most people want that level of attention paid to their private emails.

      Moreover, this presumes that all ISPs participate honestly and thoroughly in such a system. All it would take is a few spam-friendly ISPs (and they exist, are legion, and jump around IP ranges like ferrets on a hot skillet) to render such a system useless.

      The alternative would be to implement email billing at the recipient side. Maybe AOL and Earthlink can pull that kind of blockade off, but small companies and J. Random Luser cannot.

      Bernstein's IM2000 proposal at least keeps the bandwidth consumption down, but that's primarily a cost issue for ISPs. (Don't try to convince me that if the amount of spam declined, ISPs would lower their prices.) The main hassle of spam for the user is that it takes time and energy to delete spam, and having to inspect the stuff with ambiguous could-be-from-someone-I-know subject lines would not be alleviated by IM2000; you'd still have to pick and choose what pending inbound email to read or delete.

      The fundamental problem with email as a mail system is that it's open to anyone who wants to send mail -- which is part of the point of mail in the first place -- but there is no economic limiting factor for the sender as there is with paper mail. Since we can't eliminate the openness without destroying the utility of the system, the only possible strategy is to artificially impose a cost on the sender. Unfortunately, owing to the nature of public networking, the only remotely reliable way to do that would be to route all mail through a centralized clearing house. No one company will be able to establish such a monopoly, and I don't think anyone wants the alternative -- which is to have the government do it.

      This may or may not be a soluble problem, but it is, as of today, still an unsolved problem. Personally, I think it's going to take national legislation and international agreements to stop it, and that will no doubt take a long time. Paper (actually clay tablet) mail existed for several millennia before the International Postal Union was finally established. Let's hope email is brought into line a little faster than that.
    • If the sender has to store the message, then suddenly they have to be accessible.

      That's important. A reachable IP makes identification easier. Besides, the sender is also responsible for storage and bandwidth, and those are costs I can bear for my personal correspondents, but that would move spam a little further from free.

      The question is a better one than I thought when I first read it. Although it doesn't sound like IM2000 can guarantee a low enough level of spam by itself, I would not only install a n
  • im2000 [cr.yp.to]
  • Why doesnt the new implementation use the evil bit. It the server is written by m$, or running on an m$ platform it sets the evil bit. If its running under linux it doesnt set it and ignores all mail comming in using evil bit! :P Simple really :P
  • by liam193 (571414) on Monday August 04, 2003 @06:46PM (#6610385)
    This sounds like a great idea. Let's present a new protocol. I suggest we name it Slashdot Mail Transfer Protocol. We could use the shortened form SMTP. hmmm well... on second thought maybe the name needs more work.
  • Jabber (Score:3, Interesting)

    by erat (2665) on Monday August 04, 2003 @06:46PM (#6610386)
    Can't Jabber do a lot of what you're asking for?
    • Re:Jabber (Score:3, Informative)

      by Phantasmo (586700)
      Unfortunately, since Jabber's a baby of the "open source" movement, it has a lot of very wealthy enemies (namely Microsoft) who will work very hard to ensure that it doesn't succeed.
      They are instead backing the (IMO) inferior SIP/SIMPLE technology for IM.

      Read The IM Standards Race [jabber.com] for more information.
  • Costs (Score:5, Interesting)

    by $exyNerdie (683214) on Monday August 04, 2003 @06:48PM (#6610401) Homepage Journal

    A lot of research and ideas and papers have been thrown around to replace SMTP with a better protocol but the costs involved are a major discouraging factor and people don't want to install a system when there is no guarantee that all the recipients have it too.

    Maybe servers using a new mail protocol should be designed such that they first attempt to use the new protocol and if connect fails, try the good old SMTP
    • Re:Costs (Score:3, Interesting)

      by jc42 (318812)
      This scheme is an important part of the old UUCP package. Part of its handshake protocol is a message that lists all the protocols that the caller understands, in the order the caller would prefer to use them. The recipient goes through the list, picks its favorite, and sends back a message saying "Let's use X."

      The advantage to this is that you can introduce new protocols completely painlessly. You pick a new name (after asking around on the newsgroup if anyone is using it), link your new protocol modul
      • Re:Costs (Score:5, Informative)

        by 680x0 (467210) <vicky@steeds.cQUOTEom minus punct> on Monday August 04, 2003 @08:05PM (#6610987) Journal
        That's similar to what happens with ESMTP (yes, there already is a "new improved SMTP"). If the client understands ESMTP, it sends a new command to begin the conversation ("EHLO" instead of the older "HELO"). If the server is old, SMTP-only, it sends an error message, and the client tries again with plain old SMTP. If the server does do ESMTP, it sends a reply, along with the list of ESMTP goodies it understands. Some of the goodies are sending msg size ahead of time (so the server can reject the message due to size limitations before the whole message gets transferred), delivery status notification, and so on. None of the current "capabilities" really help filter out spam, but if you come up with a new feature, you can add it as an ESMTP capability, and whenever both client and server support it, it will be used.

        Check out RF2821.

  • SDTP (Score:5, Funny)

    by thenextpresident (559469) on Monday August 04, 2003 @06:48PM (#6610404) Homepage Journal
    "is it possible for the Slashdot collective to come up with another one?"

    SlashDot Transfer Protocol - Essentially, the way it works, is the information is posted on one single, easily crashed server. Then, this information is linked to by Slashdot. Then, said server is taken down. However, 1,000 other posters will have mirrored it by then, therby helping in the "transfer" of the information.
    • by barzok (26681)
      Sounds more like Bittorrent to me.
      • Bittorrent is more organized (controlled more or less by a program), whereas SDTP is simply human controlled.

        Of course, SDTP also utilizes GCIP (Google Copyright Infringing Protocol) often. =)

        *Preemptive Note: GCIP is not meant to be taken seriously in any way. Seeing that this is Slashdot, I am sure there are people that would read more into it then was meant.
  • SPAM is a problem, but I think it can be fixed above SMTP by whitelisting or webs of trust. What are these "loopholes" in SMTP?

    • by pbur (88030) on Monday August 04, 2003 @06:58PM (#6610498)
      To me a big problem with SMTP is that is never authenticated. There's no way you can verify anyone actually sent you an email, short of PGP keys.

      At least if some one had to authenticate to send as joe@bar.com, some spammer would have to hack your password before they used your email address as the "From:" in a mailing...which just happened to me.
    • by jc42 (318812) on Monday August 04, 2003 @07:24PM (#6610703) Homepage Journal
      Well, I think those "loopholes" are all the zillions of features that people want, but they aren't good enough software designers to realize that the features belong in the layer above SMTP.

      In particular, lack of authentication is a strength of SMTP, just as it is with IP. It means, for example, that I can implement my own authentication (or plug in PGP or whatever), and don't have to use the mail-transfer layer's after it turns out to have a serious hole that lets the spammers and con-men through.

      Protocols that try to do everything for you have the inherent problem that, when a serious problem arises, you have to put up with it until the idiots at the vendor decide to solve it.

      SMTP is simple enough that even a relatively incompetent programmer can do it correctly. You can type it yourself via a telnet connection.

      And adding features in the higher layers is easy.

  • slashdot (Score:5, Insightful)

    by Anonymous Coward on Monday August 04, 2003 @06:49PM (#6610420)
    is it possible for the Slashdot collective to come up with another one?

    Not a chance. The slashdot collective taken as a whole, is a very stupid group of people. Even the few intelligent people wouldn't be able to get anything useful done because they'd be shouted down by the teaming masses of idiots.

    We hate Sony's recording arm, but we'll sell our souls to them for the next cool gadget. We hate MS, but 90% of us use windows on our main home machine. No to mention all the idiots who use words like boxen.
  • QWERTY!!! (Score:2, Flamebait)

    by litewoheat (179018)
    You're probably typing on a QWERTY keyboard, right? Why? Its function is to slow you down so that you don't jam the typewriter.

    Moral: Just because one design is better than an already widespread yet inferior design does not mean that it can and will replace the current one. Change is not easy in the least.
  • by dspyder (563303) on Monday August 04, 2003 @06:51PM (#6610440)
    SMTP is so deep-rooted and pervasive already it will be a long, hard change to implement. Every little cellphone that comes with a mail-client. Every router that has smtp alerting. Every application that uses it for various tasks... they would all have to be updated!

    Doesn't mean it shouldn't be done, but don't be fooled into thinking it's just a "propose a new spec, step 2?, profit" type of deal....

    --D
  • by Ninja Master Gara (602359) on Monday August 04, 2003 @06:53PM (#6610454) Homepage
    As long as SMTP continues to the be the friendly protocol.

    HELO imamailserver.com
    250 Hello imamailserver.com [127.0.0.1] nice to meet you!

    • So... instead of a friendly hello, the mailserver should instead answer for an incoming connection request with a gruff "nuqneH!" (Klingon for "What do you want?")
  • SPF (Score:4, Interesting)

    by Karl J. Smith (184) <karl@onetruekarl.com> on Monday August 04, 2003 @06:53PM (#6610457) Homepage
    http://spf.pobox.com [pobox.com] describes an elegant anti spam solution that uses dns, and can be phased in gradually. The basic ideas:
    • cuts spam and
    • stops email address forgery
    • when domain owners designate sending mail exchangers in DNS, so that
    • SMTP servers can distinguish legitimate mail from spam
    • by verifying sender domain against client IP
    • before any message data is transmitted.
  • by dex22 (239643) <plasticuser.gmail@com> on Monday August 04, 2003 @06:54PM (#6610469) Homepage
    I'd like to simply see SMTP updated to require work. On establishing a connection, a recipient should be able to give the sender a task to complete that takes a second or two. The recipient will only accept the mail once the work unit has been done.
    This would make it too slow to send spam, by making it simply too processor intensive. Legitimate users would be unaffected.
    • It doesn't make it slow to send spam, makes it slow to send bulk email, of which SPAM is the best known and most annoying subset. Mailing lists are also a subset.

      Most examples of "takes a second or two" are very processor dependent. You'd then also have the problem of running code on another machine, DOS attacks, all that fun.
    • The problem with this is that it makes it impossible to use an older system in order to send e-mail -- anything difficult enough to cause an appreciable delay for a new system will take intolerably long on a low-end pentium or 486. There's no reason why e-mailing someone should require a new machine.

      It might work to allow the reciever to have a whitelist of addresses -- so that you only have to do the work if you are sending to someone you don't know. Still, I sure wouldn't want to have to let my compute
    • by silas_moeckel (234313) <`moc.proc-cnimsd' `ta' `salis'> on Monday August 04, 2003 @07:30PM (#6610756) Homepage
      OK now you have to check to see that that work is valid that also takes a second or two. Your talking about a spammer arms race they will get nice shiny new SMTP work unit coprocs on a PCI card that can do it in a few milliseconds (remember how they broke DES in 48 hours) or better yet a calculated list of every possible work unit? Spammers make money with email to just about everybody else it's a cost center so they can afford to get piles of machines to send there junk everybody else on the planet cant.

  • Difficult Problem (Score:3, Interesting)

    by 4of12 (97621) on Monday August 04, 2003 @06:55PM (#6610476) Homepage Journal

    I agree that something ought to be done to cut down on the huge volume of spam that clogs most SMTP traffic.

    On the surface of it, a white-listing system, perhaps based on public-key cryptography and endorsements might work.

    But, as someone who values freedom and anonymity, I'd hate to have a system that closes off completely the opportunity for more anonymous communication via email.

    Whistleblowers in the government and in the corporate sector, dissidents under a repressive political regime are some of the use cases for email that I'm not really inclined to sacrifice merely to eliminate spam.

  • With all the loopholes in the current SMTP specification,is it possible for the Slashdot collective to come up with another one?

    To start with, I would suggest a detailed look at RFC 2549 [isi.edu].

    The Standard for the Transmission of IP Datagrams on Avian Carriers described therein is fairly broad and could prove a feasible alternative to current email delivery mechanisms, specifically SMTP.

    The reason I think it hasn't taken off since 1999 is that it proposes to completely replace IPv4 (like IPv6). Maybe it wou

  • by Dark Lord Seth (584963) on Monday August 04, 2003 @06:59PM (#6610508) Journal
    If more and more ISP's make use of this, SMTP could be gradually phased out...

    Like IPv6? You mean most things will already be there but no one will support it, no one will care apart from a few and no one will implement regardless of how hopeless and disastrous the current implementation is?

    or if you are one for a sudden cut-over, just cut to the new one at the same time as the IPv6 upgrade!

    Ah yes, like IPv6 indeed. You know, I'll send a shiny mail delivered by SMTP2* over an IPv6* internet about the release of Duke Nukem Forever* to my gaming-addicted girlfriend* on the day SCO coughs up some evidence*

    Note:
    * = May or may not require divine intervention.

    • my gaming-addicted girlfriend*

      Think about what you're saying! Do you want a girlfriend that:

      never has time for you

      too into the game to bathe for weeks at a time

      more interested in game than sex

      kicks your ass in Quake

      I didn't think so

  • With all the loopholes in the current SMTP specification, is it possible for the Slashdot collective to come up with another one?

    Yes, I'm sure that Slashdot is up to the task of coming up with another loophole.
  • SMTP over TLS (Score:5, Insightful)

    by NearlyHeadless (110901) on Monday August 04, 2003 @07:03PM (#6610548)
    There is already a protocol that can ensure the identity of the sending SMTP server: RFC2487: SMTP Service Extension for Secure SMTP over TLS [faqs.org]. With the right certificate policy you could make sure that all spammers could be tracked down. I have suggested that people transition to SMTP over TLS and use a challenge-response system (such as TMDA [tmda.net]) for backward compatibility.

    Working out the details of an appropriate certificate policy is not trivial, though.

  • by jc42 (318812) on Monday August 04, 2003 @07:03PM (#6610549) Homepage Journal

    C'mon now; the IPv6 upgrade will be spread out over at least several decades. And both Microsoft systems and many US Government installations will still be using it a century from now, because it's "standard".

    After all, it's now past the death of typewriters, and we're still using the typewriter keyboard from nearly two centuries ago. And we use a ridiculous rail gauge, because the standard was set centuries ago.

    And here in the US, we're still using inches and feet, measurements based on the lengths of the thumb and foot of a long-dead king. And we call them "standard".

    We will be stuck with IPv4 for long past the final download of anyone reading this.

    SMTP will probably be around even longer. But that's OK; it's fun to impress friends by a "telnet 25", followed by typing in a message directly to the server. I like to use "MAIL From: dubya@whitehouse.gov", and ask them if they'd be interested in a nice job in the TIA program. Then I challenge them to prove from the message they get who actually sent it.

    • by darrylo (97569) on Monday August 04, 2003 @08:26PM (#6611111)
      After all, it's now past the death of typewriters, and we're still using the typewriter keyboard from nearly two centuries ago. And we use a ridiculous rail gauge, because the standard was set centuries ago.

      Don't laugh. The following might be apocryphal, but it's still interesting .... I don't know where it comes from, though:

      The US standard railroad gauge (width between the two rails) is 4 feet, 8.5 inches. That's an exceedingly odd number. Why was that gauge used?

      Because that's the way they built them in England, and the US railroads were built by English expatriates.

      Why did the English build them like that? Because the first rail lines were built by the same people who built the pre railroad tramways, and that's the gauge they used.

      Why did "they" use that gauge then? Because the people who built the tramways used the same jigs and tools that they used for building wagons which used that wheel spacing.

      Okay! Why did the wagons have that particular odd wheel spacing? Well, if they tried to use any other spacing, the wagon wheels would break on some of the old, long distance roads in England, because that's the spacing of the wheel ruts.

      So who built those old rutted roads? The first long distance roads in Europe (and England) were built by Imperial Rome for their legions. The roads have been used ever since.

      And the ruts in the roads? Roman war chariots first formed the initial ruts, which everyone else had to match for fear of destroying their wagon wheels. Since the chariots were made for (or by) Imperial Rome, they were all alike in the matter of wheel spacing.

      The United States standard railroad gauge of 4 feet, 8.5 inches derives from the original specification for an Imperial Roman war chariot.

      Specifications and bureaucracies live forever. So the next time you are handed a specification and wonder what horse's ass came up with it, you may be exactly right, because the Imperial Roman war chariots were made just wide enough to accommodate the back ends of two war horses. Thus, we have the answer to the original question.

      When we see a Space Shuttle sitting on its launch pad, there are two big booster rockets attached to the sides of the main fuel tank. These are solid rocket boosters, or SRBs. The SRBs are made by Thiokol at their factory in Utah. The engineers who designed the SRBs might have preferred to make them a bit fatter, but the SRBs had to be shipped by train from the factory to the launch site.

      The railroad line from the factory had to run through a tunnel in the mountains. The SRBs had to fit through that tunnel. The tunnel is slightly wider than the railroad track, and the railroad track is about as wide as two horses' behinds.

      So, the major design feature of what is arguably the world's most advanced transportation system was determined over two thousand years ago by the width of a horse's ass!

      • by jc42 (318812) on Monday August 04, 2003 @09:48PM (#6611747) Homepage Journal
        You'll find some good commentary on this particular bit of mythology at:

        http://www.snopes.com/history/american/gauge.htm

        Their best comment on it is probably:

        Marvelling that the width of modern roadways is similar to the width of ancient roadways is sort of like getting excited over a notion such as "modern clothes sizes are based upon standards developed by medieval tailors." Well, duh.

        Then they go into a rather detailed explanation of why it's basically an uninteresting historical semi-truth for exactly this sort of reason.

        Still, the modern "standard" railway gauge does go back at least a few centuries. And the early railroad equipment was derived from the sort of horse-drawn vehicles (carriages and carts), so of course it was about the same size.

        But in the "standards" sense, the current American rail gauge doesn't really trace back to anything Roman, or much before around 1800. Before that, it's just vague copying, with sizes coming out nearly the same because the job (carrying people and their luggage) was about the same.

        The Space Shuttle tie-in is completely bogus.

  • by Malach (25852)
    Technological fix to a social problem.

    It's simple. Don't bother.

    The problem will remain, it will just shift tactics. By 'fixing' SMTP you're not addressing the problem, you're addressing a symptom of the problem.

    Anything we do on the technology side to fix this problem will ultimately do nothing.

    That's not to say that SMTP can't be improved on... but improving on it purely to 'stop spam' is a waste.

  • Actually, I've been working on a broader based piece of infrastructure than a new mail protocol, but the first problem I intend to attack is mail.

    RFC 822 is fine for messages, but the transport needs a big upgrade. Also, envelope senders and receivers are non-verifiable, and therefor broken. One day, spammers are going to start using mailing lists and message boards to construct a profile of people you talk to, and send you mail that appears to come from them, thereby making whitelists useless.

    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.

    A public key ID plays a similar role to an IP address in an IP packet. There will be distributed databases that hold (signed) mappings between public key IDs and their locations using other networking mechanisms.

    I'm trying to design this protocol and its implementation so its easy to encapsulate it in almost anything. My first connection to an outside protocol will be IMAP/SMTP.

    It's far from being ready for even a public alpha yet, but I do have preliminary code for creating certain kinds of messages at https://svn.generalpresence.com:5131/repos/trunk/C ++/pract_crypto/ [generalpresence.com]. I'm borrowing heavily from Bruce Shcneier and Niels Ferguson's latest book, Practical Cryptography. The initial implementation is in a mix of Python and C++. It requires Swig and the GMP library. I haven't designed the implementation itself to be in the least robust against attacks by someone who has root on your machine.

    I am calling the protocol 'CAKE' for now. CAKE stands for Key Addressed Crypto Encapsulation. It is a layered protocol, since I intend it to be layered on top of any other protocol you can think of. :-)

    One intention of mine is to publish a hash collision problem along with information mapping a public key to a mailbox. First time senders will have to solve the hash collision problem to avoid having the mail thrown away. I'm planning on simply wrapping an RFC 822 message in a CAKE shell.

  • If you want a new protocol, write an internet draft and submit it to internet-drafts@ietf.org.

    From there it can be evaluated, a Working Group created to push it through engineering review to Last Call, to proposed standard.

    Sounds easy, well you can expect to spend aproximately 20 hrs/wk on it for 3 years, and that is if it is a non-controversial idea. For something controversial like changing the SMTP protocol, expect it to effectively never happen, why you might ask... Well lets say the first problem i

  • I thought SMTP was Spam Mail Transfer Protocol!

    Just kidding.

    Seriously, because of spam issues, there have been many proposals for ways to replace SMTP or to modify it. Some of them are downright comical.

    But it's going to take something a lot bigger than that to change anything.

    Any replacement would have to be completely backwards compatible with SMTP for years to come. Many people would never switch. Others would switch only after seeing it in operation for a long time.

    Since it would have to be comp
  • by geek (5680)
    Why not P2P email? Then all mail is on the senders machine until the recipient comes online to check it. It seems P2P is perfect for such a system.
  • It seems like the issue that you're trying to solve, implicit from your original post, is that SMTP allows a lot of spam. Are you sure that this is a problem with SMTP? In other words, is this a protocol problem or an application problem?

    Non-email messaging systems have been thinking about virtually the same problem quite a bit, and have come up with a set of solutions that try to solve what are fundamentally the same issues: message integrity, message non-repudiation, and message authentication. And the surprising part of this is that nobody really focused on the protocol, because it doesn't provide the path to a meaningful solution to the problem.

    Case in point: web services. While initially the people who were playing iwth web services started out doing security at the transport level (i.e. with SSL and various derivatives thereof), but realized that something like WS-Security (where the security of a message is a part of the message itself) is the more optimal approach.

    Why not just force the issue into the realm of S/MIME (and similar extensions to rfc822) and handle it at MUA space? You can cover virtually all the problems with SPAM by following the example of the reliable messaging systems and doing more with the contents of the message itself, rather than trying to say that messages have to transmit over a particular protocol. For example, depending on your trust environment, S/MIME signatures solve the authentication, non-repudiation, and integrity problems perfectly. What more do you need/want?

  • Why replace it? (Score:3, Insightful)

    by silas_moeckel (234313) <`moc.proc-cnimsd' `ta' `salis'> on Monday August 04, 2003 @07:25PM (#6610705) Homepage
    SMTP works for it's intended purpose lets extend it to SMTPv3 (I think it's been extended once allready) So here is a general brainstorming.

    If you exent it two servers with the extensions will send mail in the new more secured format.

    Frst things first keep it friendly you should be able to do everything via telnet because it jsut makes testing easy.

    So what do you need a little bit on how to get into this new mode once your connected to port 25.

    The server must offer what encryption methods it allows as a list more perfered methods first. Unencrypted should be an option all senders and receivers MUST allow it as encryption is nice but CPU heavy and you can allays depreciate enencrypted senders.

    There should be a DNS entry for the sending mail servier in the domain that the from address and the reply to address originate (some new DNS field well it's a nice big distributed DB with cache so why not?) This needs more work and it sorta outside of scope.

    If the sender domain is part of the servers domain of responcibility the server must use the from and replyto addresses to authenticate the user(s) passwords via CHAP, Kerebros etc this MUST be done after the encrypted state is up and can NOT allow unencrypted passwords and perferable uses a CHAP like system where the password is never on the wire.

    The receiving server must include all options specified by the sending server as message headers.

    The server MUST only accept mail that is destined to it's domains or source from one of it's domains if accompinied with valid credentials.

    A server to server intermediary authentication may be implemented.

    OK thats no where near completed but it's a start.
  • by keithmoore (106078) on Monday August 04, 2003 @07:26PM (#6610715) Homepage
    The problem is that building trust networks is really difficult, and all the ways that make it look easy actually end up making some small set of concerns (i.e. the certificate authorities) very powerful, and thus, dangerous.


    SMTP already has authentication, and anyone who operates an SMTP server is free to accept or not accept mail from whomever he wants. You don't need a new protocol to require mail to be authenticated. If you can solve the trust problem, you can implement a trusted mail solution more quickly and easily with SMTP than by requiring deployment of an entirely new protocol.

  • Pragmatism required (Score:3, Informative)

    by m00nun1t (588082) on Monday August 04, 2003 @07:32PM (#6610773) Homepage
    I don't think the /. community could do this. Why? Too many idealists. Look at all the "successful" protocols (HTTP, POP3, etc) - they all are loaded with problems, but regardless, they get the jobs done and where appropriate, get fixed over time. A pragmatic approach is required IMHO - something that does the job and that a large group of people could agree on. Pragmatism & consensus are not things the /. community are renowned for.
  • How about this? (Score:3, Interesting)

    by Garion911 (10618) on Monday August 04, 2003 @07:41PM (#6610822) Homepage
    Keep using SMTP... But after the message is recieved, and the connection dropped, have another mechanism connect to the senders server (from the MX in DNS), asking if it sent this MD5SUM(message), on this date/time? If so, let it through. In not, check the user's preferences to see if they allow non-checked emails, and processs accordingly (place it in a users subfolder, forward to admin, whatever...)..

    This doesn't break anything as it stands now, users/admin can choose how its handled, and should be fairly simple to implement.. There would be an overhead cost of keeping track of the MD5's... But it could be done...

    Just an idea... Waiting to be shot down...
  • Karma! (Score:3, Funny)

    by JediTrainer (314273) on Monday August 04, 2003 @07:46PM (#6610855)
    Can't we use Karma?

    Simple premise - everyone in the world signs onto the 'KarmaMail' service, and get to send mail at "1". Once enough KarmaMail users validate the user's email as being legitimate, their Karma goes up. Registered users can also complain about a spammer, thus making their Karma go down. Marking email messages as 'urgent' requires a higher Karma. Users with a negative Karma (>= -5?) can only send at '0'. Users with a very negative Karma get booted off the system.

    Then individual users can use Karma plus Whitelists to decide who to read mail from. Whenever a server receives mail, it checks with the central KarmaMail repository and inserts the user's Karma into the mail headers (optionally, Karma can be assigned to the *server* as well, eliminating the open relay problem). The header can then be processed by the mail reader.

    Maybe someone would care to expand this idea further to clear up the many loopholes I've left?
  • by nickgrieve (87668) on Monday August 04, 2003 @07:46PM (#6610864) Journal
    SMTP is not the problem. Open Mail Relays are the problem. As long as you can drop an SMTP box on the net and have it spew Spam to other mail servers you will have Spam. Any new Mail Transport Protocol will have to be backwards compatible. i.e., receive mail from old SMTP servers. You can't switch all machines over at one time, you need to roll out one box at a time and keep it all working all the time.

    In the country where I live there is a general rule for farm animals, the farmer is not responsible for fencing them in, it is your job to fence them out. Mail is the same, its not my job to stop spam being sent, but to stop it being delivered (to my users) There are many ways to do this, a combination of a few can be very effective.

    As for the home user, well stop buying into the "submit your e-mail and we will send you porn" forms on the sites you wife does not want you to look at. :-)
  • by B.D.Mills (18626) on Monday August 04, 2003 @07:59PM (#6610953)
    There's not a lot wrong with SMTP. The trouble is that SMTP is always implemented so it delivers mail as fast as possible. And that's the problem.

    Judicious teergrubing (intentional slowing of responses; teergrube is German for tarpit) can alleviate many problems.

    For example, let's examine the Rumplestiltskin attack (a form of dictionary attack to guess e-mail addresses). The trouble here is that most mail servers send back their "No such account" response immediately, so an attacker can try about 5-15 addresses a second. If the mail server was programmed to wait 5 seconds before sending back the response, then the Rumplestiltskin attack would be slowed down by about 50 times. Even better would be to make the delay longer and longer for repeated attempts from the same IP. This way, a normal user with a couple of dud e-mail addresses is not harmed much, but the Rumplestiltskin attack eventually gets bogged down in the tarpit. We have a 3 second delay at the login prompt if we enter the wrong password, so why not a delay at the mail server for incorrect e-mail addresses?

    Another way to slow the spam is to teergrube *all* e-mail connections so all email takes a few minutes to send. Legitimate users aren't harmed much by this, but spammers are hurt a lot. Spammers rely on speed to send all their e-mail, and if we slow them down we can hurt them.

    Then there's the question of what happens if a spammer sends another RCPT or other similar packet before receiving the response from the first? SMTP can legally drop the connection because such command buffering may be "unsupported". So the spammer must be teergrubed or must experience a *lot* of dropped connections.

    There's no need to replace SMTP yet. Instead, we use the tools we have in a slightly different way, and the spammer can be inconvenienced a lot.

    For more information on teergrubing, go here [iks-jena.de].
  • by m11533 (263900) on Monday August 04, 2003 @08:03PM (#6610975)
    I come to this discussion as an expert, albeit a bit dated, as I spent a number of years as the lone software developer supporting ALL email software at Apollo Computer (before it was bought by HP).

    There once was a very interesting competing standard from OSI, the X.400 standard. Most people now think of X.400 as an interconnect standard for bridging the various email systems out there. Yet, it actually is a specification for a very robust email system in and of itself. It is based on a self-describing data representation... no, not XML since XML wasn't even a twinkle in someone's eye at that time, but ASN.1. That standard has been somewhat successful as used in X.500, which has become somewhat popular through its exposure via LDAP.

    SMTP has never been a particularly strong standard. First, it is not the specification for a complete email system. It mearly describes a protocol for exchanging messages between two processes via the network. This is not sufficient to build an email system. Thus we also get POP and IMAP, and any number of supplimental bits that are not necessarily standards. Even sticking to exchanging email between two processes, SMTP has always been rather loosely specified. Sendmail has served as the reference implementation. Supporting sendmail was more a matter of figuring out what it was doing than reading the SMTP specification since sendmail used a far richer protocol for exchanging email than described in the specification. Thus, the question of what comprised a compliant implementation was more like (does it interoperate fully with sendmail) than going through a specification and checking off each element it described.

    Apollo started a project to produce a native X.400 email system. It had a very rich set of features that go far beyond what we see today in Unix and Windows email systems. The project was put on hold when I was reassigned to a higher priority task, I was a member of a strategic technology team given the task of determining what "everyone" meant by the term "CASE Integration" with the goal of producing a corporate strategy and piloting and/or prototyping some initial products. Given the state of the CASE community, it sure seems like pursuing the email strategy would have had better long term success. Of course the CASE Integration project died a painful and horrible death when HP bought the company. Surely "SoftBench" did everything and more...
    • > I come to this discussion as an expert

      Gee whiz! Better mod this one "+10: Self-Proclaimed Expert" to distinguish it from all the other stuff on /. that's posted by people who forget to point out to us how knowledgeable they are.

  • by djmitche (536135) on Monday August 04, 2003 @08:29PM (#6611129) Homepage

    This is currently being discussed on NANOG [merit.edu] (where it's an offtopic favorite). I highly recommend this list for peeks and views into the people who keep this Internet thing working.

    In the discussions yesterday and today, there's been a lot of talk about how to "bootstrap" this new protocol. There are interesting discussions of the business ramifications of being an early adopter of something like this -- very sililar to those for IPv6.

    It's been said by far wiser people than me: spam is a social problem, and it must have a social cure. Any solution which does not respect these two facts is doomed to failure.

  • by thogard (43403) on Monday August 04, 2003 @08:41PM (#6611226) Homepage
    There is a solution on the table and US law that requires the US government to use it. Its called X.400 and it is a mess. For a start you have to register your server and that used to cost something like $25,000 or maybe $40,000 for businesses. The Gossip program for gov email requires all email systems to migrate to this x.400 nonsense but I manged to get them to allow a migration path through SMTP (the others were worse and the only two that were even consididered that worked were SMTP and UUCP). The only encrytion addon for sendmail happens to be a result of work that started from encrypting x.400 stuff.

    If you want to fire up your own X400 server to play with, grab isode and try to get it to compile on your machine without gagging if you can. Its one nasty bit of bad code.

    SMTP isn't that broken. It works for about a billion people. Any attempt to "fix" it will break it for way too many of them.

    After looking through the posts here (most of the +5 should be -5 Stupid), its clear that most of the experts don't understand email in the real world.

    Encryption:
    The 1st tings is email must be interceptable. Many governments won't allow high level encryption that isn't full of holes that allow them to play pack recorded streams. Most large email servers can't deal with the CPU load of full encryption anyway so 100% solid encryption is out.

    Authentication:
    Authenticating the server is very importaint to many sites. Once you start doing some level of encryption, you need to make sure you know who your connecting to.

    Authenticating the client is the where spam issue comes from. There are many ways to do this but none of them are being done and none of them work 100% (which is why none of them work)

    There is no way of knowing of a new business is a spamer or not. Therefore there is no way to filter out spamers that have enough cash to hook up to new ISPs all the time. (there are some stupid ideas like charging--my isp is rich enough, forcing all email out--my isp's mail server is up 100% doesn't understand MX,I can run my own server and it works so why chnage?)

    reverse MX record checks only work if you can trust the ISP to get reverse dns working correctly and they won't deligate it to a spam house. The other choice is a verisgn like company to whitelist everyone or some sort of distributed whitelist (which the spamers will try to hack into)

    As far as fixes:
    The solution is patch sendmail, qmail, postfix, exim to understand email on port 26 (pointed to by a srv record) and if mail comes in on the new port, then it must be checked with a reverse MX record or its dropped. Get the clients to stop handing off email on port 25 (sendmail allows port 587 for that) Use something like the SSH transport layer to encrypt (i.e. set up the encrypted channel 1st and then figure out whos talking). Add a new smtp verify_message command so I can ask another server "did you send me messages Xcxczxczqweczx?". Patches for all 4 systems must come out at the same time but be tested aginst each other. The when an ISP figures enough of its mail comes in on something other than 25, kill port 25 forever. That will kill all the proxies and all the old email gateways that haven't been updated in years.

    Or save up your money and buy your self an X.400 gateway license adn tell all your friends about your cool new email address with all thouse nice slashes and no @.
  • by Anonymous Coward on Monday August 04, 2003 @10:30PM (#6612029)
    Do not send the message along with the envelope. Mail servers should only collect message envelopes, which contain information to obtain the real message. Then when someone reads their email their email program contacts the server to obtain the message. Thus you can't send email and vanish, since if you're not there when someone checks their email, they won't get your message.

    Obviously ISPs will have to have the ability to store the messages of their users so they can deliver them while the user is offline, but that's no problem. If a user, or someone else, sends spam, once the ISP is notified, they can remove it from their servers, so that no further people who were sent the spam will actually recieve it upon reading their email.

    Why I'm writing this I don't know. No one reads below score 3 anyway unless you're lucky and get one of the first 10 replies. Slashdot is useless. I'd shit myself if one person actually read this post. Hell, I can't even find posts after I make them, even after waiting several hours.
  • by dsfox (2694) on Monday August 04, 2003 @11:24PM (#6612333) Homepage
    The people who design a new mail protocol should, at the very least, all know the current one backwards and forwards.
  • by BELG (4429) on Tuesday August 05, 2003 @11:28AM (#6615348)
    Filters are -very- expensive (both for the computer, you and me), and a fee-per-email system is silly, and does nothing to actually control spam.

    The only really effective way I can think of is another fscking registry. ISPs and companies large enough to really need external relays pay the fee to register their mail-server there, and the new implementation of the SMTP-protocol only accepts external mail from other listed servers.

    The downside? A fee comparable to the price of a domain name for ISPs, companies and stubborn individuals. Don't give me the old crap about "having to run your own relay", because you still could, by in turn having it relay through your ISPs server. Your ISP doesn't provide you with a relay? After this, they would have to.

    The upside? It would be a lot easier to blacklist spammers. No more hijacked boxes on broadband-connections flooding us with spam.

    Oh, I know, it will be shot down because there's a fee involved, but keep in mind that I would be one of the people that would have to pay that fee, and it would be a very small price to pay to protect myself and my users from spam.

"There are things that are so serious that you can only joke about them" - Heisenberg

Working...