Subject: Re: [feedback-report] Redacting data
From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Tue, 30 Dec 2008 16:39:54 +0000
List-Id: Public forum for discussion on the feedback-report draft <abuse-feedback-report.mipassoc.org>

On Dec 29, 2008, at 11:52 PM, J D Falk wrote:

> On 23/12/2008 11:25, "Murray S. Kucherawy" <[email-masked]> wrote:
>
> > Can someone give me a few examples of the data which ARF  
> generators like
> > to redact, and how they go about doing it?  Then we can get into  
> some
> > discussion about what guidance the ARF spec should provide in this  
> area.
>
> In every case I'm aware of (which includes nearly all of the  
> installed base
> of ARF generators), the intention is to preserve user privacy -- so  
> they'll
> redact the recipient's email address in the headers, or sometimes  
> redact
> that same string from the entire message.
>
> There are rumours of further redaction, but so far they've all  
> turned out to
> be some obscure little ISP who isn't using ARF anyway.

(Cisco, say.)

AOL has, on occasion, got a bit silly with redaction, but it looked
more like code problems than policy, and didn't happen consistently
or for long. Most of the issues like that I've heard reported were when
they were offering ARF format as an option, and the problems were
with the new ARF generating code, rather than with the stable existing
scomp code. I think that's why some people got the idea that redaction
and ARF are related.

Cheers,
   Steve

Content-class: urn:content-classes:message
Date: Mon, 29 Dec 2008 18:52:29 -0500
From: "J D Falk" <[email-masked]>
To: <[email-masked]>
Subject: Re: [feedback-report] Redacting data

This is a multi-part message in MIME format.

------_=_NextPart_001_01C96A10.80A1D3FD
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 23/12/2008 11:25, "Murray S. Kucherawy" <[email-masked]> wrote:

> Can someone give me a few examples of the data which ARF generators =
like
> to redact, and how they go about doing it?  Then we can get into some
> discussion about what guidance the ARF spec should provide in this =
area.

In every case I'm aware of (which includes nearly all of the installed =
base
of ARF generators), the intention is to preserve user privacy -- so =
they'll
redact the recipient's email address in the headers, or sometimes redact
that same string from the entire message.

There are rumours of further redaction, but so far they've all turned =
out to
be some obscure little ISP who isn't using ARF anyway.

------_=_NextPart_001_01C96A10.80A1D3FD
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7651.59">
<TITLE>Re: [feedback-report] Redacting data</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>On 23/12/2008 11:25, &quot;Murray S. Kucherawy&quot; =
&lt;[email-masked]&gt; wrote:<BR>
<BR>
&gt; Can someone give me a few examples of the data which ARF generators =
like<BR>
&gt; to redact, and how they go about doing it?&nbsp; Then we can get =
into some<BR>
&gt; discussion about what guidance the ARF spec should provide in this =
area.<BR>
<BR>
In every case I'm aware of (which includes nearly all of the installed =
base<BR>
of ARF generators), the intention is to preserve user privacy -- so =
they'll<BR>
redact the recipient's email address in the headers, or sometimes =
redact<BR>
that same string from the entire message.<BR>
<BR>
There are rumours of further redaction, but so far they've all turned =
out to<BR>
be some obscure little ISP who isn't using ARF anyway.<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C96A10.80A1D3FD--

Date: Wed, 24 Dec 2008 13:52:37 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: [feedback-report] Redacting data

At 08:51 24-12-2008, John L wrote:
>I'd suggest adding a few sentences saying that some ARF senders redact
>the recipient's address to avoid inadvertent disclosure to an ARF
>recipient who wasn't the sender of the original message, but there's
>no reason to redact other addresses, nor fields whose meaning would
>only be known to the actual sender.

If the recipient's address is to be redacted, then the specifications 
would have to define how the change should be done.  Do we replace 
the email address with another one (e.g. [email-masked])?  Such a 
change has an impact on the Original-Rcpt-To (optional) field.

Regards,
-sm

