ietf-asrg
[Top] [All Lists]

[Asrg] Re:Proposals: First draft of the ASRG-RMX Discussion paper

2003-11-07 12:50:31
I'm new to ASRG but have just read the above draft paper. The idea of LMAP 
(Lightweight MTA Authentication Protocol) makes a lot of sense to me, and I 
hope this can move quickly forward.

Congratulations to Alan DeKok, Raymond Brand, Hadmut Danisch, Gordon Fecyk, 
Richard Rognlie, Lauerence Sherzer, and Meng Weng Wong! All of you and anyone 
else not mentioned who has played a major part in getting this to a stage where 
it can move forward also should be credited. I hope it moves forward with ASRG 
support and finds major support in IETF. It may not solve all the worlds 
problems, it may not be perfect, but it's a major step in the right direction!

Ian Peter
--- Begin Message ---
Send Asrg mailing list submissions to
        asrg(_at_)ietf(_dot_)org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www1.ietf.org/mailman/listinfo/asrg
or, via email, send a message with subject or body 'help' to
        asrg-request(_at_)ietf(_dot_)org

You can reach the person managing the list at
        asrg-admin(_at_)ietf(_dot_)org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Asrg digest..."


Today's Topics:

   1. Re: 2a. Analysis - Changed patterns in spamming? (Kurt Magnusson)
   2. Re: Re: 2a. Analysis - Changed patterns in spamming? (Andreas Saurwein)
   3. Re: Re: 2a. Analysis - Changed patterns in spamming? (Mark E. Mallett)
   4. 3. Requirements - Accessibility - W3C draft published (Yakov Shafranovich)
   5. Re: 6. Proposals: First draft of the ASRG-RMX Discussion paper (Yakov 
Shafranovich)
   6. 6. Proposals - Turing Tests - News Article on Exploits (was Re: [Asrg]
       3. Requirements - Accessibility - W3C draft published) (Yakov 
Shafranovich)
   7. Re: 1. Inventory of Problems - Input Needed (Jon Kyme)
   8. Re: 1. Inventory of Problems - Input Needed (Yakov Shafranovich)
   9. Re: 1. Inventory of Problems - Input Needed (David Maxwell)
  10. Re: 1. Inventory of Problems - Input Needed (Yakov Shafranovich)
  11. Re: 1. Inventory of Problems - Input Needed (Yakov Shafranovich)
  12. Re: 1. Inventory of Problems - Input Needed (David Maxwell)
  13. Re: 2a. Analysis - Changed patterns in spamming? (Fridrik Skulason)
  14. Re: Re: 2a. Analysis - Changed patterns in spamming? (Yakov Shafranovich)
  15. Re: 1. Inventory of Problems - Input Needed (Eric Allman)
  16. Re: 1. Inventory of Problems - Input Needed (Andrew Akehurst)
  17. Re: 1. Inventory of Problems - Input Needed (Andrew Akehurst)
  18. Re: 1. Inventory of Problems - Input Needed (Alan DeKok)

--__--__--

Message: 1
From: "Kurt Magnusson" <kmn_asgr(_at_)hotmail(_dot_)com>
To: asrg(_at_)ietf(_dot_)org
Subject: [Asrg] Re: 2a. Analysis - Changed patterns in spamming?
Date: Thu, 06 Nov 2003 16:01:44 -0300

I took this up around Oct. 15, but never got any response at that time.

While looking at some statistics in my incoming spam, I noticed that the ca 
50% of korean spams I had for the last 1.5 year have dropped to nearly zero 
around Oct. 1. All .kr domains is gone and the asian spam I see is from non 
asian domains.

Question is if the new spam laws in Korea have had an effect or if I just 
see the result of filtering on some trunk line between Europe and Korea?

For if this is a global effect, koreans stopped spamming (ok, ok, but it is 
soon Fathers Day, and this would be better than the tie I never use ;-), the 
antispam community have to consider the impact of legal actions, with the 
new EU law getting in place, definitively marking NA/SA spammers as the main 
culprits.

