Full Disclosure mailing list archives
Re: [LONG] Improving E-mail security...
From: Valdis.Kletnieks () vt edu
Date: Wed, 27 Aug 2003 00:37:07 -0400
On Tue, 26 Aug 2003 23:05:15 EDT, "lceone () comcast net" <lceone () comcast net> said:
size). If the protocol was rewritten to allow only "one for one" sending, maybe this would slow them down?
Remember in your analysis to include the fact that large mailing lists DO exist, and that RCPT TO piggybacking exists for a very good reason: It's an amazing performance win if you DO have multiple recipients at a site. And it's something that Sendmail has had in a more general form for 5 years: 8.9.0/8.9.0 1998/05/19 ..... Add the MaxRecipientsPerMessage option: this limits the number of recipients that will be accepted in a single SMTP transaction. After this number is reached, sendmail starts returning "452 Too many recipients" to all RCPT commands. This can be used to limit the number of recipients per envelope (in particular, to discourage use of the server for spamming). Note: a better approach is to restrict relaying entirely.
Oh! And *maybe* we could make relaying OFF by default! Wacky ideas.
Also in the 8.9.0 release notes: CONFIG: by default do not allow relaying (that is, accepting mail from outside your domain and sending it to another host outside your domain). The big problem these days are open *PROXY* servers and trojaned boxes. Open mail servers are getting rare.
So maybe it would be in the best interest of the internet community if someone stopped and took a look at what the requirements for a good communications protocol to replace email would be, and tried to put one together from the ground up. Security, features, and all. Heck, if I can get a group together, I'll take a crack at the darn thing myself.
See the asrg () ietf org mailing list: https://www1.ietf.org/mailman/listinfo/asrg Make *very* sure to read the archives before proposing a Brilliant New Idea, as most of them have already been proposed and then torn to shreds by people who run major mail servers for a living. https://www1.ietf.org/mail-archive/working-groups/asrg/current/maillist.html Quick guidelines: 1) Make sure your scheme interoperates with itself - for instance, many challenge-response systems lose here because they deadlock if they encounter another site running themselves. 2) Examine if your scheme still works if *everybody* does it - for instance, many "look for this header as spamsign" schemes don't work because spammers will just change what they do (which is why SpamAssassin keeps shipping new rulesets - this is NOT a long-term sustainable scheme). 3) Examine if your scheme works when only a few sites have deployed - if it requires near-universal deployment to work at all, make REALLY sure you discuss bootstrapping issues. If you require that AOL, MSN, Yahoo, and the next 4 largest providers all convert their entire user bases *before* you have critical mass, explain the business logic - in particular, why should one of those 7-10 sites deploy (with associated expense) without a *guarantee* that their competition will do likewise? Why should anybody buy into this if they're still going to be dragging a legacy-SMTP gateway along until 98% of the OTHER sites have converted, and said gateway is going to be leaking in spam the whole time anyhow? 4) Examine your scheme for cost/benefit issues - any scheme where the cost is born by one end but the benefit is at the other end will have trouble. For instance, HashCash is a tough sell because the *cost* (cpu in this case) is born at the sender end, but the *benefit* (rate-reduction of non-whitelisted mail) is born by the reciever. 5) Examine how your scheme works under scaling - does it Do The Right Thing for 40 million domains and billions of pieces of mail a day? (Hint - a centralized server of *any* sort doesn't work, and even DNS is *barely* distributed enough. If you use DNS for your scheme, make sure to think about things like lame delegations, timeouts, and similar, and what they do to workability and perfomance). 6) Examine how your scheme works for actual operational deployment. The two most common questions are: (a) Does it Do The Right Thing with mailing lists, and (b) Does it Do The Right Thing for "Aunt Tillie"? 7) Examine how your scheme works in a non-trusted environment, and note that there's a lot of distrust on *everybody*'s part. Some of us don't trust Verisign (and can point at specific reasons not to, including a CERT advisory), some of us don't trust another country's government, and there's even some that don't trust their own government. (Would you want the US Postal Service to be your e-mail provider? Why or why not? ;) 8) Examine how your scheme works in a worldwide context, paying attention to any legal/legislative/jurisdiction issues. If your solution involves passing a law, explain how you get it to apply to a site in the Cayman Islands or Havenco. 9) Actual operational experience and a thick skin are two large bonuses - if an idea isn't scalable, you may very well be told in excruciating detail why it *won't* work for an AOL-sized site by somebody who knows what *does* work for that sized site because he helped design it.... (And that list is a good explanation of why the ASRG hasn't come up with The Grand Solution either... :)
Attachment:
_bin
Description:
Current thread:
- Improving E-mail security... Bengt Ruusunen (Aug 26)
- Re: [LONG] Improving E-mail security... lceone () comcast net (Aug 26)
- Re: [LONG] Improving E-mail security... Ron DuFresne (Aug 27)
- Re: [LONG] Improving E-mail security... Valdis . Kletnieks (Aug 27)
- <Possible follow-ups>
- RE: Improving E-mail security... Leif Sawyer (Aug 26)
- RE: Improving E-mail security... Eric Wagner (Aug 27)
- Re: Improving E-mail security... I.R.van Dongen (Aug 27)
- Re: [LONG] Improving E-mail security... lceone () comcast net (Aug 26)