Date: Wed, 24 Dec 2008 16:51:01 +0000 (GMT)
From: John L <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cleverness: None detected
Cc: [email-masked]
Subject: Re: [feedback-report] Redacting data

> Can someone give me a few examples of the data which ARF generators like
> to redact, and how they go about doing it?

My understanding is that the original rationale for redacting the
recipient's address at AOL was that the recipient of the feedback
report might not be the same entity that sent the message, and
redaction prevents leakage of private mailbox names.  But there is no
need to redact other fields that might be encoded versions of the
recipient's address, since if you know how to decode it, you must have
sent it in the first place.  There's no winking or nodding, it's quite
straightforward.

As we all know, there's rampant cargo cult thinking on the Internet,
even among the Internet's lawyers*, and there's a lot of cultists who
think that if some redaction is Good, even more redaction is Better,
which is the only reason I can see that they redact all over the
place.

I'd suggest adding a few sentences saying that some ARF senders redact
the recipient's address to avoid inadvertent disclosure to an ARF
recipient who wasn't the sender of the original message, but there's
no reason to redact other addresses, nor fields whose meaning would
only be known to the actual sender.

R's,
John

* - viz the stupid confidentiality boilerplate that I see on many of
the submissions to update the public abuse.net database

Date: Tue, 23 Dec 2008 10:25:44 -0800 (PST)
From: "Murray S. Kucherawy" <[email-masked]>
To: [email-masked]
Subject: [feedback-report] Redacting data

[In an attempt to get these conversations taking place out in the open...]

I must admit I've come to the ARF discussion in the middle rather than at 
the beginning.

Can someone give me a few examples of the data which ARF generators like 
to redact, and how they go about doing it?  Then we can get into some 
discussion about what guidance the ARF spec should provide in this area.

Date: Mon, 15 Dec 2008 10:37:22 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: [feedback-report] Abuse Feedback or Email Feedback

At 10:00 15-12-2008, J.D. Falk wrote:
>That could invite massive feature creep, as we've seen in the ASRG
>discussions.

Let's not mix the ASRG discussions with the ones here. :-)

The updated version of the draft (as posted to the mailing list) is 
set for Standard Track.  I asked the question about whether this 
could be a generalized mechanism as I expect it to come up at some 
point during the process.  I understand that there are already 
existing implementations of this specification.  But that alone might 
not be viewed as a compelling reason not to do it.

Regards,
-sm 

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Mon, 15 Dec 2008 10:10:50 -0800
Subject: Re: [feedback-report] Abuse Feedback or Email Feedback

On Dec 15, 2008, at 10:00 AM, J.D. Falk wrote:

> On 14/12/2008 14:08, "John L" <[email-masked]> wrote:
>
>>> That's a good point.  So should there be some mention, to clarify  
>>> the
>>> inconsistency, that this work takes a wide view of what constitutes
>>> "abuse"?
>>
>> How about saying that it was originally designed for sending abuse
>> reports, hence the name ARF, but it has been found useful as a more
>> general way to send reports about received e-mail.

I don't believe that's true. If there's actual operational experience
that shows that I might be more convinced.

>>
>
> That could invite massive feature creep, as we've seen in the ASRG
> discussions.

We've already had some feature creep. Fortunately the added features
don't harm the base protocol (just make the spec more complicated)
and nobody really expects anyone to use them anyway (not least
because they're redundant thanks to, amongst others, RFC2369),
and the main problem they've caused is to make people object
to the name.

Further feature creep and obfuscation of the existing simple protocol
would be a bad thing.

Cheers,
   Steve

Date: Mon, 15 Dec 2008 11:00:02 -0700
From: "J.D. Falk" <[email-masked]>
To: John L <[email-masked]>, "Murray S. Kucherawy" <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] Abuse Feedback or Email Feedback

On 14/12/2008 14:08, "John L" <[email-masked]> wrote:

>> That's a good point.  So should there be some mention, to clarify the
>> inconsistency, that this work takes a wide view of what constitutes
>> "abuse"?
> 
> How about saying that it was originally designed for sending abuse
> reports, hence the name ARF, but it has been found useful as a more
> general way to send reports about received e-mail.

That could invite massive feature creep, as we've seen in the ASRG
discussions.

Date: Sun, 14 Dec 2008 21:08:45 +0000 (GMT)
From: John L <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cleverness: None detected
Cc: [email-masked]
Subject: Re: [feedback-report] Abuse Feedback or Email Feedback

> That's a good point.  So should there be some mention, to clarify the
> inconsistency, that this work takes a wide view of what constitutes
> "abuse"?

How about saying that it was originally designed for sending abuse 
reports, hence the name ARF, but it has been found useful as a more 
general way to send reports about received e-mail.

R's,
John

Date: Sun, 14 Dec 2008 11:22:06 -0800 (PST)
From: "Murray S. Kucherawy" <[email-masked]>
To: J D Falk <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] Abuse Feedback or Email Feedback

On Sun, 14 Dec 2008, J D Falk wrote:
> There's a large established userbase which calls it ARF, including lots 
> of software (some open, much more proprietary) and documentation. 
> Changing the name would introduce vast, unnecessary confusion for little 
> (if any) benefit.

That's a good point.  So should there be some mention, to clarify the 
inconsistency, that this work takes a wide view of what constitutes 
"abuse"?

At CEAS this year, the speaker from Google mentioned that their definition 
of abuse is "whatever the users say it is", and that seems to have worked 
for them.

Content-class: urn:content-classes:message
Date: Sun, 14 Dec 2008 10:03:09 -0500
From: "J D Falk" <[email-masked]>
To: <[email-masked]>
Subject: Re: [feedback-report] Abuse Feedback or Email Feedback

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95DFD.1373AC38
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 10/12/2008 10:39, "SM" <[email-masked]> wrote:

> Anything a recipient doesn't like doesn't necessarily constitute
> abuse.  During a discussion on the ASRG mailing list, it was pointed
> out that it's easier to describe the email as "unwanted".  From
> there, we can have categories such as abuse, fraud, opt-out,
> etc.  The draft defines an email feedback mechanism.  The
> determination of what constitutes abuse is up to the reporter.

There's a large established userbase which calls it ARF, including lots =
of
software (some open, much more proprietary) and documentation.  Changing =
the
name would introduce vast, unnecessary confusion for little (if any)
benefit.

------_=_NextPart_001_01C95DFD.1373AC38
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7651.59">
<TITLE>Re: [feedback-report] Abuse Feedback or Email Feedback</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>On 10/12/2008 10:39, &quot;SM&quot; =
&lt;[email-masked]&gt; wrote:<BR>
<BR>
&gt; Anything a recipient doesn't like doesn't necessarily =
constitute<BR>
&gt; abuse.&nbsp; During a discussion on the ASRG mailing list, it was =
pointed<BR>
&gt; out that it's easier to describe the email as =
&quot;unwanted&quot;.&nbsp; From<BR>
&gt; there, we can have categories such as abuse, fraud, opt-out,<BR>
&gt; etc.&nbsp; The draft defines an email feedback mechanism.&nbsp; =
The<BR>
&gt; determination of what constitutes abuse is up to the reporter.<BR>
<BR>
There's a large established userbase which calls it ARF, including lots =
of<BR>
software (some open, much more proprietary) and documentation.&nbsp; =
Changing the<BR>
name would introduce vast, unnecessary confusion for little (if any)<BR>
benefit.<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C95DFD.1373AC38--

Date: Wed, 10 Dec 2008 09:39:36 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: [feedback-report] Abuse Feedback or Email Feedback

At 11:47 09-12-2008, Murray S. Kucherawy wrote:
>I think all of the forms of mail which could generate ARF reports as the
>spec currently defines could be described as forms of abuse (certainly by
>the recipient, who is objecting and thus generating the report).  Thus,
>the name seems acceptable to me.