If not and it is just a local effect, which ISP installed this effective 
filter and how many countries are affected? Might mean that trunk line 
filtering should be considered.

Kurt Magnusson

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus



--__--__--

Message: 2
Date: Thu, 06 Nov 2003 17:10:54 -0200
To: asrg(_at_)ietf(_dot_)org
From: Andreas Saurwein <saurwein(_at_)uniwares(_dot_)com>
Subject: Re: [Asrg] Re: 2a. Analysis - Changed patterns in spamming?

At 6/11/2003 17:01 Thursday, you wrote:
While looking at some statistics in my incoming spam, I noticed that the 
ca 50% of korean spams I had for the last 1.5 year have dropped to nearly 
zero around Oct. 1. All .kr domains is gone and the asian spam I see is 
from non asian domains.

While I cant say that my personal account ever received lots of it (3-5 by 
month), it definitely is down almost 0 but it comes from asian domains.

Andreas 



--__--__--

Message: 3
From: "Mark E. Mallett" <mem(_at_)mv(_dot_)mv(_dot_)com>
Date: Thu, 6 Nov 2003 14:19:14 -0500
To: Kurt Magnusson <kmn_asgr(_at_)hotmail(_dot_)com>
Cc: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] Re: 2a. Analysis - Changed patterns in spamming?

On Thu, Nov 06, 2003 at 04:01:44PM -0300, Kurt Magnusson wrote:
I took this up around Oct. 15, but never got any response at that time.

Question is if the new spam laws in Korea have had an effect or if I just 
see the result of filtering on some trunk line between Europe and Korea?

Could be just a change in spammer operations.  Personally I am seeing
less spam via open SMTP relays and more spam via slave machines.  These
days when we get spam barrages, it's a few messages from one IP address,
a few from another, over hundreds of sources.  Some months ago the
pattern was different, where a particular batch of spam would come from
just a few different sources.

mm


--__--__--

Message: 4
Date: Thu, 06 Nov 2003 14:21:22 -0500
From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
To: asrg(_at_)ietf(_dot_)org
Organization: SolidMatrix Technologies, Inc.
Subject: [Asrg] 3. Requirements - Accessibility - W3C draft published

The WAI Protocols and Formats Working Group of the World Wide Consortium 
(W3C) has published a working draft on Turing tests and accessibility 
issues. This is in particular very relevant to C/R systems. The current 
version of the draft is available at:

http://www.w3.org/TR/turingtest/

Comments are welcome and we need to also figure out how this is relevant 
to our requirements.



--__--__--

Message: 5
Date: Thu, 06 Nov 2003 14:43:03 -0500
From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
Subject: Re: [Asrg] 6. Proposals: First draft of the ASRG-RMX Discussion paper
To: Alan DeKok <aland(_at_)ox(_dot_)org>
Cc: asrg(_at_)ietf(_dot_)org
Organization: SolidMatrix Technologies, Inc.

Alan DeKok wrote:
  I've posted the first draft of the ASRG-RMX discussion paper on the
combined proposal to the ASRG-RMX list.  It's available on gmane, at:

      http://article.gmane.org/gmane.ietf.asrg.rmx/260

  I do not currently have sufficient time to discuss or defend the
document.  If there are errors of fact, please email me with
references, and suggested replacement text.

  Any flames will be archived for later amusement.


This document is available for download at the ASRG's wotksite at the 
following URL:

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



--__--__--

Message: 6
Date: Thu, 06 Nov 2003 14:56:12 -0500
From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
To: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
Cc: asrg(_at_)ietf(_dot_)org
Organization: SolidMatrix Technologies, Inc.
Subject: [Asrg] 6. Proposals - Turing Tests - News Article on Exploits (was Re: 
[Asrg]
 3. Requirements - Accessibility - W3C draft published)

Yakov Shafranovich wrote:
The WAI Protocols and Formats Working Group of the World Wide Consortium 
(W3C) has published a working draft on Turing tests and accessibility 
issues. This is in particular very relevant to C/R systems. The current 
version of the draft is available at:

http://www.w3.org/TR/turingtest/

