Subject: RE: [Asrg] 6. Proposals - DNS-Based - LMAP

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 12 Nov 2003 16:31:25 -0800

The problem is not simply getting the spec agreed, the harder part is to get
deployment to take place.

The group needs a media strategy, and no, the current situation is not a
strategy.

The key thing to avoid here is to oversell the technology. It is much better
to promise little and deliver some than to promise great things and deliver
merely good results. It is all an expectations game.

LMAP is clearly not going to eliminate all spam, why is it important then?
The answer is that it will eliminate the worst types of spam, impersonation
spam.

The second thing is to make sure that the concepts being communicated are
clear. Please do not talk to journalists about joe jobs, if you are lucky
they will ask you to explain what you mean, more likely they go and publish
something you will regret later, like a story about how you are going to
stop Steve Jobs from sending spam.

The third point is to have a strategy to make sure that the credit for the
work is fairly shared. The media attention is doing this group absolutely no
good as far as the internal workings of the group are concerned.

What is needed here is a set of talking points, and a set of attributed
quotations that journalists can work into their stories. It is not necessary
for everyone to interact with the media directly.

>From my point of view it is currently very difficult for me to comment on
the ASRG work in a way that leads to predictable and favorable media
coverage. 

		Phill

> -----Original Message-----
> From: Yakov Shafranovich [mailto:[email-masked]]
> Sent: Monday, November 10, 2003 9:00 PM
> To: ASRG
> Subject: [Asrg] 6. Proposals - DNS-Based - LMAP
> 
> 
> Just a reminder that a draft of the LMAP discussion document has been 
> posted and is available at:
> 
> http://asrg.kavi.com/apps/group_public/download.php/15/draft-i
rtf-asrg-lmap-discussion-00.txt

 From the abstract:

------------
"  The Lightweight MTA Authentication Protocol (LMAP) [ref] has been
    proposed as a method to help address the spam problem.  That document
    describes the design of the protocol.  This document discusses the
    applicability, and the costs and benefits of wide-spread deployment
    of that protocol."
------------

_______________________________________________
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: Markus Stumpf <[email-masked]>
Date: Thu, 13 Nov 2003 02:06:07 +0100

> deployment to take place.

I'd posted a short note about that problem to the RIPE antispam list.
I'd ask how much (money, time) the postmasters and CEOs would spend
for a solution. Also, how hard it would be to integrate solutions like
e.g. LMAP into their administrative tools.

No response (but one) :(

Without feedback from that people most antispam proposals are probably
academic :(
IMHO it is important to learn how processes that are affected by
antispam proposals are handled in most companies/ISPs. The ease of
integration and the costs involved will be a major criterion about
hop of flop.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: "Dave Atherton" <[email-masked]>
Date: Wed, 12 Nov 2003 20:22:24 -0800

----- Original Message ----- 
From: "Markus Stumpf" <[email-masked]>
Sent: Wednesday, November 12, 2003 5:06 PM
> integration and the costs involved will be a major criterion about
<snip>

A likely first step is to persuade the makers of the most commonly used
affected software to implement the necessary changes.  Once that is
accomplished, I see 2 potential ways to get the new feature put into common
use:

1. Persuade a few major ISPs and private nets to begin using it (and to
encourage or expect others to use it).  This would require some significant
lobbying.  "It's not what you know but who you know."
-OR-
2. Wait until some major event, such as a sharp increase in spam or
joe-jobs, to cause admins and CIOs to ask, "What do we have handy to deal
with this problem?"  Then, the presence of the new feature (such as LMAP) in
existing or commonly available software could be proclaimed and admins would
be inspired to use it.

-Dave

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 12 Nov 2003 23:36:50 -0500

Dave Atherton wrote:
>>>The problem is not simply getting the spec agreed, the harder part is to
> 
> get
> 

We still need work on the discussion draft and even more work on a 
combined protocol spefication. A lot of things are still in raw state, 
and need more work.

Discussion draft available at:
http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap-discussion-00.txt

Yakov

---

From: "Herr Vinny" <[email-masked]>
Date: Wed, 12 Nov 2003 22:38:14 -0600

We're going to wait a long time if we're going to wait for a sharp increase
in spam. Spam is already estimated to be 12 billion+ emails/day, who's going
to notice another billion or two?

Personally, I think it might be better if we persuaded some major ISP's to
take it up. Perhaps create some sort of demo, e.g. load a laptop with
examples of popular mail servers, and demonstrate in front of admins how
easy it is to configure a mail server to use LMAP?

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 12 Nov 2003 23:46:55 -0500

Keep in mind that LMAP has not been fully defined yet.

Herr Vinny wrote:
>>accomplished, I see 2 potential ways to get the new feature put into
> 
> common
> 
>>use:
>>
>>encourage or expect others to use it).  This would require some
> 
> significant
> 
>>with this problem?"  Then, the presence of the new feature (such as LMAP)
> 
> in
> 
>>existing or commonly available software could be proclaimed and admins
> 
> would
> 
>>be inspired to use it.
>>
>>-Dave
>

---

From: "Eric Dean" <[email-masked]>
Date: Fri, 14 Nov 2003 10:28:51 -0500

I'm struggling a little bit in trying to figure out how Turing tests fit
into a fully automated protocol.  For example, with CRI, we are allowing
for a stateful mail system to automatically respond to challenges.
However, I'm not sure where a turing test would apply.  Turig tests are
designed for a human interaction...which is precisely what I am trying
to overcome.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 17 Nov 2003 16:23:48 -0500

> The answer is that it will eliminate the worst types of spam, impersonation

  I'm starting work on an SMTP evaluation document.  It will discuss
why spam is worse in SMTP than any other protocol.  The goal of the
document is to give us concrete reasons as to why spam is such a
problem in SMTP.  Once we know that, we will then know why certain
proposals are useful, and what impact they have on spam, and on
non-spam uses of SMTP.

  Alan DeKok.

---

From: Mark Baugher <[email-masked]>
Date: Mon, 17 Nov 2003 13:50:59 -0800

At 01:23 PM 11/17/2003, Alan DeKok wrote:
>why spam is worse in SMTP than any other protocol.

Which protocols are you comparing it to?

Mark

>The goal of the

---

From: Philip Miller <[email-masked]>
Date: Mon, 17 Nov 2003 18:13:25 -0500

> Which protocols are you comparing it to?

The following are probably the most important to compare to:
NNTP
instant messaging (ICQ, AOL, MSN, YHO, etc.)
cell-phone 'texting'

Did I miss any that are crucial?

--
Philip Miller

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 17 Nov 2003 20:11:22 -0500

> Did I miss any that are crucial?

FYI, IETF's IM protocols are called IMPP, SIP and XMPP.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 18 Nov 2003 11:04:21 -0500

> Which protocols are you comparing it to?

  Instant messaging, etc.  Philip Miller's post listed a few.

  SMTP has characteristics which not only make it amenable to send
spam (as opposed to HTTP, for example), but which makes the spam
problem *worse* in SMTP, than in any other protocol.

  The choices are then to narrow down the possibility of abuse within
SMTP (which slows down spam), or to design a new message delivery
protocol which doesn't have SMTP's flaws.  The biggest problem with
the second choice is not implementation or deployment costs, it's
ensuring that any new protocol does NOT have SMTP's flaws.  And
without a serious analysis of SMTP, all effort put into designing, or
talking about other protocols, is a waste of time.

  Alan DeKok.