Subject: [Asrg] alok - encrypted email

From: Alok Menghrajani <[email-masked]>
Date: Sun, 4 Jan 2004 16:07:43 +0100 (MET)

Hi,

Would using encrypted email affect spam ?

Alok.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Philip Miller <[email-masked]>
Date: Sun, 04 Jan 2004 19:31:54 -0500

> Would using encrypted email affect spam ?

It can make whitelisting much, much easier, if seeing a message signed with 
a known key means that message isn't spam. However, unless you intend to get 
every user on the internet signing and/or encrypting their mail, you can't 
block anything on that basis. All you could do is throw the statistics about 
signed vs. unsigned messages into the Bayesian toekn bin with everything else.

Philip Miller

---

From: Alok Menghrajani <[email-masked]>
Date: Mon, 5 Jan 2004 21:31:23 +0100 (MET)

Hi All,

has anyone already thought of this: for every pair of email addresses, a
unique id is generated.

Once people have setup (exchanged) these unique ids, they can send emails
to each other be being "pretty sure" that the emails are not spam. This
way if I pretend to be [email-masked], until and unless I don't
know what the unique id is, you will know I'm pretending to be
[email-masked] (and this probably spam). It's kind of the idea
behind public key cryptography, that create a symetric key, except that
the goal here is not to encrypt mail, and that the unique id can be kept
for a long period of time. (the unique id is of course sent in each email,
actually the unique id would be the seed of a random number generator, and
each email will have the next random number in one of it's header).

I don't know what would be the best way to exchange these unique id's,
perhaps something like what I talked in my previous emails (each person
performs a calculation), or it could just be based on plain text (until
and unless we don't exchange the id's, our mails won't be automatically
marked 'clean').

I know this list is about improving the current mail protocols, sorry
if any of my questions/suggestions are completly off topic.

Btw, can someone explain me why the email protocol uses relays (and why
the sender doesn't connect directly to the receiver's server) ? Is there
an advantage of having such an architecture today ?

Alok.

PS: I really like this list's archive, I think it's really rich in
content. I would like to thank everyone who has contributed to this list.

---

From: Philip Miller <[email-masked]>
Date: Mon, 05 Jan 2004 17:06:58 -0500

> has anyone already thought of this: for every pair of email addresses, a

There have been similar proposals in the past, yes, although most of them 
have brought cryptography in basically because there's little reason not to.

> each email will have the next random number in one of it's header).

Little nit: that's *NOT* public key cryptography. Public key cryptography is 
where one can encrypt without having a shared secret, like this unique ID.

The major problem with this is that a great many emails are not 1 to 1 
messages. This one, for example, it addressed to you, and thus would have a 
unique ID between us embedded in its headers, but it's being copied to the 
list, where anyone could get it and forge messages between us. That's why 
public key cryptography is so powerful: even with access to massive numbers 
of signed messages, it's still theoretically 'hard' to compute the signing key.

> and unless we don't exchange the id's, our mails won't be automatically

If you want to use a system like that, it's already been implemented in 
stronger cryptographic form with pgp and its free software reimplementation, 
gpg. That includes the infrastructure to distribute signature and encryption 
keys.

> if any of my questions/suggestions are completly off topic.

It's all seemed pretty much on topic so far, although some of this has been 
discussed in the past. My one suggestion is to follow the posting guidlines 
of prepending a subject area to the subject line, like "0. General" or "6. 
Proposals"

> an advantage of having such an architecture today ?

For various structural reasons, it's necessary, and I wouldn't say it's 
particularly evil. There is really nothing that can be done with end-to-end 
that can't be done with relays, it just may require a little more thought at 
times.

Philip Miller

---

From: "Za'mbori, Zolta'n" <[email-masked]>
Date: Mon, 05 Jan 2004 23:23:07 +0100

> has anyone already thought of this: for every pair of email addresses, a

Similar to TMDA. ( http://www.tmda.net/config-client.html )

"[email-masked]

This particular sender address will only accept messages from 
[email-masked] ."

> an advantage of having such an architecture today ?

IMHO email is designed to be an asynchron network. Relays must storing 
messages immediately and forwarding later when resources (bandwidth 
and/or connection) are available. For example over a dial-up telephone 
line after working hours.

The advantage is that network (infra)structure can be enforced (again). 
Enforced routing/relaying path means that the "cable" can be cut and the 
bad guys will be disconnected from the net.

z2

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 05 Jan 2004 17:44:35 -0500

Philip Miller <[email-masked]> wrote:
> list, where anyone could get it and forge messages between us.

  That's easily solved, so long as there's a web of trust between
originator and final recipient.  e.g.  Something like Yahoo's DK, but
signed on a sender/recipient pair:

  originator: X-Magic-Header = nonce + sign(nonce, originator, list)
  list: X-Magic-Header = nonce2 + sign(nonce2, list, list-sender)
  list-sender: X-Magic-Header = nonce3 + sign(nonce3, list-sender, recipient)

  This does mean that every message suddenly becomes unique, which has
issues for multiple RCPT TO's.  The alternative is to supply the
signing information in the SMTP envelope, along with the RCTP TO
(somehow).

  Provided the signing keys are per-MTA, and the chain of signatures
is maintained, every message would then be traceable and thus
accountable.  Whether this method would do anything to stop spam is
another question.

  Alan DeKok.