Subject: Re: [Asrg] Proposal for transition to authenticated email

From: "Ken Hirsch" <[email-masked]>
Date: Thu, 1 May 2003 05:49:38 -0400

Gah! I forgot one other important advantage of my proposal.  End users can get
certificates and use them with current MUA software.  That way they won't be subject
to challenge-response even if they have to send through a non-participating SMTP
server.  The free certificates that just certify your email address would not be
acceptable, but the certificates don't have to be out of reach of individuals.
There has to be some real effort to check real-world identity, plus, as I said in
another message:

A certificate that provides strong identity (e.g. government-issued) is
not by itself sufficient as an antispam certificate.  A CA would have
to (1) check it against a database of known spammers (2) get the person
to sign a contract  to abide by a set of antispam policies and (3) have
a set of procedures to handle complaints against the person (including
reporting the person to the database if they do not cooperate).

> From: "Ken Simpson" <[email-masked]>
> > Instead of certificates, why not just use the Bonded Sender approach and
> > use PTR queries to a whitelist DNS server or group of servers? A quick DNS
> > query is less intensive than cryptography and requires less programming.
> > Besides, running a CA is a huge undertaking.
>
> This is a possibility.  A DNS query may be less computationally intensive,
> but I think it takes more time.  A DNS query would avoid the byte overhead
> of a message signature.
>
> The advantage of cryptographic signatures is they prove that the message was
> sent by the holder of the private key.  This helps prevent malicious
> complaints against a bonded sender.
>
> There are already CAs.  I think that they would work with an organization
> such as TRUSTe rather than try to handle complaints themselves.  They could
> work with more than one organization.  The exact details about certificate
> signing and revocation would need to be worked out.
>
> Other differences of my proposal from the Bonded Sender approach--
>   More than one policy  could be chosen.  Getting consensus on just one is
> hard.
>   Participating servers should require a challenge-response on all mail from
> non-participating servers.
>   Labeling properties of individual messages and senders is encouraged.
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg

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

---

From: "David Koblas" <[email-masked]>
Date: Thu, 1 May 2003 12:05:07 -0700

I've been reading this discussion for a while and I have one core question,
which is why is this an "antispam certificate".  At the end of the day,
we've all got a slightly different idea of what is and isn't acceptable as a
message (yes, there is a very large common ground).

Why not focus on Verifiable/Validated senders and let other systems worry
about the policy for specific senders.  It strikes me that it would be easy
to have a system that adds a single new header "ValidatedSender:
[email-masked]; ...stuff including signature..."  Then other systems could
make a policy decision based on that _verifiable_ header.

This header could/would be inserted at the ISP level, rather than the MUA
level, provided they believed in the senders authenticity (via trust based
systems, SMTP AUTH, etc.).

David
--koblas

---

From: "Ken Hirsch" <[email-masked]>
Date: Thu, 1 May 2003 17:16:49 -0400

From: "David Koblas" <[email-masked]>
> make a policy decision based on that _verifiable_ header.

By itself, it doesn't mean anything.  Every spammer will insert it on their
own and send through an open relay.  A spammer could have 10,000 accounts on
hotmail and each one would be a legitimate hotmail account.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "David Koblas" <[email-masked]>
Date: Thu, 1 May 2003 14:43:33 -0700

Maybe I didn't explain myself fully.

The basic idea is that at the moment we _cannot_ trust any content that is
in an SMTP session (ok, maybe the originating IP address, but that a TCP
thing).  If there was a way in which a single header that would indicate the
true sender of a message, or resender for mailing lists, then systems could
be build which utilize this basic piece of validated information.

In the simplistic case, I cannot whitelist/blacklist any sender or domain
because it's possible to forge this information into a message or envelope.
While a spammer could get their own certificate and sign 100,000 email
messages, it does cause them to both expend time/energy/money in doing so
and also provides a way in which large quantities of messages can be
refused/deleted based on the ability to validate the sender.  You could also
have simple systems that if the sender is "new" that the message is deferred
for some period of time before it's delivered, thus letting probe accounts
create decisions about the message prior to it's final delivery.

David,
--koblas

> > we've all got a slightly different idea of what is and isn't acceptable
as
> a

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 1 May 2003 16:30:09 -0600 (MDT)

> ...
> ...

Why does it matter that the IP address is a TCP thing instead of
an SMTP thing?  What is the difficulty in using TCP things in SMTP?
(none that I can see)

What is the difference between the "true sender" (whatever that is)
and whatever you get from the IP address, and why do you care? 
(I see differences, but none that could be effective for fighting
spam in the real world.)

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