Message-ID: <200308270437.h7R4b7re011629@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: [LONG] Improving E-mail security... 

On Tue, 26 Aug 2003 23:05:15 EDT, "lceone@...cast.net" <lceone@...cast.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@...f.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... :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030827/19ef9a31/attachment.bin

Powered by blists - more mailing lists