I wouldn't put the opt-out request as abuse as it has a distinctive 
Feedback Type Name.

>Is it necessary to state that the draft takes a wide view of what
>constitutes abuse, i.e. anything a recipient doesn't like or want?

Anything a recipient doesn't like doesn't necessarily constitute 
abuse.  During a discussion on the ASRG mailing list, it was pointed 
out that it's easier to describe the email as "unwanted".  From 
there, we can have categories such as abuse, fraud, opt-out, 
etc.  The draft defines an email feedback mechanism.  The 
determination of what constitutes abuse is up to the reporter.

Regards,
-sm 

From: "Anne P. Mitchell, Esq." <[email-masked]>
To: [email-masked]
Date: Tue, 9 Dec 2008 13:21:30 -0700
Subject: Re: [feedback-report] Request for information from ARF users

> - what organization you represent

ISIPP - the Institute for Social Internet Public Policy

> - how you're using ARF (generator, recipient, or both)

Intermediary translator. :-)

> - whether or not you've got generator/parsing code that is open  
> source, or
> could be
> - what kinds of reports you handle and how you handle them (manual or
> automated)

We currently offer a service called Feedback Loop Reports, where we  
take the FBLs for our senders, and generate a daily report which  
breaks down how many complaints they've had from each ISP, how many  
complaints per "from" address, how many per subject line, etc..  It's  
been incredibly useful for senders - but at least as importantly it  
gets senders to start actually *looking at what their FBLs are telling  
them*!  It also means that the sender doesn't have to worry about  
parsing the information, what format it's in, etc..

> - how long you've been using it

Several months.

> - how many users benefit from your implementation (if you're allowed  
> to say)

All of the users on the receiving end of the combined billions of  
pieces of email our FBL Reports-using senders are sending.

Anne

Anne P. Mitchell, Esq
CEO/President
Institute for Social Internet Public Policy
http://www.ISIPP.com
Member, Cal. Bar Cyberspace Law Committee
Professor of Law, Lincoln Law School of SJ
Author, "The Email Deliverability Handbook"

Date: Tue, 9 Dec 2008 11:47:09 -0800 (PST)
From: "Murray S. Kucherawy" <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] Abuse Feedback or Email Feedback

On Tue, 9 Dec 2008, SM wrote:
> Is the intent to have a have general format for feedback reports?  If
> so, shouldn't the format be renamed to Email Reporting Format instead
> of Abuse Reporting Format?

I think all of the forms of mail which could generate ARF reports as the 
spec currently defines could be described as forms of abuse (certainly by 
the recipient, who is objecting and thus generating the report).  Thus, 
the name seems acceptable to me.

Is it necessary to state that the draft takes a wide view of what 
constitutes abuse, i.e. anything a recipient doesn't like or want?

Date: Tue, 9 Dec 2008 11:44:14 -0800 (PST)
From: "Murray S. Kucherawy" <[email-masked]>
To: [email-masked]
Subject: [feedback-report] Proposed -06 draft

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-80634524-1228851854=:80971
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

I'm starting to gather the momentum to move ARF through the IETF 
publication process.  It's my understanding that since the 
interoperability of the proposal will span administrative domains (the 
generator and the recipient will in fact rarely be in the same domain), it 
has to go as a proposed standard, which will mean everyone's scrutiny 
knobs will be set to "11".  Thus, we need to give it some pretty thorough 
review.

I've attached what I'm proposing to post as the -06 draft, and intend to 
begin seeking feedback from lots of parties once I've done so.  You've 
already seen me seek implementation information which is useful when 
justifying to the IESG why the publication is important.

This new version has a number of minor edits but also several important 
changes:

- the IANA stuff has been grouped together into one common section

- Security Considerations has been expanded a little (probably needs more; 
please suggest other issues that could be discussed)

- I've added ABNF; my view is that anything which could be machine-parsed 
should have ABNF

- changed the RFC reference tags to be named rather than numbered

