Subject: Re: [Asrg] FeedBack loops

From: Franck Martin <[email-masked]>
Date: Fri, 14 Nov 2008 08:09:14 +1200 (ANAT)

I feel, there is a need to have a protocol working before advising it as a best practice. 

This could be a task for this research group (I'm not volunterring here ;) ) 

How to analyse email headers and have a successful unsubscription when user says "no more", otherwise report as spam. 

Cheers 
----- Original Message ----- 
From: "J.D. Falk" <[email-masked]> 
To: "Anti-Spam Research Group - IRTF" <[email-masked]> 
Sent: Friday, 14 November, 2008 7:58:07 AM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] FeedBack loops 

On 13/11/2008 12:53, "Franck Martin" <[email-masked]> wrote: 

> So I understand, the misnomer of the SPAM button in some cases. But as 
> inidicated, the logic behind the SPAM button could be to check if there is an 
> unsubscribe and act on it. Saying that all the spammers will add an 
> unsubscribe header to make sure their mails are not realy flag as SPAM. So I 
> guess there must an unsubscribe header and some dkim or other authentication 
> form... There is an idea here... it needs more thoughts? 

It's been discussed many times. Hotmail kinda sorta has something like that 
already, and there was an early-alpha Thunderbird plugin floating around for 
a while. 

This is an area where we need to see some actual MUA-level experimentation 
before we can codify a best practice. 

_______________________________________________ 
Asrg mailing list 
[email-masked] 
https://www.irtf.org/mailman/listinfo/asrg 
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "David Nicol" <[email-masked]>
Date: Thu, 13 Nov 2008 14:27:36 -0600

On Thu, Nov 13, 2008 at 2:09 PM, Franck Martin <[email-masked]> wrote:
> How to analyse email headers and have a successful unsubscription when user
> says "no more", otherwise report as spam.

that unsubs require confirmation makes a general one-click solution
difficult.  Given tight MUA/MTA integration, the button could cause a
check for mailing list headers and when found, issue a 550 at the
inbound border when further messages come from that mailing list
server for the particular user.

-- 
"When laws are outlawed, only outlaws will have laws" -- Ginger Root
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 13 Nov 2008 14:20:26 -0700

> I feel, there is a need to have a protocol working before advising it as a

AOL, Cloudmark, Hotmail, Yahoo!, and many others have had it working for
years.  It's often called a reputation system, and is regularly discussed at
MAAWG and other fora.

---

From: Franck Martin <[email-masked]>
Date: Fri, 14 Nov 2008 10:02:14 +1200 (ANAT)

No this was not what I was talking about. 

We were talking about: "when the user click spam, the system does not send a spam report but an unsubscribe if the mail contains the right headers and the unsubscribe is successful"

---

From: Steve Atkins <[email-masked]>
Date: Thu, 13 Nov 2008 14:31:25 -0800

On Nov 13, 2008, at 2:02 PM, Franck Martin wrote:

> We were talking about: "when the user click spam, the system does  
> not send a spam report but an unsubscribe if the mail contains the  
> right headers and the unsubscribe is successful"

It's been discussed. The critical flaw with the idea is blindingly  
obvious if
you think about it for a second, though.

Cheers,
   Steve

> > I feel, there is a need to have a protocol working before advising  
> it as a
> > best practice.
>

---

From: Franck Martin <[email-masked]>
Date: Fri, 14 Nov 2008 10:51:34 +1200 (ANAT)

yes fake headers, but that's being addressed too, no? 

----- Original Message ----- 
From: "Steve Atkins" <[email-masked]> 
To: "Anti-Spam Research Group - IRTF" <[email-masked]> 
Sent: Friday, 14 November, 2008 10:31:25 AM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] FeedBack loops 

Cheers, 
Steve

---

From: "David Nicol" <[email-masked]>
Date: Thu, 13 Nov 2008 16:53:32 -0600

> yes fake headers, but that's being addressed too, no?

my guess is differentiating between wanting to unsub and reporting to
the shared filter an actual spam that made it onto a mailing list.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Barry Shein <[email-masked]>
Date: Thu, 13 Nov 2008 17:52:49 -0500

> you think about it for a second, though.

All I can come up with is it could be easily defrauded, tho some care
in verifying the source would seem to mostly avoid that problem. It's
not like we're dealing with the family jewels.

I suppose that might not be the spam button clicker's intent.

