headers
Frank Ellermann | 6 Jan 2007 22:11
Picon
Picon

Re: [Fwd: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC]

Tony Hansen wrote on <ietf-822.imc.org>

> fyi, this seems relevant to these two lists.

Thanks, answered on the general list, forwarding your pointer
to the ASRG list.  Maybe I simply don't get it, or the I-D
proposes to send special NDRs for mails considered as dubious
by OPES, and the "special" feature is a way to bypass OPES on
behalf of the (alleged) sender in another mail.

That would be a convoluted kind of challenge response system,
and the discussion of this known 2821 issue in the draft does
not justify this net abuse.

> http://www.ietf.org/internet-drafts/draft-ietf-opes-smtp-security-02.txt

Frank
Permalink | Reply | 0 comments |
headers
John L | 17 Jan 2007 20:36

Opportunity to get involved in the NSF FIND research program

This went out to the IRTF main list.  Anyone want to do some actual 
research?

Regards,
John Levine, johnl <at> iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

Begin forwarded message:

> From: David Clark <ddc <at> csail.mit.edu>
> Date: January 10, 2007 8:08:29 AM PST
> To: End to End Interest <end2end-interest <at> postel.org>
> Subject: [e2e] Opportunity to get involved in the NSF FIND research
> program
>
> Folks,
>     Many of you may know that NSF has announced a focus area for 
> research funding called Future Internet Design, or FIND. The idea behind 
> FIND is to bring together interested researchers to discuss options for 
> a future Internet, and to develop integrated proposals for such a 
> network.
>     NSF understands that there is lots of interesting, relevant work 
> that has been funded from sources other than NSF, and there may be folks 
> who would like to come to the meetings and participate in the process, 
> on a BYOF (Bring Your Own Funding) basis. You might have funding from a 
> different NSF program, from another funding agency, or from your 
> company. Perhaps you are from a different country with its own funding 
> mechanisms.
>     However you are funded, if you are interesting in being part of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Danny Angus | 18 Jan 2007 12:44
Picon
Favicon

Comments: draft-irtf-asrg-criteria-00.txt

At:
http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.txt

You will find a document which outlines an idea I've had for a while.
Please give me your comments on this list.

The thrust of the document is that while we don't know what the silver
bullet solution for spam is we do know some of the characteristics
which we expect it to exhibit.

We also know that very many ideas are presented on this list which
fail to meet one or more of those criteria, this draft is intended to
provide a reference which outlines those criteria, and could be used
as a partial statement of requirements for a technique to solve the
problem of spam.

Obviously this is just my own 2c at the moment, so let me know what
your opinions are and I'll modify, abandon or replace this as
necessary.

FYI the abstract reads:

"The Internet Research Task Force Anti-Spam Research Group (ASRG) is
   frequently presented with proposals for techniques for managing spam
   from authors who wish to elicit an expert critique of their
   proposals.  In many cases proposals fall foul of issues and risks
   which are well known and understood by members of the ASRG.  This
   Internet Draft is intended to enumerate and explain a number of the
   more important of the criteria which tend to be applied.  This
   document will then serve as a normative checklist for anyone wishing
(Continue reading)

Permalink | Reply | 24 comments |
headers
Danny Angus | 18 Jan 2007 14:31
Picon
Favicon

Re: Comments: draft-irtf-asrg-criteria-00.txt

I've put an html version at

http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html
Permalink | Reply | 0 comments |
headers
John Levine | 18 Jan 2007 17:10

Re: Comments: draft-irtf-asrg-criteria-00.txt

Thank you for moving ahead with this.

I've been sitting on it way too long supposed to make comments.  I
agree that taxonomies to help categorize anti-spam techniques and
their success or lack thereof are a good direction for us.

In article <5ec229170701180344g6daca36dtdbe5ede8a2db447f <at> mail.gmail.com> you write:
>At:
>http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.txt
>
>You will find a document which outlines an idea I've had for a while.
>Please give me your comments on this list.
Permalink | Reply | 0 comments |
headers
Walter Dnes | 19 Jan 2007 02:47
Favicon

Re: Comments: draft-irtf-asrg-criteria-00.txt

On Thu, Jan 18, 2007 at 11:44:45AM +0000, Danny Angus wrote
> At: http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.txt
> You will find a document which outlines an idea I've had for a while.
> Please give me your comments on this list.
> 
> The thrust of the document is that while we don't know what the silver
> bullet solution for spam is we do know some of the characteristics
> which we expect it to exhibit.

  Item number 0) Avoid using "the S word"
1,$s/spam/unwanted email/

  Rationale: If you set up a technical definition of spam, some lawyer
or wannabee-lawyer *WILL* find a loophole in it.  And there are some
legal jurisdictions that have defined spam, and allowed explicit
exemptions.  The result will be a constant battle of technicalities.
And calling someone's email "spam" can result in lawsuits by "legitimate
bidnizzmen".  Simply saying that you don't want certain email, without
calling its senders "spammers", is less of a legal risk.  In other
words, "because I said so" should be sufficient reason for a person to
reject email for their inbox.  My inbox, my rules.

  Item number 1) Assume that senders of unwanted email may be hostile,