- add more discussion about project history and current implementation 
(this needs to be fleshed out even further)

With your help we can get it ready for easier passage through the IETF 
approval process.

Thanks,

-MSK
--0-80634524-1228851854=:80971
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=new.txt
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=new.txt

--0-80634524-1228851854=:80971--

Date: Tue, 09 Dec 2008 10:10:34 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: [feedback-report] Abuse Feedback or Email Feedback

Hello,

The following comment is for draft-shafranovich-feedback-report-05.

The Abstract defines the format as for

   "report feedback about received email to other parties"

In the Introduction, it is mentioned that

  "Abuse Reporting Format (ARF) for reporting email abuse but also includes
   support for direct feedback via end user mail clients, reports of some types
   of virus activity, and some similar issues."

Section 2 also mentions that the intent is:

   To inform email service provides about opt-out requests

Is the intent to have a have general format for feedback reports?  If 
so, shouldn't the format be renamed to Email Reporting Format instead 
of Abuse Reporting Format?

Regards,
-sm 

From: Mark Martinec <[email-masked]>
Organization: J. Stefan Institute
To: [email-masked]
Date: Tue, 9 Dec 2008 15:17:17 +0100
Subject: Re: [feedback-report] Request for information from ARF users

Murray,

> As I'm preparing the ARF draft for some revision and fleshing-out in
> preparation for its submission to the IETF for publication, I'm missing
> some information that will be useful to present when that time comes.
>
> So if you're a user of ARF as either a report generator or a report
> consumer, including both ISPs and software vendors, please get back to me
> either on-list or privately with:

> - what organization you represent

- developer of amavisd-new (content filtering);
- postmaster at: Jo¾ef Stefan Institute, Slovenia

> - how you're using ARF (generator, recipient, or both)

Generator only.

- as a developer: ARF generator is part of amavisd-new since
  version 2.6.0, April 2008. It can send ARF (or plain)
  abuse reports on grounds of a quarantined pristine mail
  ('amavisd-report' command), or report generation can be
  invoked automatically during mail reception from a custom
  hook (in Perl).

- as a site, most fraud reports (no spam reports) that we send out
  go to yahoo.com, and unfortunatlely they are not equipped to handle
  ARF or any mail attachments, so our reports include the original
  mail header section in-line. We only send automated reports when
  origin of mail is confirmed by a valid DKIM or DK signature.

- I'd very much like to send abuse reports to proven mail from
  google, but it seems they only take web-form reports.

> - whether or not you've got generator/parsing code that is open source,
>   or could be

amavisd-new is open source (GPL).

> - what kinds of reports you handle and how you handle them (manual
>   or automated)

- manual reports through 'amavisd-report' utility, taking mail header
  section from a quarantine;

- automated reports (by a custom hook to amavisd-new) to yahoo.com
  with several safety-fuses: DKIM/DK must be valid, IP address must
  belong to yahoo pool, sender address must be yahoo.com, several
  fraud indicators in SpamAssassin and SaneSecurity must fire, and
  reports are rate limited to 1 per 6 hours for any given sender
  address. I'm happy to report that so far more than 3000 of our
  reports were manually processed by yahoo so far, and practically
  all reported accounts terminated (except for a small handful,
  apparently operator not reading carefully the report).

> - any local extensions you've added

no

> - how long you've been using it

April 2008.

> - how many users benefit from your implementation (if you're allowed to
> say) - any other information that would explain to others why ARF is
> important to your operation

- 1000 at our side; benefits to other recipients of fraud from yahoo;
- unknown number for users of amavisd-new;

> I'm also interested in hearing from those of you who were part of ARF
> early on so that I can give some history of the work that can't be found
> on the mailing list, especially what the impetus was for starting this
> work and what collaboration was done at MAAWG (or elsewhere) to encourage
> its progress.

None, besides what is on a mailing list (my suggestions were incorporated
into ARF, like: reports for multi-recipient mail).

  Mark