One gray area that occurs (in practice!) is someone sends a spam-ish,
or even really spam, message to a mailing list and people hit the spam
button sending the complaint to AOL et al.

By "spam-ish" I mean a msg that one can understand on quick skim
may've looked like spam ("ONLY FOUR DAYS LEFT TO BUY YOUR IRTG
T-SHIRTS!") but really isn't spam in the usual sense.

And they're complaining to their own ISP (e.g., AOL) rather than
perhaps the list manager or list ISP in some cases, say where they
know it's about IRTG T-Shirts and what IRTG is but don't want that in
their list discussion so they hit SPAM, but that's not really germaine
to the original comment.

-- 
        -Barry Shein

The World              | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Login: Nationwide
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Steve Atkins <[email-masked]>
Date: Thu, 13 Nov 2008 15:11:18 -0800

> not like we're dealing with the family jewels.

There are several problems with it, but one is
that the feedback loop is set up to return data to the entity signing
up for the feedback loop - which is someone who has demonstrated
that they have some ownership of (usually) the sending IP address.

The unsubscription link is set up to notify whoever the sender of
the email wants it to notify.

If I sign up for a feedback loop such that I want to be notified of any
reports of unwanted email for my /16 I absolutely want to be notified
if the unwanted email has a List-Unsubscribe header. I definitely
don't want spammers who are my customers or who are abusing
my resources to be able to suppress FBL reports that I've asked for.

Conversely, in the case of legitimate ESPs and other senders there's
pretty much no difference between an FBL notification and a
List-Unsubscribe notification. They both go to the same place, and
they both carry the same message.

So, if you have an email that someone has complained about
which has a List-Unsubscribe header then, sure, you might
want to tickle that unsubscription mechanism in addition to
sending an FBL report. But you wouldn't want to do so *instead*
of sending the FBL report - the only time where that would be
"safe" to do would be when you can confirm (via DKIM would
be one obvious route) that the recipient of the List-Unsubscribe
action and the FBL action are one and the same - and even in
those cases there is no negative result to sending the FBL
report instead of or as well as the unsub.

