Subject: Re: 4: solution taxonomy; was: RE: 3. Requirements - Anonymity (was Re: FW: [Asrg] 0. General)

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 02 Nov 2003 20:16:43 -0500

All of these discussions point back to the consent framework. We need to 
evaluate whether it is viable to have an infrastructure or architecture 
in place that can tie in all existing and future anti-spam tools and 
methods. If it is indeed possible, then each receiver and his or her 
organization will pick and choose as to what type of tools to use.

Yakov

Bob Atkinson wrote:
> Indeed.
> 
> Myself, I look at it this way.
> 
> RMX and things like it are a minimal *authentication* step that can give
> you reasonable that the mail is from the domain it says it's from. This
> is very valuable, but is indeed only a piece of the picture.
> 
> Beyond that I think we need ways for you to provide in the mail that you
> send positive evidence that the mail isn't spam (having the evidence
> flow with the original message at the get-go means the existing mail
> delivery experience is preserved). When all is said and done, I only
> know of two basic ways to do this:
> 
> 1.	Get someone whose opinion your recipient values to say you are 
> 	a good guy.
> 
> 2.	Do something that it's uneconomical for a spammer to do, and
> show that
> 	you did that.
> 
> The first of these amounts to trading on your reputation; the latter
> amounts to expending some resource on behalf of the message (money, CPU
> cycles, and so on, though lack of a viable micro-payment scheme makes
> using the first of these difficult).
> 
> While not one and the same thing, the authentication and the spam
> deterrence measures are related. For example, domains and their owners
> have reputations: thus, to the extent you can attribute a message to a
> domain, you can ask questions about the reputation of / policies
> associated with the domain, which is likely to be a very interesting
> question. Similarly, if you have an authenticated piece of mail (perhaps
> it's signed) you can reasonably then ask policies about the particular
> sender of the message.
> 
> I think it's also worth noting that the two fundamental approaches above
> are likely to serve quite different audiences.
> 
> More likely that not, it's only the larger organizations / domains which
> will have sufficient reputation so that their mail transmission policies
> can be evaluated and monitored and sufficient money to pay for that
> evaluation. All those small businesses, personal mail servers and other
> small domains out there realistically won't be able to participate.
> 
> On the other hand, it's a happy coincidence that the situation is
> exactly reversed when it comes to the availability of spare CPU cycles:
> the people who send volumes and volumes of mail generally run their
> machines to the hilt. After all, if they have such volume, they have to
> budget and capacity plan the thing, and they don't tend to build in huge
> extra capacity that they don't actually need. On the other hand, the
> machines running the small domains are by and large highly idle, with
> plenty of spare cycles.
> 
> I think it's important that as the industry picks spam deterrence
> measures that we don't end up making 1st and 2nd class senders. No one
> mechanism will be usable by all senders, yet all receivers need to value
> all the mechanisms.
> 
> 	Bob
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hallam-Baker, Phillip
> Sent: Thursday, October 30, 2003 4:09 PM
> To: 'Eric Dean'; 'Alan DeKok'; [email-masked]
> Subject: RE: 3. Requirements - Anonymity (was Re: FW: [Asrg] 0. General)
> 
> 
> 
>>I agree.  RMX would merely allow for me to protect my domain from
>>getting spoofed.  By no means is it an anti-spam method.  
> 
> 
> RMX and SPF do not prevent all spam but they do have the potential to
> eliminate impersonation spam (aka Joe Jobbing). This type of spam is
> particularly serious because it has been used in a series of very
> successful
> identity theft schemes. These include the persistent 'update your
> ebay/amazon/paypal account solicitations and recently a series of emails
> impersonating several banks.
> 
> Impersonation spam creates considerable inconvenience and cost for the
> impersonation victim. In addition to the cost of fielding complaints
> about
> the spam the victim's reputation is damaged. In many cases the
> impersonator
> may steal business from the victim (anti-virus software spam, domain
> name
> registration spam). It is not unusual for a spam to be correct in every
> detail except for the telephone number to contact to give payment.
> 
> 
> Certainly it is possible and useful to go further than IP address/Domain
> Name verification of the type supported in RMX/SPF. But this does
> invalidate
> RMX/SPF infrastructure as a first step. Nor is it tenable to claim that
> RMX/SPF are insufficient and then claim that certificate based schemes
> are
> unnecessary.
> 
> 
> 
> 	Phill
> 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 

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