Date: Mon, 8 Dec 2008 11:48:44 -0500
From: Ricardo SIGNES <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] Request for information from ARF users

* "Murray S. Kucherawy" <[email-masked]> [2008-12-08T03:42:14]
> - what organization you represent

I'm the lead programmer at Pobox.com and Listbox.com.

> - how you're using ARF (generator, recipient, or both)

We receive, parse, and automatically act on ARF reports.  We are not yet
sending ARF reports.

> - whether or not you've got generator/parsing code that is open source, or 
> could be

Yes, we wrote and published the Perl library Email::ARF.

> - what kinds of reports you handle and how you handle them (manual or 
> automated)

Most of the reports we handle are from large ESPs whose users have (in most
cases mistakenly) reported opt-in mail as spam.  We automatically process those
as if they were opt-out request.  There are a few other common cases (user
turns of spam filtering, then reports us as having forwarded spam is another
big one).

> - any local extensions you've added

Because most large ESPs muck with addresses found in the headers, we've had to
improve our message fingerprinting to allow us to know how to act based on the
redacted message included in the ARF report.  This is an extension to our
mailflow, not to ARF.

> - how long you've been using it

We've been processing ARF formatted mail for at least a year and a half.

> - how many users benefit from your implementation (if you're allowed to say)

I can't say, but I think it's fair to say "quite a lot."

> - any other information that would explain to others why ARF is important to 
> your operation

The biggest benefit is how our internal systems for handling mail to our abuse
and requests addresses were able to change.  It used to be that we'd need to
add code for every feedback loop provider, and some providers did or did not
provide enough information for the program to then understand what problem was
occuring and fix it.  Now we have one report parser and all we have to do is
write the code to fix each detected problem type.

-- 
rjbs

Date: Mon, 08 Dec 2008 07:50:01 -0800
From: Marc Perkel <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] Request for information from ARF users

I've been using ARF for about 18 months. I'm the owner of Junk Email 
Filter dot com. (http://www.junkemailfilter.com) We generate automated 
abuse reports when we detect virus infected computers. We generate as 
much as 5000 reports an hour.

At first these reports were a problem in that we found out that we had 
some false positives. We customized the report to be extremely 
respectful of the recipient. Eventually people not only got to like the 
report but came to depend on it so that they could use it in their 
automated scripts to block ports on infected computers. If my reporting 
stops people start asking me what happened.

Date: Mon, 8 Dec 2008 10:34:58 -0500
From: "Ken Robbins" <[email-masked]>
Sender: [email-masked]
To: "Murray S. Kucherawy" <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] Request for information from ARF users

------=_Part_54630_24647939.1228750499010
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

> - what organization you representUnica Corporation (www.unica.com). Unica
is a provider of marketing automation software and solutions.

> - how you're using ARF (generator, recipient, or both)
Recipient.

> - whether or not you've got generator/parsing code that is open source, or
could be
Our parsing code is proprietary at this time. It is conceivable that our
code could be segmented and made open source, but there is no plan to do
this at this time.

> - what kinds of reports you handle and how you handle them (manual or
automated)
We handle any sort of ARF report. The processing is fully automated and
integrated with our bounce handler and auto-reply handler technology. A
database record with all of the relevant parsed information is created for
each received ARF report so that additional processing may automatically
occur (e.g., to create suppression lists, unsubscribe actions, etc.)

> - any local extensions you've added
Not yet.

> - how long you've been using it
Only since October 2008.

> - how many users benefit from your implementation (if you're allowed to
say)
We are just getting going with ARF reports, but there will be hundreds of
organizations that will eventually utilize this functionality.

> - any other information that would explain to others why ARF is important
to
your operation
In order to improve mail quality, deliverability, and mail reputation it is
obviously critical to remove recipients that have clicked spam. We have a
need to do this across a worldwide diversity of email ISPs and across
billions of messages sent per year. This is not tenable if the industry does
not adopt a machine readable standard for abuse reports.