(Whether an MUA should have an unsubscribe button, in the
case where it's a trusted sender with a List-Unsubscribe header
in some standard form, instead of or in addition to a TiS button
is a whole other issue. I believe some ISPs have done so, but I've
not seen any reports as to how well it's worked.)

Cheers,
   Steve

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 13 Nov 2008 20:52:32 -0500

> We were talking about: "when the user click spam, the system does not send a spam report but an unsubscribe if the mail contains the right headers and the unsubscribe is successful" 

First, there's no way for the web interface to know if the unsubscription
request was successful -- presuming that it's submitted via the address
specified in the RFC 2369 headers.

But second, and this is the much larger problem: widespread adoption of
this will almost instantly lead to its mass exploitation by spammers.

---Rsk

---

From: Barry Shein <[email-masked]>
Date: Thu, 13 Nov 2008 21:31:05 -0500

> specified in the RFC 2369 headers.

Is that important? Any unsubscription confirmation email should go
back to the subscriber.

 > this will almost instantly lead to its mass exploitation by spammers.

How? Maybe I lack imagination, but why is this any more of a problem
than spammers just sending unsub etc requests now?

One would hope the path between a customer clicking a spam complaint
button and the service provider is reasonably reliable. And the unsub
could be verified by the same sort of means it might be verified
today.  For example I might only execute an unsub from AOL if it came
either from a customer who was actually sub'd to the list or from
AOL's feedback loop MTA. I suppose an FBL could also set up some sort
of asymmetric key pair method at setup.

But maybe I'm missing something entirely.

-- 
        -Barry Shein

---

From: Steve Atkins <[email-masked]>
Date: Thu, 13 Nov 2008 18:42:03 -0800

> But maybe I'm missing something entirely.

I think so, yes.

The suggestion is that the sender of the email can suppress sending
a report via feedback loop by including an unsubscription link in the
headers of the mail.

One flaw with that is that this allows spammers to suppress feedback  
loop
reports. Consider the (usual) case where the recipient of the feedback
loop is not the author of the original email, rather they're a service  
provider
to the original author.

Cheers,
   Steve

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 14 Nov 2008 12:21:29 +0000

--On 13 November 2008 14:27:36 -0600 David Nicol <[email-masked]> 
wrote:

>> How to analyse email headers and have a successful unsubscription when
>> user says "no more", otherwise report as spam.
>
> difficult.

They needn't require confirmation. It might be better to send a 
notification, including a mechanism for restoring subscription. Also 
including, if necessary, a mechanism for getting delivery of any email 
messages that have been missed in the mean time.

> Given tight MUA/MTA integration, the button could cause a

-- 
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 14 Nov 2008 12:28:12 +0000

> a report via feedback loop by including an unsubscription link in the

Huh? How is that a problem. If the email is from a feedback loop provider, 
then it doesn't matter whether the "report" is a feedback loop report, or 
through use of the unsubscription link. Spammers will ignore either, but 
genuine list owners will - presumably - find it easier to process requests 
using the link that they've provided.

> One flaw with that is that this allows spammers to suppress feedback loop
> provider to the original author.

Then the feedback loop provider needs to use both mechanisms, and perhaps 
be able to indicate whether the unsubscribe mechanism was attempted.

---

From: der Mouse <[email-masked]>
Date: Fri, 14 Nov 2008 07:30:01 -0500 (EST)

> They needn't require confirmation.

Quite.  Or, to put it another way, unsubs don't require confirmation;
some implementations of unsubs do.

It's always seemed broken to me.  Unless there's been a history of
unsub attacks or some such to justify it, I can't see any reason to
require confirmation for unsubs.  Ideally it would be a
per-subscription option, since people as well as lists can have a
history of attracting the sort of people who'll forge unsubs.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 14 Nov 2008 07:38:53 -0500

On Fri, Nov 14, 2008 at 12:21:29PM +0000, Ian Eiloart wrote:
> notification, including a mechanism for restoring subscription. 

A decade ago, I would have concurred with this, but given ensuing
events, I think it's now a best practice to require confirmation
in order to forestall the inevitable abuse.

---Rsk

---

From: der Mouse <[email-masked]>
Date: Fri, 14 Nov 2008 07:50:04 -0500 (EST)

>> [Unsubs] needn't require confirmation.
> events, I think it's now a best practice to require confirmation in
> order to forestall the inevitable abuse.

I'm not convinced.  Forge-unsubbing someone from a list does not gain
the unsubber anything directly (for most lists), so it's useful mostly
as a harassment mechanism.  This means that a few prominent people need
it; so do a few unusual lists.  But most subscriptions to most lists do
not, I think, need unsub confirmations.  Ideally, I think, unsub
confirmations should be an option that the individual subscriber can
turn on (for the prominent people) or a listadmin can turn on (for the
unusual lists), but which is normally off.

Or is there history I'm not aware of indicating that most subscriptions
to most lists _do_ need unsub confirmations?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 14 Nov 2008 07:42:50 -0500

> Is that important? Any unsubscription confirmation email should go

Well, I'm not sure if it's important or not.  But I'm concerned about
how this process will work from the user's point of view.

Some lists allow unsubscription without confirmation, and in a case
like that, a button-generated unsubscription request should work without
any further involvement of the user.

But some lists require confirmation, and in that case, the user will
need to wait for a second message, understand that it's a request for
confirmation and reply to it -- which can't be done with the button.
(That is, presuming the code behind the button is set up to process
RFC 2369 headers and not to attempt to parse the myriad formats of
unsubscription confirmation messages.)

(BTW, I think requiring confirmation is a good idea, so I'm not arguing
against that.)

> than spammers just sending unsub etc requests now?

Because spammers will quickly learn to attach RFC 2369 headers to
their messages, and will use "unsubscription" requests for anything
but that -- for example, they'll use this to confirm that addresses
are valid and that traffic to them is being read.  (I'm thinking back
here to the days of Return-Receipt.)

Or they'll cause the RFC 2369 "unsubscribe" header to point to
a "subscribe" link.  Or they'll point it to unrelated third parties.
And so on.

The bottom line is that nothing spammer-generated in a spam can be
trusted, so taking any action based on it opens the door to abuse.

---Rsk

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 14 Nov 2008 08:18:31 -0500

> in order to forestall the inevitable abuse.

There are ways to avoid needing confirmation (or worse, passwords) that
still protect against malicious unsubscribes.

The MAAWG sender BCP talks about saying that unsubs should be a "single
action", and not require any additional information (eg: "confirmation
cycle" or password).

Each email message's unsub links should contain everything needed to do
an unsub in one action - the user doesn't need to know another password,
and then goes on to say that if malicious unsubscriptions are a concern,
that "everything" could include a magic cookie that only the recipient
of the email sees (in the link) that serves as a password for the unsubs.

Which means that a compliant mailing list, no matter how your address
got on the list, can be unsubbed with a single action, and no
out-of-band info is needed.

"Single action" being intended to mean either unsubs immediately on
clicking the link, or, being presented with an "you're unsubbing from
<x>, <click> to do it".  Not a password or confirmation.

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 14 Nov 2008 08:51:23 -0500 (EST)

> action", and not require any additional information (eg: "confirmation

The unsubscribe URL could contain a cookie in addition to the email 
address to prevent malicious unsubscriptions, if such a thing became a 
problem.

---

From: Seth <[email-masked]>
Date: Fri, 14 Nov 2008 08:52:53 -0500 (EST)

> using the link that they've provided.

A spammer sending through a legitimate provider (who was fooled into
thinking the spammer was legitimate) will not be reported to its
provider.  That's a Bad Thing.

> be able to indicate whether the unsubscribe mechanism was attempted.

Right; and there's no need to indicate anything about the unsubscribe
(which shouldn't be attempted, since it might validate the address for
a spammer's benefit).

Seth

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 14 Nov 2008 09:04:39 -0500

> address to prevent malicious unsubscriptions, if such a thing became a 

I think that's what I just said.  In fact, I'm the guy who put it in the
Sender BCP ;-)
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 14 Nov 2008 09:14:50 -0500

> provider.  That's a Bad Thing.

Assumes it's not reported to the provider.  I can't see any reason why
the provider wouldn't keep track of all "unsubscribes" as well, and
start treating them as "this is spam" hits if the sender demonstrates a
propensity for generating large numbers of unsubs.

IOW, have only one button:
   a) if the provider has some reason to believe this is most
      appropriate as an unsub (_including_ sender asserts that
      it is, or message has appropriate List-ID headers), issue an
      unsub.  Count them as "A".
   b) if the provider doesn't think it's an unsub, count it as a spam
      complaint "B", no unsub.
   c) If "A" rate is > some threshold, treat new button hits as spam
      complaints ("B") instead (perhaps with a multiplier depending on
      BOFHishness) and don't unsub.
   d) Tune filters from B.