unethical, sleazy lawbreakers who will resort to all means at their
disposal to get their unwanted email delivered to their target.  If your
proposed solution will not work in such an environment, forget about it.

--

-- 
Walter Dnes <waltdnes <at> waltdnes.org> In linux /sbin/init is Job #1
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Nicol | 19 Jan 2007 07:07
Picon
Gravatar

Re: Comments: draft-irtf-asrg-criteria-00.txt

On 1/18/07, Walter Dnes <waltdnes <at> waltdnes.org> wrote:
> My inbox, my rules.

also known as "per-recipient configuration"
Permalink | Reply | 0 comments |
headers
Danny Angus | 19 Jan 2007 10:47
Picon
Favicon

Fwd: Comments: draft-irtf-asrg-criteria-00.txt

David,

On 1/18/07, David Nicol <davidnicol <at> gmail.com> wrote:
> okay you got it.

Its appreciated

> Before looking at it:
> One hopes that the criteria therein will be a superset of the issues
> enumerated on the "how to tell if you are an anti-spam kook" page
> http://www.rhyolite.com/anti-spam/you-might-be.html
>
> After looking at it:
> right off (1.1.1), we're at
> http://www.rhyolite.com/anti-spam/you-might-be.html#spam-fighter-4

That's a fair point. I don't think the difference is hugely
significant. But I'm not convinced that "bulk" is really a necessary
constraint. OTOH I know we've had this discussion before and I have
*no* intention of starting it again, god forbid, so I'm prepared to
remove "spam" as the headline and replace it with Unwanted Mail
throughout the document, of which "unsolicited bulk mail" is certainly
part. This also addresses Walter's point about the S word being
pejorative but "i said so" being the recipients right.

Why Unwanted Mail? Because I think that the value of any solution is
in the removal
of mail which which we know will be unwanted *before* it reaches its
destination, the sooner the better to the point where preventing it
from being sent at all is the ultimate. The trick (or implementation
(Continue reading)

Permalink | Reply | 0 comments |
headers
Danny Angus | 20 Jan 2007 21:47
Picon
Favicon

Re: Comments: draft-irtf-asrg-criteria-00.txt

On 1/19/07, David Nicol <davidnicol <at> gmail.com> wrote:

> So what's to motivate the operators then?  Operating a reputatble
> reputation server service will require ongoing effort.

Let me try to be clearer about this. I'm not stopping anyone from
charging to people for any of the services they might choose to offer
as part of the implementation of any technique. This para is about
discouraging people from making proposals which enshrine a *single*
*central* register, and that is because I think it would confer too
much power, and might be proposed simply as a licence for the proposer
to print money, never mind the practical constraints of setting it up
and operating it.

IMHO, and it *is* only my opinion, is that it should be possible and
would be desirable to establish a technique which allowed multiple
providers to co-exist, and those providers' services could either be
used singly or combined without a mandated central authority.

 I said "SHOULD NOT", not "MUST NOT" because I accept that there may
well be some proposed techniques which can make a valid and compelling
case for a central authority. I can't think of one though.

> Set up standards
> for interoperability of reputation services and commercial reputation
> services could appear, the reputation of the commercial services will
> get determined in all the usual reputation determination sources --
> free press, word of mouth, etc.

Fine yes, my thoughts exactly, yes. An open market place for services.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Feenberg | 22 Jan 2007 14:29
Favicon

Re: Comments: draft-irtf-asrg-criteria-00.txt


On Thu, 18 Jan 2007, Danny Angus wrote:

> At:
> http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.txt
>
> You will find a document which outlines an idea I've had for a while.
> Please give me your comments on this list.
>

Comments:

1.1.1 I would resist making the definition of spam so receipient 
dependent. If every receipient gets to make his/her own definition, then 
it tends to prevent cooperative solutions from looking satisfactory, and 
the the purpose of the IETF is to facilitate cooperative solutions. For 
example, if spam has no objective definition, then each user must maintain 
their own DNSBL, or list of spamassassin regular expressions. I would have 
thought the purpose of this group was to suggest ways for MTA operators to 
cooperate to reduce spam - individual solutions don't require the IETF.

There are also the cases to consider of ISPs who ignore messages to abuse 
- does that make the messages spam?  I think we should stick with 
"unsolicited commercial email" as a workable spam definition.

2.2.1 Why the prohibition on the use of non-SMTP protocols? Many 
legitimate spam reduction techniques use DNS (DNSBLs, DKIM, SPF, etc). 
While all these techniques have disadvantages, the primary problems do not 
arise for the use of an alternate protocol for communication of anti-spam 
information. Or perhaps the section means only that the mail itself should
(Continue reading)

Permalink | Reply | 19 comments |

Gmane