Comments are welcome and we need to also figure out how this is relevant 
to our requirements.


Just to add something to this, Matt McCay who is the author of this 
draft, posted a reference on his weblog about how a spammer was able to 
get human volunteers to visit a porn site and defeat the CAPTHAS. The 
weblog comment is here:

http://www.bestkungfu.com/archive/?id=257

and the original article here:

http://www.post-gazette.com/pg/03278/228349.stm

Relevant quote:

--------snip---------
But at least one potential spammer managed to crack the CAPTCHA test. 
Someone designed a software robot that would fill out a registration 
form and, when confronted with a CAPTCHA test, would post it on a free 
porn site. Visitors to the porn site would be asked to complete the test 
before they could view more pornography, and the software robot would 
use their answer to complete the e-mail registration.
--------snip---------



--__--__--

Message: 7
Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed 
To: "ASRG" <asrg(_at_)ietf(_dot_)org>
From: "Jon Kyme" <jrk(_at_)merseymail(_dot_)com>
Date: Thu, 06 Nov 2003 20:20:31 +0000

AD wrote:
  I believe that social issues (like lying about opt-in) should be
outside of the scope of this group.  

Right.


Currently, the charter
is vague, and very unhelpful.  

I can't agree with that. Generalising the problem as a consent / policy /
enforcement thing means we don't start by talking about spam, spammers and
what spammers do. We just (!) need to identify opportunities for
(recipients) policy expression, transmission and enforcement in (or
alongside) the MTS. This isn't vague (it may not be what a lot of people
want to see) and I don't see why this can't be helpful.

For instance, C/R and and other Consent-token schemes don't know anything
much about *spam* and the only thing they assume about *spammers* is that
the business model precludes the human or other resources required to get
through.

A filtering system based on the use of a filtering engine doesn't know
anything about the content of *spam* except that it differs somewhat from
*non-spam* (the particular engine used will know more than this).



Witness the huge volume on the list,
for the first few months.  Most of that volume was caused by people
talking at cross purposes, because no one agreed on a problem
statement.

I agree somewhat. As I remember, much of the traffic was produced by people
touting their own silver bullets or, like you say, talking at cross
purposes - because they weren't using the consent model.








--


--__--__--

Message: 8
Date: Thu, 06 Nov 2003 15:29:27 -0500
From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed
To: Jon Kyme <jrk(_at_)merseymail(_dot_)com>
Cc: ASRG <asrg(_at_)ietf(_dot_)org>
Organization: SolidMatrix Technologies, Inc.

Jon Kyme wrote:
AD wrote:

Currently, the charter
is vague, and very unhelpful.  


I can't agree with that. Generalising the problem as a consent / policy /
enforcement thing means we don't start by talking about spam, spammers and
what spammers do. We just (!) need to identify opportunities for
(recipients) policy expression, transmission and enforcement in (or
alongside) the MTS. This isn't vague (it may not be what a lot of people
want to see) and I don't see why this can't be helpful.


It is hard to explain consent to someone when all the legal efforts are 
talking about consent. People tend to misunderstand the concept. 
However, I think that both of you are right - we need to look at what 
spam and spammers do AND at how we start looking at the entire email 
system as one with consent.

For instance, C/R and and other Consent-token schemes don't know anything
much about *spam* and the only thing they assume about *spammers* is that
the business model precludes the human or other resources required to get
through.

A filtering system based on the use of a filtering engine doesn't know
anything about the content of *spam* except that it differs somewhat from
*non-spam* (the particular engine used will know more than this).


Do you think that the current draft of the consent framework seems to be 
heading in the right direction?

Draft: http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html




--__--__--

Message: 9
Date: Thu, 6 Nov 2003 15:38:38 -0500
From: David Maxwell <david(_at_)crlf(_dot_)net>
To: Jon Kyme <jrk(_at_)merseymail(_dot_)com>
Cc: ASRG <asrg(_at_)ietf(_dot_)org>
Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed

On Thu, Nov 06, 2003 at 08:20:31PM +0000, Jon Kyme wrote:
Alan DeKok wrote:
Currently, the charter
is vague, and very unhelpful.  

I can't agree with that. Generalising the problem as a consent / policy /
enforcement thing means we don't start by talking about spam, spammers and
what spammers do.

I agree with John, that the charter is helpful. However, I agree with
Alan, that the charter is vague.

I see what Alan proposed as a set of use cases for messaging.

Once you have them, you can identify which use cases are abused by
spammers. You can look at which proposed solutions affect which cases.
You can look at which cases suffer side-effects from each proposal.
Instead of 'A is better than B', you get to 'A fixes 1,2,3 - B fixes
3,4,5 - seems that we need a bit of both'.

 We just (!) need to identify opportunities for
(recipients) policy expression, transmission and enforcement in (or
alongside) the MTS. This isn't vague (it may not be what a lot of people
want to see) and I don't see why this can't be helpful.

A set of use cases would allow definition of trust diagrams, which would
show which attributes of the communication are trustworthy at each
transition (between hosts/organizations/programs/protocols). It's not
that what you said can't be helpful - I think it needs to be more
specific.

For instance, C/R and and other Consent-token schemes don't know anything
much about *spam* and the only thing they assume about *spammers* is that
the business model precludes the human or other resources required to get
through.

A filtering system based on the use of a filtering engine doesn't know
anything about the content of *spam* except that it differs somewhat from
*non-spam* (the particular engine used will know more than this).

It's possible that some sub-set of the solutions affect all the use
cases equally. Their side-effects probably effect all uses-cases equally
as well.

-- 
David Maxwell, david(_at_)vex(_dot_)net|david(_at_)maxwell(_dot_)net --> The 
only difference I see
between voodoo and marketing research is that voodoo sometimes works! 
                                                - Leonard Stern 




--__--__--

Message: 10
Date: Thu, 06 Nov 2003 15:35:09 -0500
From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed
To: Fridrik Skulason <frisk(_at_)f-prot(_dot_)com>
Cc: asrg(_at_)ietf(_dot_)org
Organization: SolidMatrix Technologies, Inc.

Fridrik Skulason wrote:
I just read through the "Inventory of problems" document, and I have a few
comments.  Some of those comments reflect my anti-virus background, and the
increasing connection I am seeing between viruses and spam.

I have three separate comments on the document.

First I would like to add one problem - the issue of "unintentional" spam
generated by incorrectly configured mail filters.

I have brought this subject up elsewhere - see for examply my open letter
in http://www.f-prot.com/news/gen_news/open_letter_10sept2003.html
....snip....

The following Internet draft seems to touch on the same subject:

http://www.ietf.org/internet-drafts/draft-moore-auto-email-response-04.txt

.....snip.....

My third point involves the "Fraud & Crime" section, where I suggest adding
two more types of spam scams.

   First, stock manipulation.  There are spammers that attempt to push 
   various penny stocks (most recently TRHL, PFDE and AZAA). I have done
   some analysis on activity of the stocks in question and it is very
   interesting to observe the increased trading volume in the weeks prior
   to the spamming (presumably when the spammer is accumulating shares).

   The second common category is the lottery scam - typically mails with
   subjects like "YOU ARE A WINNER OF US$2.5MILLION LOTTO"
........snip........

We need to rethink whether to include "social" and "legal" issues in the 
inventory of problems. On one hand, we are a technical group and are not 
considering legal issues, on the other hand without some of these 
issues, the picture may be incomplete.

Yakov



--__--__--

Message: 11
Date: Thu, 06 Nov 2003 15:45:30 -0500
From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed
To: David Maxwell <david(_at_)crlf(_dot_)net>
Cc: Jon Kyme <jrk(_at_)merseymail(_dot_)com>, ASRG <asrg(_at_)ietf(_dot_)org>
Organization: SolidMatrix Technologies, Inc.

David Maxwell wrote:

On Thu, Nov 06, 2003 at 08:20:31PM +0000, Jon Kyme wrote:

Alan DeKok wrote:

Currently, the charter
is vague, and very unhelpful.  

I can't agree with that. Generalising the problem as a consent / policy /
enforcement thing means we don't start by talking about spam, spammers and
what spammers do.


I agree with John, that the charter is helpful. However, I agree with
Alan, that the charter is vague.

I see what Alan proposed as a set of use cases for messaging.


Someone already wrote a document with a set of use cases! See this message:

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg07695.html

The document is available at:

http://studenti.lboro.ac.uk/~coada/project/usecases.pdf

We need to think how that can be intergrated with the inventory of 
problems work.



--__--__--

Message: 12
Date: Thu, 6 Nov 2003 15:57:15 -0500
From: David Maxwell <david(_at_)crlf(_dot_)net>
To: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
Cc: Jon Kyme <jrk(_at_)merseymail(_dot_)com>, ASRG <asrg(_at_)ietf(_dot_)org>
Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed

On Thu, Nov 06, 2003 at 03:45:30PM -0500, Yakov Shafranovich wrote:
David Maxwell wrote:
I see what Alan proposed as a set of use cases for messaging.

Someone already wrote a document with a set of use cases! See this message:

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg07695.html
http://studenti.lboro.ac.uk/~coada/project/usecases.pdf

We need to think how that can be intergrated with the inventory of 
problems work.

It can certainly be used. I don't think it's quite specific enough for
the final version - as we need to cover protocol specific issues.

In other words, the use cases there will need to be split into each
method that a user currently has available for delivering a message
appropriate to that use case.

-- 
David Maxwell, david(_at_)vex(_dot_)net|david(_at_)maxwell(_dot_)net -->
(About an Amiga rendering landscapes) It's not thinking, it's being artistic!
                                              - Jamie Woods



--__--__--

Message: 13
Date: Fri, 7 Nov 2003 00:10:30 +0000
From: Fridrik Skulason <frisk(_at_)f-prot(_dot_)com>
To: asrg(_at_)ietf(_dot_)org
Subject: [Asrg] Re: 2a. Analysis - Changed patterns in spamming?

I posted a reply on this subject earlier today, mentioning some analysis
I had done on the spam reaching my spamtraps, which get around 3000
spams per day.

Analysis of the Content-Type charset revealed a sharp (around 95%)
drop in the number of Korean messages around October 1st, but a 
gradual increase in the number of Chinese messages for the last 6
months.

However, in my post I made one mistake - I mentioned the actual
names of the charsets ;-)

This caused the ietf.org spam blocker to kick in and reject my 
message:

   **************** eManager Notification *****************

   The following mail was blocked since it contains sensitive content.

   Source mailbox: <frisk(_at_)f-prot(_dot_)com>
   Destination mailbox(es): asrg(_at_)ietf(_dot_)org
   Policy: Non-English Trap
   Action: Quarantine

   To prevent excessive spam abuse, non-English character sets 
   have been blocked at www.ietf.org.  The IETF Secretariat's
   official language of operation is English - although the 
   message you have sent was proper, your mail composer's 
   settings specified an Asian 'charset'  which is widely 
   used by spam abusers.  To permit your message (and confirm
   human response),  please include the keyword:  ' spamcontrol '
   somewhere in your message.  We apologize for any inconvenience
   this may cause.

   ******************* End of message *********************

This is wrong, of course - the message charset was not an asian
one, but the names of several Asian charsets were included in
the message body.  It seems this was enough to trigger the
spam filter - it is not sufficiently intelligent to search only
for the offending charsets within Content-Type.

Slightly off-topic, but a bit funny ;-)

--
Fridrik Skulason   Frisk Software International   phone: +354-540-7400
Author of F-PROT   E-mail: frisk(_at_)f-prot(_dot_)com       fax:   
+354-540-7401



--__--__--

Message: 14
Date: Thu, 06 Nov 2003 19:44:18 -0500
From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
Subject: Re: [Asrg] Re: 2a. Analysis - Changed patterns in spamming?
To: Fridrik Skulason <frisk(_at_)f-prot(_dot_)com>
Cc: asrg(_at_)ietf(_dot_)org
Organization: SolidMatrix Technologies, Inc.