We have enough problems with senders mashing the one button they have
inappropriately.  Two buttons will just make the problem worse.  This is
more of a human factors exercise than a technical one.

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 14 Nov 2008 09:41:48 -0500

> of the email sees (in the link) that serves as a password for the unsubs.

This sounds reasonable, but I have some concerns with it.

First, it requires sending individual messages to each subscriber,
doesn't it?  Which in turn increases mail traffic, because it's no
longer possible to deliver the same message to some/all subscribers
at a given MX.

Second, I'm concerned that the lack of a closed loop will be exploited.
Granted, to date, that exploitation seems to be pretty much limited to
nuisance unsubscription requests, and granted, I don't think we've seen
anything else -- yet.  But this makes me uneasy, because (as I've learned)
the adversary has on occasion shown considerable ingenuity in exploiting
openings we'd previously considered inconsequential.  Let me think about
this for a few days and see if I can't come up with something more tangible.

---Rsk

---

From: SM <[email-masked]>
Date: Fri, 14 Nov 2008 05:54:34 -0800

>history of attracting the sort of people who'll forge unsubs.

It's better not to wait for the unsub attacks to prevent it from 
happening.  Sometimes we may take an action based on the information 
we receive from a list.  Without the confirmation, we would not be 
aware that the information may no longer be available to us.

>here to the days of Return-Receipt.)

They already do.

>trusted, so taking any action based on it opens the door to abuse.

Right.

>of the email sees (in the link) that serves as a password for the unsubs.

Sometimes the subscriber resends the message, including full 
headers.  The magic cookie is then disclosed to third parties.

Regards,
-sm

---

From: "David Nicol" <[email-masked]>
Date: Fri, 14 Nov 2008 11:17:24 -0600

> history of attracting the sort of people who'll forge unsubs.

Unsub attacks are very real, and were once an effective but blunt
mailing list argument tactic.The logic went something like:  Why
should I killfile this flamer when I can jwith equal ease unsub him
and save the rest of the list readership the trouble?  He's a luser
anyway so he'll just think its a slow list day.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 14 Nov 2008 17:29:26 +0000

--On 14 November 2008 05:54:34 -0800 SM <[email-masked]> wrote:

> happening.  Sometimes we may take an action based on the information we
> receive from a list.  Without the confirmation, we would not be aware
> that the information may no longer be available to us.
>

