Subject: Knowing who pressed the button (was Re: [feedback-report] ARF spec oversights)
From: "J.D. Falk" <[email-masked]>
To: [email-masked]
Date: Sat, 27 May 2006 11:58:36 -0700
List-Id: Public forum for discussion on the feedback-report draft <abuse-feedback-report.mipassoc.org>

On 2006-05-26 05:32, Mark Bainter wrote:

> We cannot stop sending that user email if we don't know who s/he is.

Nobody disagrees -- but writing that requirement into ARF won't make 
AOL's lawyers change their minds.  Better to keep it optional in the 
technical spec, and use social pressure to encourage best practices.

(Speaking of best practices: you get the full headers in the report, and 
you can put a token in an x-header which matches up with the subscriber 
in your database.  That'll survive forwarding, too, so it's a lot more 
accurate than just knowing who pressed the button.  But a sender worthy 
of their job doesn't need /me/ to tell them this stuff, right?)

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team

Date: Fri, 26 May 2006 15:37:01 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: Mark Bainter <[email-masked]>
Subject: Re: [feedback-report] ARF spec oversights
Cc: [email-masked]

Mark Bainter wrote:
> 
> Incidentally, I DO agree with your request to require the name of the
> offended party.  I can understand some of the hesitance here, but most
> people who are going to be using this to try and be 'good' senders,
> like us, are generally sending the mail to customers at other ISPs.
> Trying to tag the fields we know for sure we'll get back historically
> only increases the chance of users filing a complaint about it.
> 
> We cannot stop sending that user email if we don't know who s/he is.
> 

We already have this feature, there is an optional header 
"Removal-Recipient" defined in section 5.3 as follows:

"
o  "Removal-Recipient:" - indicates the email address to be removed
     from the mailing list (MUST only be used with  "opt-out" and "opt-
     out-list" types).  The format of this field is defined in section
     3.4.1 of RFC 2822 [6].
"

Yakov

Date: Fri, 26 May 2006 07:32:31 -0500
From: "Mark Bainter" <[email-masked]>
To: [email-masked]
Subject: Re: Re[2]: [feedback-report] ARF spec oversights

On 5/24/06, Chris Drake <[email-masked]> wrote:
> As it stands - what's in your standard is no use to me.  I cannot
> authorize action against my customers without confirmed, verified,
> substantiated, authenticated reports with evidence.  It is NOT my
> problem how some other ISP designs their GUI to facility abuse
> reporting - but if they want me to take action based on their reports,
> I refuse to do so if they don't bother to put the effort in to prevent
> mistaken reports, and give me what I need to protect my customers
> against malicious ones.

I know exactly what you're talking about.  We even have messages sent
by our users that are replied to by users, and then they still
generate a spam complaint about it.  Trying to comply with feedback
requirements is a nightmare when the users treat it like it's a delete
button.  Particularly when they then call and complain and get irate
when they stop receiving emails.

I read through your message and tried to understand how it would
improve things but I'm not sure it will.  As these others have said,
your suggestions are simply not controllable through the format being
suggested here.  This is just a format for reporting, not a means of
enforcing good design methods.  It would be nice if we could force
users to have to click to confirm...to make reporting spam more
difficult than deleting the email is.  (Not make it a hurdle, just
don't make it easier and more convenient than deleting emails)
However I think any attempt to enforce a standard like that is simply
not going to be accepted, leaving us witih nothing.  And even without
that, the ARF format is a big step forward.  I hate to lose it because
we tried for too much out of the gate.

Incidentally, I DO agree with your request to require the name of the
offended party.  I can understand some of the hesitance here, but most
people who are going to be using this to try and be 'good' senders,
like us, are generally sending the mail to customers at other ISPs.
Trying to tag the fields we know for sure we'll get back historically
only increases the chance of users filing a complaint about it.

We cannot stop sending that user email if we don't know who s/he is.

Mark Bainter
Email Operations Manager
Match.com

Date: Thu, 25 May 2006 14:07:47 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: [email-masked]
Subject: Re: [feedback-report] ARF spec oversights

On 2006-05-24 21:59, Chris Drake wrote:

> I guess I didn't make my point clear enough.  Unless your "standard"
> produces something that me, as an ISP abuse-desk manager, can actually
> *use* and RELY upon, there's no point having any standard at all.

No need to get upset.  All of us who've been involved with the 
development of this standard have many years of experience with abuse 
desks, and with trying to get abuse folks to agree on anything.

It sounds like you've made the common mistake of assuming that a single 
report MUST result in a single action, or that ARF is intended to 
somehow replace standard reports send to abuse desks.  Neither of those 
are necessarily true.

Instead, automated reports are sent to automated report processing 
systems.  Depending on the policies of the report recipient, the 
automated report processing system MAY act on a single report -- or, you 
might want to wait until there've been multiple reports about the same 
user, or the same IP, or the same URL, or whatever.

In other words, the policy is in the processing -- not in the data format.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team

Date: Thu, 25 May 2006 14:59:50 +1000
From: Chris Drake  <[email-masked]>
To: [email-masked]
Subject: Re[2]: [feedback-report] ARF spec oversights

Hi Mike & J.D.,

I guess I didn't make my point clear enough.  Unless your "standard"
produces something that me, as an ISP abuse-desk manager, can actually
*use* and RELY upon, there's no point having any standard at all.

As it stands - what's in your standard is no use to me.  I cannot
authorize action against my customers without confirmed, verified,
substantiated, authenticated reports with evidence.  It is NOT my
problem how some other ISP designs their GUI to facility abuse
reporting - but if they want me to take action based on their reports,
I refuse to do so if they don't bother to put the effort in to prevent
mistaken reports, and give me what I need to protect my customers
against malicious ones.

Don't take my word for it - phone up your own ISP and ask their abuse
desk what they do with AOL "TOS" complaints.  You will find that we
all ignore them, even ARF compliant ones, because 90%+ are mistaken
reports, and we either do not have the time to read mounds of AOL
users personal emails looking for individual ones that might be spam,
or, we take an ethical position that it's not right that we *should*
be reading AOL users personal emails.

If you improve your standard by incorporating my suggestions, that's
the pressure that ISPs need to improve their GUIs to comply with your
standard, which is all I need an an abuse-desk manager to properly and
immediately act on genuine abuse complaints.  Win. Win. Win.

Kind Regards,
Chris Drake

Content-class: urn:content-classes:message
Subject: RE: [feedback-report] ARF spec oversights
Date: Wed, 24 May 2006 14:10:13 -0500
From: "Mike Fitzgerald" <[email-masked]>
To: <[email-masked]>

My 2 cents...

> On 2006-05-24 00:23, Chris Drake wrote:
> 
> > 1. Mandatory - Generator identity
> > 
> >    There needs to be a way to distinguish between human-generated
> >    reports, machine generated reports, vindictive malicious (eg:
DoS)
> >    reports, and 3rd-party (eg: not the original recipient) reports.
>
> What's the use case you're thinking of?

I would hope that we could rely on an existing standard to authenticate
the identity of the generator and prevent spoofing / DoS.  DomainKeys
and/or SPF should work well.

> > 3. Recommended - "Feedback type selected by" header
> > 
> >    Lots of people hit the "spam" button when they get emails from
> >    their friends or enemies, and that they merely dislike the
> >    contents.  We need to know how the "Feedback type" was
determined:
> >    is it an accurate description of the reason for the report which
> >    was something the reporting original recipient selected, or is it
> >    some kind of generic guess or hard-coded constant inserted by the
> >    reporting ISPs abuse system ?
>
> Do any current implementations care about feedback type?

Feedback type (e.g. abuse or opt-out) can be determined by the existing
"Feedback-Type:" header.  How the feedback type was determined is an
implementation detail of the ISP that I'm not sure should be exposed to
report recipients.  There are so many different implementation
possibilities that it would be difficult to enumerate them in a standard
and unclear how a receiver should treat them differently.

In any case, there exists a "User-Agent:" header, which "indicates the
name and version of the software program that generated the report."

Best Regards,
Mike Fitzgerald
Team Lead - Email Operations
AdKnowledge, Inc.

Date: Wed, 24 May 2006 11:03:28 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: [email-masked]
Subject: Re: [feedback-report] ARF spec oversights

On 2006-05-24 00:23, Chris Drake wrote:

> 1. Mandatory - Generator identity
> 
>    There needs to be a way to distinguish between human-generated
>    reports, machine generated reports, vindictive malicious (eg: DoS)
>    reports, and 3rd-party (eg: not the original recipient) reports.

What's the use case you're thinking of?

> 2. Recommended - confirmation status
> 
>    As 90%+ of the people on this list should know by now - the effect
>    of AOL, Gmail, Hotmail, etc folks putting their "Spam" button right
>    next to their "Trash" button means that a large number of users are
>    hitting the wrong button by mistake.

Sounds like a user interface decision, rather than a problem with the 
standard.

>    Having a recommended (or perhaps even mandatory - to highlight how
>    important this is!) header to indicate whether or not the user
>    "just hit the spam button", or whether they were given an
>    opportunity to preview what they were about to report, and actually
>    confirmed that it was "spam" - is important.

That still sounds like a user interface decision, rather than a problem 
with the standard.

>    Consider also that some emails are highly confidential, and are not
>    suitable for sending to abuse desks immediately upon clicking a
>    single button: rg: We also recently received a user-error
>    spam-report containing some extremely confidential, personal
>    banking information.

And that's a policy issue, not a technical issue.  If you think your 
users can't be trusted with a spam button, that's between you and your 
users.

> 3. Recommended - "Feedback type selected by" header
> 
>    Lots of people hit the "spam" button when they get emails from
>    their friends or enemies, and that they merely dislike the
>    contents.  We need to know how the "Feedback type" was determined:
>    is it an accurate description of the reason for the report which
>    was something the reporting original recipient selected, or is it
>    some kind of generic guess or hard-coded constant inserted by the
>    reporting ISPs abuse system ?

Do any current implementations care about feedback type?

> 4. Reporting individual Authentication
> 
>    There also needs to be a way to communicate to ARF report
>    recipients the results of an authenticity check performed against
>    the reporting individual - for example - a third-party might
>    maliciously choose "select-all" then "report as spam" with the
>    "remove" option selected to cause everyone that a victim
>    communicates with to be barred from sending email to the victim in
>    future.

I'm not sure I understand the scenario you're describing.  Are you 
talking about random third parties somehow gaining access to a Report 
Generator's reporting system?

> 5. Confirmation requests
> 
>    Finally - we need a way to communicate back with the original
>    reporting entity - if they selected "remove" from a mailling list
>    that they're paying $1000 per year to be listed on, we need to let
>    them know that we honored their request, or if they submitted a
>    non-authenticated request - we need to get them to confirm this,
>    and we probably also need to get them their instructions for how to
>    cancel their account and get a refund. 

If you can't figure out who you sent the mail to, that's not the Report 
Generator's problem.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team

Date: Wed, 24 May 2006 17:23:22 +1000
From: Chris Drake  <[email-masked]>
To: [email-masked]
Subject: [feedback-report] ARF spec oversights

Hi,

There's a few important omissions in the ARF standard that I think
need addressing.

1. Mandatory - Generator identity

   There needs to be a way to distinguish between human-generated
   reports, machine generated reports, vindictive malicious (eg: DoS)
   reports, and 3rd-party (eg: not the original recipient) reports.

   We need some extra mandatory fields to specify this
   
2. Recommended - confirmation status

   As 90%+ of the people on this list should know by now - the effect
   of AOL, Gmail, Hotmail, etc folks putting their "Spam" button right
   next to their "Trash" button means that a large number of users are
   hitting the wrong button by mistake.

   For mail operations who send zero spam and zero unsolicited and
   zero marketing emails, this results in an almost 100%
   false-positive complaint rate - that is - every single "spam" that
   gets reported is a result of a user hitting "Spam" by mistake.

   There needs to be a way for ISP staff to find actual spam
   complaints in amongst this sea of user errors, without having to
   read the personal emails of hundreds of "lame users".

   Having a recommended (or perhaps even mandatory - to highlight how
   important this is!) header to indicate whether or not the user
   "just hit the spam button", or whether they were given an
   opportunity to preview what they were about to report, and actually
   confirmed that it was "spam" - is important.

   Consider also that some emails are highly confidential, and are not
   suitable for sending to abuse desks immediately upon clicking a
   single button: rg: We also recently received a user-error
   spam-report containing some extremely confidential, personal
   banking information.
   
3. Recommended - "Feedback type selected by" header

   Lots of people hit the "spam" button when they get emails from
   their friends or enemies, and that they merely dislike the
   contents.  We need to know how the "Feedback type" was determined:
   is it an accurate description of the reason for the report which
   was something the reporting original recipient selected, or is it
   some kind of generic guess or hard-coded constant inserted by the
   reporting ISPs abuse system ?
   
4. Reporting individual Authentication

   There also needs to be a way to communicate to ARF report
   recipients the results of an authenticity check performed against
   the reporting individual - for example - a third-party might
   maliciously choose "select-all" then "report as spam" with the
   "remove" option selected to cause everyone that a victim
   communicates with to be barred from sending email to the victim in
   future.

   As on ISP administering this bar - I need to know by who's
   *legitimate*, authenticated, authority this bar has been selected.

5. Confirmation requests

   Finally - we need a way to communicate back with the original
   reporting entity - if they selected "remove" from a mailling list
   that they're paying $1000 per year to be listed on, we need to let
   them know that we honored their request, or if they submitted a
   non-authenticated request - we need to get them to confirm this,
   and we probably also need to get them their instructions for how to
   cancel their account and get a refund. 

Kind Regards,
Chris Drake