Additional needs: While having the ARF standard is an essential starting
point, the process of establishing feedback loops with a diversity of ISPs
is difficult and different for each. The confirmation steps for feedback
loop destinations and for IP ownership vary for provider to provider and can
be convoluted especially for email service providers providing FBL services
on behalf of third parties.

Thanks for your work on ARF,
  Ken Robbins

On Mon, Dec 8, 2008 at 3:42 AM, Murray S. Kucherawy <[email-masked]>wrote:

> As I'm preparing the ARF draft for some revision and fleshing-out in
> preparation for its submission to the IETF for publication, I'm missing
> some information that will be useful to present when that time comes.
>
> So if you're a user of ARF as either a report generator or a report
> consumer, including both ISPs and software vendors, please get back to me
> either on-list or privately with:
>
> - what organization you represent
> - how you're using ARF (generator, recipient, or both)
> - whether or not you've got generator/parsing code that is open source, or
> could be
> - what kinds of reports you handle and how you handle them (manual or
> automated)
> - any local extensions you've added
> - how long you've been using it
> - how many users benefit from your implementation (if you're allowed to
> say)
> - any other information that would explain to others why ARF is important
> to
> your operation
>
> I'm also interested in hearing from those of you who were part of ARF
> early on so that I can give some history of the work that can't be found
> on the mailing list, especially what the impetus was for starting this
> work and what collaboration was done at MAAWG (or elsewhere) to encourage
> its progress.
>
> Thanks!
>
> -MSK
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
>

------=_Part_54630_24647939.1228750499010
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