You can close that gap with a notification message, which gives access to 
the missing information. Something like this:

Click here if you didn't mean to unsubscribe.
Click here to see the messages you've missed.
Click here to protect your subscription.

> Sometimes the subscriber resends the message, including full headers.
> The magic cookie is then disclosed to third parties.

Yes, so it would be best practice for mail clients not to do that by 
default. It would also be sensible to have a time-sensitive cookie, to 
reduce the window of opportunity for abuse, and to limit repeat attacks.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 14 Nov 2008 17:35:24 +0000

> longer possible to deliver the same message to some/all subscribers

It does. But, 90% of my site's inbound email is to single recipients. And, 
all my outbound list traffic is VERP'd anyway.
...
-- 
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Seth <[email-masked]>
Date: Fri, 14 Nov 2008 12:53:49 -0500 (EST)

> headers.  The magic cookie is then disclosed to third parties.

If that discourages people from copying entire messages when replying,
I fail to see how it's a bad thing.

Seth

---

From: Barry Shein <[email-masked]>
Date: Fri, 14 Nov 2008 14:01:04 -0500

It's astounding to me how for over 30 years we've been trying to turn
email into a general purpose application without actually trying to
own the problem. Believe me, I've been sitting right here for all
those 30 years.

As an analogy replace "email headers" with "tcp packet headers" and
imagine trying to shove unsub and so on into those year in and year
out.

THAT SAID, maybe an approach would be, instead, a fairly strictly
defined mime body type for operations like unsub which would tend to
frustrate a spammer from adding their own spam load. That is, spam
wouldn't conform so it could be easily rejected at various levels
(MTA, MUA, manually.)

I suppose such an idea would have to allow certain other mime body
parts, email signatures come to mind.

Or maybe "there madness lies"?

But just as with other protocols (e.g., tcp packets) some superficial
notion of whether it's even conforming, and restricting
conformationaltude to what it claims to be (e.g., an unsub) would seem
to help, along with other practical suggestions made.

Well, far be it for me to suggest that one way to avoid abuse of a
protocol is to define that protocol.

BUT MY REAL POINT IS -- design by open-ended enumeration of specific
examples tends to go poorly.

Maybe some more general purpose mechanism limiting a functional email
message like an unsub to the truth, the whole truth, and nothing but
the truth, helps in general.

Hmmm...

    and what rough beast, its hour come round at last,
    slouches towards EDI to be born?

One gets the creepy feeling this is slouching towards something
EDI-like wrapped in XML wrapped in MIME wrapped in email.

-- 
        -Barry Shein

---

From: Franck Martin <[email-masked]>
Date: Sat, 15 Nov 2008 07:22:55 +1200 (ANAT)

The problem with all the security protocols put by IETF, is that they don't go the extra mile, which is to make it user friendly. It is left to in our case mail client developers to put it in their application and they don't because it won't seem easy for my mum to use. 

PS: Not sure if you have noticed, there is an invite only meeting at IETF to plan a test of a large deployment of ("enforced"?) DKIM. 

----- Original Message ----- 
From: "Barry Shein" <[email-masked]> 
To: "Anti-Spam Research Group - IRTF" <[email-masked]> 
Sent: Saturday, 15 November, 2008 7:01:04 AM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] FeedBack loops 

Hmmm... 

-- 
-Barry Shein

---

From: "David Nicol" <[email-masked]>
Date: Fri, 14 Nov 2008 13:43:42 -0600

> examples tends to go poorly.

For design it might suck, but for requirements gathering open-ended
brainstorming kicks ass.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Steve Atkins <[email-masked]>
Date: Fri, 14 Nov 2008 12:10:40 -0800

> For design it might suck, but for requirements gathering open-ended

When everyone involved is familiar with the current practices and  
issues, it can be. When a significant fraction aren't it's much more  
likely to end up being less useful.

Spam-related groups tend to have many more people interested in them  
than more prosaic protocol development groups, which is positive in  
some respects.

Cheers,
   Steve

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 14 Nov 2008 13:40:59 -0700

> For design it might suck, but for requirements gathering open-ended

...if you have all the relevant parties represented.  Otherwise, you're
likely to overlook or otherwise discount some common use cases.

Which is exactly what's happening here.

Again.

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 14 Nov 2008 16:58:57 -0500

> likely to end up being less useful.

s/less useful/actively harmful/

> than more prosaic protocol development groups, which is positive in  

And negative in others.