That's strange since according to the IETF anti-spam guidelines 
(http://www.ietf.org/spamcontrol.html), we are supposed to be exempt 
from ALL anti-spam policies. I have notified the IETF Mail administrator.

Fridrik Skulason wrote:
I posted a reply on this subject earlier today, mentioning some analysis
I had done on the spam reaching my spamtraps, which get around 3000
spams per day.

Analysis of the Content-Type charset revealed a sharp (around 95%)
drop in the number of Korean messages around October 1st, but a 
gradual increase in the number of Chinese messages for the last 6
months.

However, in my post I made one mistake - I mentioned the actual
names of the charsets ;-)

This caused the ietf.org spam blocker to kick in and reject my 
message:

   **************** eManager Notification *****************

   The following mail was blocked since it contains sensitive content.

   Source mailbox: <frisk(_at_)f-prot(_dot_)com>
   Destination mailbox(es): asrg(_at_)ietf(_dot_)org
   Policy: Non-English Trap
   Action: Quarantine

   To prevent excessive spam abuse, non-English character sets 
   have been blocked at www.ietf.org.  The IETF Secretariat's
   official language of operation is English - although the 
   message you have sent was proper, your mail composer's 
   settings specified an Asian 'charset'  which is widely 
   used by spam abusers.  To permit your message (and confirm
   human response),  please include the keyword:  ' spamcontrol '
   somewhere in your message.  We apologize for any inconvenience
   this may cause.

   ******************* End of message *********************

This is wrong, of course - the message charset was not an asian
one, but the names of several Asian charsets were included in
the message body.  It seems this was enough to trigger the
spam filter - it is not sufficiently intelligent to search only
for the offending charsets within Content-Type.

Slightly off-topic, but a bit funny ;-)




--__--__--

Message: 15
Date: Thu, 06 Nov 2003 15:57:04 -0800
From: Eric Allman <eric+asrg(_at_)sendmail(_dot_)org>
To: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>,
        David Maxwell <david(_at_)crlf(_dot_)net>
cc: Jon Kyme <jrk(_at_)merseymail(_dot_)com>, ASRG <asrg(_at_)ietf(_dot_)org>
Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed

| The document is available at:
|
| http://studenti.lboro.ac.uk/~coada/project/usecases.pdf

I believe this (quite good) document misses at least one very 
important use case:  Sender Alice (alice(_at_)example(_dot_)com) sends a 
message 
to Bob (bob(_at_)somewhere(_dot_)org), but he has a new account and has 
forwarded his old address to his new address (xyzzy(_at_)foobar(_dot_)edu).

eric


--__--__--

Message: 16
Date: Fri,  7 Nov 2003 12:36:12 +0000
From: Andrew Akehurst 
<A(_dot_)D(_dot_)Akehurst-99(_at_)student(_dot_)lboro(_dot_)ac(_dot_)uk>
To: Eric Allman <eric+asrg(_at_)sendmail(_dot_)org>
Cc: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>,
        David Maxwell <david(_at_)crlf(_dot_)net>, Jon Kyme 
<jrk(_at_)merseymail(_dot_)com>,
        ASRG <asrg(_at_)ietf(_dot_)org>
Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed

Quoting Eric Allman <eric+asrg(_at_)sendmail(_dot_)org>:

| The document is available at:
|
| http://studenti.lboro.ac.uk/~coada/project/usecases.pdf

I believe this (quite good) document misses at least one very 
important use case:  Sender Alice (alice(_at_)example(_dot_)com) sends a 
message 
to Bob (bob(_at_)somewhere(_dot_)org), but he has a new account and has 
forwarded his old address to his new address (xyzzy(_at_)foobar(_dot_)edu).

Ah, many thanks... Someone else had separately pointed this out to me. I
shall add it as an additional scenario.

I've been getting behind with my ASRG mail, but will make a more determined
effort to catch up :-)

Andrew



--__--__--