&gt; - what organization you represent<div>Unica Corporation (<a href="http://www.unica.com">www.unica.com</a>). Unica is a provider of marketing automation software and solutions.</div><div><br>&gt; - how you&#39;re using ARF (generator, recipient, or both)</div>
<div>Recipient.</div><div><br>&gt; - whether or not you&#39;ve got generator/parsing code that is open source, or<br>could be</div><div>Our parsing code is proprietary at this time. It is conceivable that our code could be segmented and made open source, but there is no plan to do this at this time.</div>
<div><br>&gt; - what kinds of reports you handle and how you handle them (manual or<br>automated)</div><div>We handle any sort of ARF report. The processing is fully automated and integrated with our bounce handler and auto-reply handler technology. A database record with all of the relevant parsed information is created for each received ARF report so that additional processing may automatically occur (e.g., to create suppression lists, unsubscribe actions, etc.)</div>
<div><br>&gt; - any local extensions you&#39;ve added</div><div>Not yet.</div><div><br>&gt; - how long you&#39;ve been using it</div><div>Only since October 2008.</div><div><br>&gt; - how many users benefit from your implementation (if you&#39;re allowed to say)</div>
<div>We are just getting going with ARF reports, but there will be hundreds of organizations that will eventually utilize this functionality.</div><div><br>&gt; - any other information that would explain to others why ARF is important to<br>
your operation</div><div>In order to improve mail quality, deliverability, and mail reputation it is obviously critical to remove recipients that have clicked spam. We have a need to do this across a worldwide diversity of email ISPs and across billions of messages sent per year. This is not tenable if the industry does not adopt a machine readable standard for abuse reports.</div>
<div><br></div><div>Additional needs: While having the ARF standard is an essential starting point, the process of establishing feedback loops with a diversity of ISPs is difficult and different for each. The confirmation steps for feedback loop destinations and for IP ownership vary for provider to provider and can be convoluted especially for email service providers providing FBL services on behalf of third parties.<br>
<br></div><div>Thanks for your work on ARF,</div><div>&nbsp;&nbsp;Ken Robbins</div><div><br><div class="gmail_quote">On Mon, Dec 8, 2008 at 3:42 AM, Murray S. Kucherawy <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">As I&#39;m preparing the ARF draft for some revision and fleshing-out in<br>
preparation for its submission to the IETF for publication, I&#39;m missing<br>
some information that will be useful to present when that time comes.<br>
<br>
So if you&#39;re a user of ARF as either a report generator or a report<br>
consumer, including both ISPs and software vendors, please get back to me<br>
either on-list or privately with:<br>
<br>
- what organization you represent<br>
- how you&#39;re using ARF (generator, recipient, or both)<br>
- whether or not you&#39;ve got generator/parsing code that is open source, or<br>
could be<br>
- what kinds of reports you handle and how you handle them (manual or<br>
automated)<br>
- any local extensions you&#39;ve added<br>
- how long you&#39;ve been using it<br>
- how many users benefit from your implementation (if you&#39;re allowed to say)<br>
- any other information that would explain to others why ARF is important to<br>
your operation<br>
<br>
I&#39;m also interested in hearing from those of you who were part of ARF<br>
early on so that I can give some history of the work that can&#39;t be found<br>
on the mailing list, especially what the impetus was for starting this<br>
work and what collaboration was done at MAAWG (or elsewhere) to encourage<br>
its progress.<br>
<br>
Thanks!<br>
<br>
-MSK<br>
_______________________________________________<br>
abuse-feedback-report mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="http://mipassoc.org/mailman/listinfo/abuse-feedback-report" target="_blank">http://mipassoc.org/mailman/listinfo/abuse-feedback-report</a><br>
</blockquote></div><br></div>

------=_Part_54630_24647939.1228750499010--

Date: Mon, 8 Dec 2008 12:29:14 +0000 (GMT)
From: John L <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Request for information from ARF users

> - what organization you represent

My tiny network which also hosts abuse.net

> - how you're using ARF (generator, recipient, or both)

Generate for all spam reports, receive in FBLs.

> - whether or not you've got generator/parsing code that is open source, or
> could be

You're welcome to my perl scripts but they're very specific to my local 
qmail and mj2 environment.

> - what kinds of reports you handle and how you handle them (manual or
> automated)

Automated FBL handling recognizes reports of mj2 list mail and generates 
unsubscribes.  Manual otherwise, but very low volume of non-list reports.

> - any local extensions you've added
> - how long you've been using it

Two years, I think.

> - how many users benefit from your implementation (if you're allowed to say)

Varies, highest was about 1000, currently about 100.

> - any other information that would explain to others why ARF is important to
> your operation

Auto-parsing the inbound ARF reports for list mail is a big timesaver.

The outbound ARF is mainly an experiment to see how well it's accepted. 
For the most part, recipients handle it pretty well.

Biggest problem: broken ticketing systems that smash the attachment so 
they write back and ask for the headers.  I've made a web archive of the 
spam I complain about and provide a URL to the spam in the report.  That 
helps, but two or three times a week I get "send headers" including the 
part of the report that tells them how to fetch the URL.

Minor problem: the occasional little web host that seems to be reading 
abuse reports in Outlook and is too scared to open the attachment with the 
message.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

Date: Mon, 8 Dec 2008 00:42:14 -0800 (PST)
From: "Murray S. Kucherawy" <[email-masked]>
To: [email-masked]
Subject: [feedback-report] Request for information from ARF users

As I'm preparing the ARF draft for some revision and fleshing-out in 
preparation for its submission to the IETF for publication, I'm missing 
some information that will be useful to present when that time comes.

So if you're a user of ARF as either a report generator or a report 
consumer, including both ISPs and software vendors, please get back to me 
either on-list or privately with:

- what organization you represent
- how you're using ARF (generator, recipient, or both)
- whether or not you've got generator/parsing code that is open source, or 
could be
- what kinds of reports you handle and how you handle them (manual or 
automated)
- any local extensions you've added
- how long you've been using it
- how many users benefit from your implementation (if you're allowed to say)
- any other information that would explain to others why ARF is important to 
your operation

I'm also interested in hearing from those of you who were part of ARF 
early on so that I can give some history of the work that can't be found 
on the mailing list, especially what the impetus was for starting this 
work and what collaboration was done at MAAWG (or elsewhere) to encourage 
its progress.

Thanks!

-MSK