Subject: RE: [Asrg] 4d. Consent Framework - Is it the only way?

From: Paul Judge <[email-masked]>
Date: Wed, 1 Oct 2003 21:25:33 -0400

> -----Original Message-----
> From: Yakov Shafranovich [mailto:[email-masked]] 
> Sent: Wednesday, October 01, 2003 4:30 PM
> To: ASRG list
> Subject: [Asrg] 4d. Consent Framework - Is it the only way?
> 
> 
> I want to pose a question to the group. The charter of the ASRG 
> concentrates on the notion of consent for email. However, we need to 
> look at whether this is the only approach to controlling spam:
> 
> "The research group will investigate the feasibility of: (1) a single 
> architecture that supports this and (2) a framework that allows 
> different systems to be plugged in to provide different pieces of the 
> solution. "
> 
> Even if the consent framework is completed, is it really the 
> only way to 
> look at spam? Perhaps, we should as many have suggested, 
> reformulate the 
> charter of the group to be more generic - to perhaps look at other 
> possibilities beside consent. 

Consent-based communication approach was proposed as a generalization of the
problem and based on the broader focus allowed by defining spam as unwanted
messages. When you say other possibilities, are you suggesting more specific
views or a more generalized view? Such as what?

We had, I believe, this very same conversation on the mailing list about
three months ago. Please see: http://article.gmane.org/gmane.ietf.asrg/4830

> As of now the charter does include this:
> 
> "ASRG will investigate the spam problem as a large-scale network 
> problem. The ASRG will begin its work by developing a taxonomy of the 
> problem and the proposed solutions. This taxonomy should 
> involve casting 
> the spam problem into different perspectives, such as examining the 
> similarities between spam and denial-of-service; spam and intrusion 
> detection/prevention; and spam and authentication, authorization, and 
> accounting."
> 
> I think we would need another effort to take place parallel with the 
> consent framework - an evaluation of whether it is proper to 
> add consent 
> to email.

What do you mean by "whether it is proper to add consent to email"?

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 01 Oct 2003 22:02:57 -0400

> What do you mean by "whether it is proper to add consent to email"?

The current email system does not have the notion of consent built in 
unlike IM systems. An email message being sent via SMTP is usually 
delivered at its destination, and the receiver usually does not have the 
option of refusing the email until it has been delivered. In the instant 
messaging (IM) world, there is a built in notion of consent as per RFC 
2778. People can refuse having them being added to a buddy list, people 
can block messages, etc (some capabilities only present in some IM 
systems, and some are only theoretical but appear in the RFC).

With the charter and the consent framework, we are inserting the concept 
of consent into email. Now suddenly email does not get to its 
destination - rather its dissected by anti-spam tools depending on the 
receiver's consent. Is this the only correct view of the situation? 
There have been others who are suggesting that perhaps it is not 
necessary to introduce consent into email since the side-effects and 
breakdown in communications will be too great. Rather, the suggestion is 
to look at spam as an engineering issue and leave it at that.

Personally, I feel that the consent approach is correct. However, I 
wanted to float this thought to get a feel if anyone else feels that the 
consent approach is not the correct one, and can provide alternative views.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 02 Oct 2003 14:15:35 -0400

[Please following the posting guidelines, subject has been changed. Mod.]

Meng Weng Wong wrote:
> On Wed, Oct 01, 2003 at 10:02:57PM -0400, Yakov Shafranovich wrote:
> | 
> | Personally, I feel that the consent approach is correct.
> | 
> 
> I agree.  Here is my perspective on the issue.
> 
> Consent-based email is already possible.  Any MTA is free to reject any
> message for any reason.  The problem lies in distinguishing wanted mail
> from unwanted.  There are two parts to this problem.  The first is a
> problem in politics; the second, deception.
> 
> 1) The difference between "wanted" and "unwanted" is a personal decision.
> 
>    Historically, ISPs have had to decide site-wide policies by fiat.
>    Such policies try to do the best thing for the greatest number, and
>    are essentially political: no matter what you do, there is always a
>    minority who'll be guaranteed to be upset.
> 
>    Today it is hard for individual persons to express their preferences
>    at the SMTP front line.
> 
>    The major MTAs are constructed on the philosophy of "be liberal in
>    what you receive."  They did not anticipate that one day they might
>    need to represent their recipients' preferences when talking to the
>    SMTP client.  If one user wants to use one DNSBL, and another user
>    wants to use a different one, too bad.  Everybody eats the same meal.
> 
>    It doesn't have to be that way.  At root, even though its symptoms
>    are social, this is a technical problem with a technical solution.
> 
>    Everybody should not have to do what the majority wants to.
> 
>    Everybody should get to do what they want to do.
> 
>    At Pobox.com we are developing an SMTP proxy, intended for use with
>    Postfix but adaptable to other MTAs, which will perform per-user
>    database lookups.
> 
>    With this technology, individual users can choose their own consent
>    mechanisms such as DNSBLs, RHSBLs, sender address verification,
>    unknown sender domain policy, whitelists, blacklists, you name it.
> 
>    That way, if they're not happy with the defaults, they are free to
>    make their own decisions.  If they don't like blackholes.easynet.nl,
>    they can use sbl.spamhaus.org.  If they don't like sender address
>    verification, they can turn it off or reduce a 5xx reject to an
>    advisory header.
> 
>    That solves the first problem.
> 
> 2) Even if you have comprehensive sender whitelists and blacklists,
>    they are beggared by the problem of forgery.
> 
>    You want to get mail from [email-masked].  Anyone can claim to be
>    [email-masked].  If you whitelist [email-masked], you will
>    get spam.
> 
>    This is also a technological limitation.  RMX/SPF aims at this problem.
> 
>    Widespread adoption of an RMX/SPF strategy by industry leaders will
>    solve the second problem.
> 
> Once we overcome these two obstacles, we can move on to more interesting
> things, like reimagining email and building automated reputation systems.
>

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 02 Oct 2003 14:48:24 -0400

Yakov Shafranovich wrote:

>> | | Personally, I feel that the consent approach is correct.
>> |

The consent framework does not specify where and how the processing take 
place. As I stated in a separate message, that is left to the 
implementors. This can be done on an MTA level with the user specifying 
settings - the more users will demand it, the more ISPs will support it. 
It can also be done by the MUA or via a proxy. The solution you are 
proposing is one of many possibilities.

>> things, like reimagining email and building automated reputation systems.

In the consent framework input can come from many sources. The person's 
email address in a white-list is only one such source. Forgin can be 
mitigated by analyzing the source IP of the message against blacklists, 
sending a C/R message, digitial signatures, RMX, etc. There are many 
solutions possible, all of which will fit within the consent framework 
if there are standards in place for them to work with each other.

Yakov