Message: 17
Date: Fri,  7 Nov 2003 12:47:06 +0000
From: Andrew Akehurst 
<A(_dot_)D(_dot_)Akehurst-99(_at_)student(_dot_)lboro(_dot_)ac(_dot_)uk>
To: David Maxwell <david(_at_)crlf(_dot_)net>
Cc: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed


http://studenti.lboro.ac.uk/~coada/project/usecases.pdf

We need to think how that can be intergrated with the inventory of 
problems work.

It can certainly be used. I don't think it's quite specific enough for
the final version - as we need to cover protocol specific issues.

In other words, the use cases there will need to be split into each
method that a user currently has available for delivering a message
appropriate to that use case.

I think I understand what you mean, but could you perhaps give a more
specific example?

The problem I've found in writing those scenarios was that there is a huge
number of configuration permutations. Hence they're currently rather
general. Any suggestions for how to manage the complexity in generating a
large number of similar (but subtly different) scenarios would be appreciated. 

I had considered rewriting the document in the form of a table whose columns
represent different aspects of the scenario and whose rows correspond to
each scenario, e.g.:

Sender address | Recipient address | Forwarding? | Mailing list?
----------------------------------------------------------------
alice(_at_)a(_dot_)com    | bob(_at_)b(_dot_)com         | No          | No
alice(_at_)a(_dot_)com    | bob(_at_)b(_dot_)com         | Yes, by Bob | No

Given suitable explanations of what each column means this might make it
more manageable. Any thoughts?

At the moment the document isn't very good, but given some more work and
ideas I'm sure it can be improved.

Thanks

Andrew


--__--__--

Message: 18
From: "Alan DeKok" <aland(_at_)ox(_dot_)org>
To: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed 
Date: Fri, 07 Nov 2003 10:43:29 -0500

Andrew Akehurst 
<A(_dot_)D(_dot_)Akehurst-99(_at_)student(_dot_)lboro(_dot_)ac(_dot_)uk> wrote:
In other words, the use cases there will need to be split into each
method that a user currently has available for delivering a message
appropriate to that use case.

I think I understand what you mean, but could you perhaps give a more
specific example?

  My take on it is that your document talks about what the users do,
and what their intentions are.  I'm a protocol guy, so I don't have
access to the users intentions.  Therefore, the diagrams I need are
diagrams of network boxes, and the protocols they use to interact.

  That is, machines on the network don't see intentions.  They see data.

  When "bob" sends "alice" email, he may do so through any number of
methods.  Roaming, webmail, ISP, vpn, etc.  All of those scenarios
have the same intentions, but they also have drastically different
implementation diagrams.

I had considered rewriting the document in the form of a table whose columns
represent different aspects of the scenario and whose rows correspond to
each scenario, e.g.:

Sender address | Recipient address | Forwarding? | Mailing list?
----------------------------------------------------------------
alice(_at_)a(_dot_)com    | bob(_at_)b(_dot_)com         | No          | No
alice(_at_)a(_dot_)com    | bob(_at_)b(_dot_)com         | Yes, by Bob | No

  Again, you're focussing on intentions.  This makes it difficult to
figure out what to do.  It also makes it difficult to talk about it on
the list, as the situations are wide-open for personal
interpretation.  "Well, MY mailing list works, and YOURS doesn't, so I
don't see why you would want to change anything..."

  Keeping things on a protocol level means that personal issues are
largely avoided.  It also means that you have something concrete to
talk about: "Box A talks to box B, using protocol C, which has fields
D, E, and F, used to send messages.  Field F can be forged
undetectably, so we propose solution G to address that forgery..."


  In contrast, a "mailing list" means many different things to
different people.  Such lists are implemented and configured
differently, all due to the intentions of the administrator.  This
means that no one can agree on the definition of a "mailing list", as
everyone uses them in slightly different manners.

  Alan DeKok.



--__--__--

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg


End of Asrg Digest

--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>
  • [Asrg] Re:Proposals: First draft of the ASRG-RMX Discussion paper, ipeter(_at_)bigpond(_dot_)net(_dot_)au <=