Subject: [Asrg] Spam button scenarios

From: "John R. Levine" <[email-masked]>
Date: 8 Feb 2010 01:28:59 -0500

Here's some scenarios in which I'm not sure what the best thing is to do.

A) User has multiple incoming accounts, presses the spam button, and the 
outbound MSA doesn't match the incoming account.  Hence the report goes 
via unrelated third parties that might snoop on it.  Do we care?  The user 
has said it's spam, after all.

B) Assume a model in which the spam reporting address is determined per 
account, e.g., fetched from the POP or IMAP server via an extension.  The 
user for whatever reason moves a message from account A into the IMAP 
mailbox for account B and then hits the spam button, which sends the 
report to B, even though the message was from A.  Do we care?  It's the 
user's fault, although I can think of some simple configurations that 
would cause that, e.g., MUA based spam filter that puts all the junk into 
the Junk folder on the first IMAP account.

C) I have a Gmail account and a Yahoo account.  The Gmail account is set 
up to fetch my Yahoo mail so I can see it all in one place.  I use Gmail's 
IMAP server to read my mail.  (I really do this, by the way.)  I hit the 
spam button.  Who should get the report?

  1) Gmail since that's who I picked it up from
  2) Yahoo since that's where the spam was sent
  3) Gmail but they should also forward the report to Yahoo

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Sun, 7 Feb 2010 23:15:39 -0800

> Here's some scenarios in which I'm not sure what the best thing is to do.

I'm assuming that this is all in the context of a TiS button in the MUA that is used primarily to drive a FBL run by the mail system operator and to control filters. If that's not the intent then all bets are off.

> 
> A) User has multiple incoming accounts, presses the spam button, and the outbound MSA doesn't match the incoming account.  Hence the report goes via unrelated third parties that might snoop on it.  Do we care?  The user has said it's spam, after all.

No, I don't care that someone might snoop on it (though you should see the "spam reports" that come into a typical abuse desk - usernames, passwords, CC numbers, banking info, so someone might care). The inbound email went across the open internet, and any generated FBL report will go across the open internet too.

As long as the "wrong" MSA sends the message to the right address that's just fine (and it's fairly common, I think, for users with multiple inbound accounts to use a single submission account for all of them, so this doesn't seem an unusual case).

> B) Assume a model in which the spam reporting address is determined per account, e.g., fetched from the POP or IMAP server via an extension.  The user for whatever reason moves a message from account A into the IMAP mailbox for account B and then hits the spam button, which sends the report to B, even though the message was from A.  Do we care?  It's the user's fault, although I can think of some simple configurations that would cause that, e.g., MUA based spam filter that puts all the junk into the Junk folder on the first IMAP account.

We do care, somewhat.

We'd prefer not to send it to someone other than the mail account we received it from, for several reasons. One is that they're unlikely to be able to do the right thing with it and automated processing of it is likely to break in some respects. It's not something they'll be able to use to tune their filters, and it's not mail they should see and be sending out via their FBLs.

We see this today, where quite a lot of email is sent from original sender A, to freemail provider B, to freemail provider C. The TiS button at provider C sends an FBL report directly to sender A, about an email sender A didn't send to them. At best, this is confusing and makes a mess of the statistics.

At the MUA the metadata about the local provider to talk to should really be attached to the message, not the mailbox.

> 
> C) I have a Gmail account and a Yahoo account.  The Gmail account is set up to fetch my Yahoo mail so I can see it all in one place.  I use Gmail's IMAP server to read my mail.  (I really do this, by the way.)  I hit the spam button.  Who should get the report?

> 3) Gmail but they should also forward the report to Yahoo

Yahoo are the right people to actually do something with a report. So (2) would be ideal (The metadata about who the local provider TiS reports should be sent to should be attached to the message at the MX, not added after the fact by the mail spool or intuited by the MUA based on where the message was found).

But (1) or (3) wouldn't be catastrophic, assuming competent handling at Gmail, as Gmail know that it was not sent to them, so they shouldn't send a FBL report or adjust reputation based on it. They might special case "mail fetched from Yahoo via IMAP" and forward it back to them in a way both parties understand, which would be OK. Or they might take advantage of metadata on the message to send it to Yahoo, which would be OK too. Or they might just drop it on the floor, which would also be OK.

It'd be a bit of a mess, but it's Gmails mess to deal with, and they're going to have to work out what to do (the base level of throwing the reports away is just fine with me, and they can probably do something smarter than that).

What would be less ideal would be the case I mentioned above, where Gmail sends an FBL report back to the original sender (based on a DKIM based FBL, maybe).

What wouldn't be OK would be if the report is made to Gmail and then Gmail consider it to be spam sent by Yahoo, and send a FBL message to Yahoo and damage Yahoos reputation. That shouldn't happen with chained IMAP, but it's what'll happen in some cases if it's done via SMTP forwarding.

Cheers,
  Steve

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 8 Feb 2010 07:59:50 -0500 (EST)

On Mon, 8 Feb 2010, John R. Levine wrote:

> outbound MSA doesn't match the incoming account.  Hence the report goes via 
> unrelated third parties that might snoop on it.  Do we care?  The user has 
> said it's spam, after all.
>

The user trusts his good outgoing mail to that MTA - why should she not 
trust her spam to the same MTA?

> user for whatever reason moves a message from account A into the IMAP mailbox 
> for account B and then hits the spam button, which sends the report to B, 
> even though the message was from A.  Do we care?  It's the user's fault, 
> although I can think of some simple configurations that would cause that, 
> e.g., MUA based spam filter that puts all the junk into the Junk folder on 
> the first IMAP account.
>

The ARF system at the MTA may examine the headers to make sure the report 
came through it or it has the potential to process ARF reports possibly 
intended for another MTA. Howeever, this is not a serious mistake, if it 
is one at all. If MTA A revises its content filter based on what it learns 
from a spam sent through MTA B, then no harm has been done.

> C) I have a Gmail account and a Yahoo account.  The Gmail account is set up 
> to fetch my Yahoo mail so I can see it all in one place.  I use Gmail's IMAP 
> server to read my mail.  (I really do this, by the way.)  I hit the spam 
> button.  Who should get the report?
>

GMAIL is your MUA. It should report to Yahoo, but I don't see any harm in 
it acting on the information itself. Lots of MUAs have built in spam 
filters - it is perfectly reasonable that the TIS button help those 
filters.

Daniel Feenberg

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 08 Feb 2010 13:03:12 +0000

--On 8 February 2010 01:28:59 -0500 "John R. Levine" <[email-masked]> wrote:

> via unrelated third parties that might snoop on it.  Do we care?  The
> user has said it's spam, after all.

Snooping might well be an issue, for example, it might be a false positive 
where the actual message contains confidential information. The reporter is 
using a system that supposedly communicates with their service provider. 
Reporting a message to the mailstore operator (who can already read it from 
the mailstore) is a lot less sensitive than forwarding it to the operator 
of a third party mailstore.

What else might we care about? That we're failing to actually report the 
message? That we're spamming the unrelated third party? That the unrelated 
third party's automatic processor might generate an onward report about an 
unrelated message?

> report to B, even though the message was from A.  Do we care?

We don't care as much. The message is already visible to the operator of 
the second mailstore.

>  It's the
> up to fetch my Yahoo mail so I can see it all in one place.  I use
> Gmail's IMAP server to read my mail.  (I really do this, by the way.)  I
> hit the spam button.  Who should get the report?
>

This is already a problem with simple forwarding. I get ARF reports from 
AOL for messages that originated elsewhere, but were forwarded by my SMTP 
servers.

The answer, I think, is that the report should go to Gmail, and they should 
forward the report to Yahoo if they're sure of the origin of the mail. If 
they're fetching it using POP or IMAP, that's the case. Otherwise some kind 
of feedback loop is required (or SPF or DKIM matches).

> R's,
> John
> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Andreas Saurwein Franci Gonçalves <[email-masked]>
Date: Mon, 8 Feb 2010 10:41:58 -0300

Sorry guys, but you are trying to solve a problem which affects less than 1%
of the internet population. 99% of the users dont know that any of this is
even possible and would have not the slightest idea why they would use it.

If all of you would simply exclude YOUR use of email and concentrate on
"real" email users, "the problem" could be solved much easier and faster.

"We" advanced users and administrators tend to forget that normal people
still take screenshots of a Powerpoint presentation, paste them into a Word
document and send the doc as attachment with Outlook because thats what they
know how to use. They read their email on gmail.com, yahoo.com, hotmail.com,
etc. All the efforts of developers to consolidate mail accounts are just
that - developer efforts.

Thats my 2 cents based on 15 years experience with 100k+ "users".

On 8 February 2010 03:28, John R. Levine <[email-masked]> wrote:

> mailbox for account B and then hits the spam button, which sends the report
> to B, even though the message was from A.  Do we care?  It's the user's
> fault, although I can think of some simple configurations that would cause
> that, e.g., MUA based spam filter that puts all the junk into the Junk
> folder on the first IMAP account.
>

---

From: John Levine <[email-masked]>
Date: 8 Feb 2010 14:11:40 -0000

Hi.  Please say "POP" a hundred times before proceeding.

>the mailstore)

Mailstore?  This is a POP account.

>AOL for messages that originated elsewhere, but were forwarded by my SMTP 

Except that there's no forwarding here.  Gmail should know that it got
the message by POPing it from Yahoo.  I agree that pinning the blame for
spam sent through courtesy forwards is a black hole, and we're not going
to solve it here.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 08 Feb 2010 14:19:51 +0000

> trust her spam to the same MTA?

It's a different case. We're sending email to an address at that MTA, and 
drawing attention to it.

The main problem here, though, is that the user thinks they're reporting 
spam, but in fact they're generating it.

>> account, e.g., fetched from the POP or IMAP server via an extension.
>> The  user for whatever reason moves a message from account A into the
>> IMAP mailbox  for account B and then hits the spam button, which sends
>> the report to B,  even though the message was from A.  Do we care?  It's
>> the user's fault,  although I can think of some simple configurations
>> that would cause that,  e.g., MUA based spam filter that puts all the
>> junk into the Junk folder on  the first IMAP account.
>>
>
> is one at all. If MTA A revises its content filter based on what it
> learns from a spam sent through MTA B, then no harm has been done.
>
>> Gmail's IMAP  server to read my mail.  (I really do this, by the way.)
>> I hit the spam  button.  Who should get the report?
>>

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Feb 2010 15:31:40 +0100

> has said it's spam, after all.

We care that reports get lost. However, picking the wrong MSA should 
at most result in a suboptimal delivery path. Was the destination 
address correct?

> would cause that, e.g., MUA based spam filter that puts all the junk
> into the Junk folder on the first IMAP account.

Assume the MUA doesn't track moving the message. Using A-R fields, it 
would find the one from A, but since it is not trusted on B's mailbox 
the MUA shouldn't use it.

Alternatively, the MUA can determine the validity of the top A-D field 
when it downloads the message. That would be useful for displaying A-R 
icons in message listing panes. And, it would allow to report the 
message as spam --to the right server-- even after it has been moved 
to a different account.

> 3) Gmail but they should also forward the report to Yahoo

By symmetry, #3. But what A-R fields do you get in messages 
transferred that way?

If I had

   Authentication-Results: mx.google.com; spf=pass (google.com: domain
    of [email-masked] designates 62.94.243.226 as permitted sender)
    smtp.mail=[email-masked]

then I would report to [email-masked] --I currently cannot, 
because there's no such domain.

Is there any report on current A-R usage?

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 08 Feb 2010 14:51:28 +0000

--On 8 February 2010 15:31:40 +0100 Alessandro Vesely <[email-masked]> 
wrote:

> We care that reports get lost. However, picking the wrong MSA should at
> most result in a suboptimal delivery path. Was the destination address
> correct?

Who knows. If the report arrives by any path other than a Message 
Submission Server, then the recipient has no reason to trust it.

---

From: John Levine <[email-masked]>
Date: 8 Feb 2010 15:05:13 -0000

>spam, but in fact they're generating it.

No, no.  I was assuming that the user was sending reports to a reasonable
address, not one made up from the name it uses to find its POP or IMAP
server.  (See other threads for why that's hopeless.)  The question is
whether it's a problem that the spam report takes a detour through someone
else's mail system on its way.

R's,
John

---

From: Derek Diget <[email-masked]>
Date: Mon, 08 Feb 2010 10:30:50 -0500 (EST)

On Feb 8, 2010 at 15:31 +0100, Alessandro Vesely wrote:
=>On 08/Feb/10 07:28, John R. Levine wrote:
=>> Here's some scenarios in which I'm not sure what the best thing is to do.
=>> 
=>> A) User has multiple incoming accounts, presses the spam button, and the
=>> outbound MSA doesn't match the incoming account. Hence the report goes
=>> via unrelated third parties that might snoop on it. Do we care? The user
=>> has said it's spam, after all.
=>
=>We care that reports get lost. However, picking the wrong MSA should at most
=>result in a suboptimal delivery path. Was the destination address correct?

Picking the wrong MSA could also result in lost reports.  The "wrong" 
MSA might have different filters/rules running on it (not having the ARF 
reporting address white-listed/scan exception) which could cause the TiS 
message to get rejected/quarantined/redirected/dropped and thus not 
making it to the intended recipient (ARF reporting address).

Not really wanting to open another "deliverability" sub-thread or debate 
the merits of SPF/DKIM, but....  IMO as more sites start to move to a 
SPF -all, or sign their out-bound MSA messages with DKIM using the 
"correct" MSA becomes more and more of a requirement if the user 
(sender) wants their e-mail to get to the recipients.  Using the correct 
MSA is not just a TiS submitted via SUBMIT issue.

-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

---

From: Martijn Grooten <[email-masked]>
Date: Mon, 8 Feb 2010 16:24:52 +0000

> has said it's spam, after all.

In theory this may be an issue for a small number of organizations, because if TiS buttons are being used by a large enough number of users, then some of these users will click TiS for legitimate emails, and some of these emails will actually contain confidential information and a still non-zero number of reports will go via unrelated third parties. In practise I would imagine the risk of confidential data leaking through other routes to be significantly bigger. (And of course nothing will stop, say, the CIA from disabling the sending of TiS reports altogether. Or paranoid company X from scanning outbound TiS reports for confidential information.)

> Gmail's

3: your MUA doesn't know anything other than that it receives email from Gmail's IMAP server. You can of course tell your MUA that Gmail fetches mail from Yahoo, but not everyone is going to do that, so just sending it to Gmail would be the simplest thing to do. Gmail should know that in this scenario it also acts as an MUA and as such should forward the report to Yahoo. It could, of course, still use the report to improve its own spam filter.

Martijn.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

---

From: der Mouse <[email-masked]>
Date: Mon, 8 Feb 2010 12:45:36 -0500 (EST)

> Hence the report goes via unrelated third parties that might snoop on
> it.  Do we care?  The user has said it's spam, after all.

Yes...but users already use their TiS mechanisms on ham accidentally,
to the point where they will often doubt they did so when confronted
with the fallout.  I see no reason to think the mechanism being
discussed here will be any different in this regard.

/~\ 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

---

From: Bill Weinman <[email-masked]>
Date: Mon, 08 Feb 2010 12:58:59 -0700

> 3) Gmail but they should also forward the report to Yahoo

One way to look at this is: Which choice benefits the user most?

Since the Yahoo mail is being forwarded to Gmail, I would think it would 
be more valuable to have Gmail doing the spam filtering. Yahoo probably 
cares that they have the opportunity to train their spam filters, but 
from the user's perspective I think Gmail is the one that matters in 
this scenario.

--B

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 8 Feb 2010 15:19:37 -0500

> has said it's spam, after all.

I'm leaning back towards inband (eg: RFC5451 AR header as extended), 
thus your B is moot, and addressing choices (sans trust issues) is trivial.

>   3) Gmail but they should also forward the report to Yahoo

Very much Gmail.  If they want to chain it back to Yahoo as part of 
their FBL, they can.

---

From: Seth <[email-masked]>
Date: Mon, 8 Feb 2010 15:24:05 -0500 (EST)

Bill Weinman <[email-masked]> wrote:

> Since the Yahoo mail is being forwarded to Gmail, I would think it
> would be more valuable to have Gmail doing the spam filtering.

Why?  If _either_ of them blocked it, the user wouldn't see it.

Training Yahoo helps the user if he later switches to having someone
else pick up his mail from Yahoo.  Training google doesn't.

Training google to see mail forwarded from Yahoo as spam can have
adverse effects for him.

So it's better to train Yahoo.  (Now, if you believe that google
trains much better than Yahoo, that's an important difference.)

Seth

---

From: Steve Atkins <[email-masked]>
Date: Mon, 8 Feb 2010 12:24:36 -0800

On Feb 8, 2010, at 12:19 PM, Chris Lewis wrote:

> I'm leaning back towards inband (eg: RFC5451 AR header as extended), thus your B is moot, and addressing choices (sans trust issues) is trivial.
> 
> Very much Gmail.  If they want to chain it back to Yahoo as part of their FBL, they can.

Even though the mail was never received by Gmail, just fetched by them from the IMAP server it was delivered to?

If the reporting address is included in the AR header as added at the Yahoo MX, that would't be overwritten by Gmail, I don't think?

Cheers,
  Steve

---

From: Martijn Grooten <[email-masked]>
Date: Mon, 8 Feb 2010 20:50:24 +0000

> Training google to see mail forwarded from Yahoo as spam can have

Firstly, I think the scenario didn't talk about forwarding, but rather about fetching email using POP3 (or possibly IMAP). Secondly, if Gmail did receive forwarded mail and then considered a click on the TiS button (which has always been there in Gmail) to automatically mean "this IP address is a spammer", then it's doing something wrong. (And given then Gmail itself can be set easily to forward email, they're unlikely to act this way.)

> trains much better than Yahoo, that's an important difference.)

But the only thing your MUA can be sure about is where it received the email from (Gmail's IMAP). It may have a good reason to think that Gmail fetched the email from Yahoo, but it has to trust Gmail for that. Which might be okay if Gmail is really Gmail and Yahoo is really Yahoo, but not if Gmail is a random IMAP server $x and Yahoo is a random POP3 server $y and you as an end user haven't explicitly told the MUA how it receives email.

So I think the only right thing to do is to send the report to Gmail.

Gmail (or $x) then knows that (and how) it received the mail from Yahoo (or $y) and hopefully knows it is best to forward the report.

Martijn.

---

From: John Levine <[email-masked]>
Date: 9 Feb 2010 01:12:56 -0000

>Who should get the report?
>> 

>Even though the mail was never received by Gmail, just fetched by
>them from the IMAP server it was delivered to?

POP server, actually, but sure, it's advice to gmail on server tuning.

>If the reporting address is included in the AR header as added at the
>Yahoo MX, that would't be overwritten by Gmail, I don't think?

Depends whether they want to handle the reports, which they very well
might, e.g., mark their copy as spam, tune filters, then pass it along
to whoever they got it from.

It occurs to me that this could work reasonably well in a dumb
forwarder case.  If A forwards to B, and A supports spam reports but B
doesn't, A's header will still be there for the recipient.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 15:11:59 +0000

--On 8 February 2010 15:05:13 +0000 John Levine <[email-masked]> wrote:

>>>> A) User has multiple incoming accounts, presses the spam button, and
>>>> the outbound MSA doesn't match the incoming account.  Hence the report
>>>> goes via  unrelated third parties that might snoop on it.  Do we care?
>>>> The user has  said it's spam, after all.
>>>>
>>>
>> It's a different case. We're sending email to an address at that MTA,
>> and  drawing attention to it.
>>
> server.

And not one found in a header in a spam message, either, I hope.

>(See other threads for why that's hopeless.)  The question is

There are two possibilities here:

The user retrieves a message from our mailstore, and attempts to use a 
third party address to report it. We'll not likely take much notice of 
reports from addresses outside our domain, that are purporting to have 
knowledge of what's on our mailstore. If the message isn't still on our 
mailstore, there won't be an easy way to verify that it ever was - and 
there certainly won't be an easy way to verify that the message in the 
report is unmodified.

The user retrieves a message from our mailstore, and attempts to use an 
address in our domain to report it to us, but submitted through a third 
party MSA. We'll simply reject the message on the basis that we don't 
permit such traffic onto our MX servers. We won't even look at the message 
body.

Either way, the report won't be actioned.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 15:14:32 +0000

> Why?  If _either_ of them blocked it, the user wouldn't see it.

That's an interesting question. Does gmail filter mail that it fetches 
through POP?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Feb 2010 17:32:42 +0100

On 09/Feb/10 16:11, Ian Eiloart wrote:
> permit such traffic onto our MX servers. We won't even look at the
> message body.

There's a whole theory of other ARF messages that may arrive at a 
domain's abuse@ mailbox. A domain's user, or someone writing to a 
forwarded address of that domain, writes a message that is reported as 
spam, either correctly or by mistake. As part of an FBL or other 
trust-chain, the message comes back wrapped in an ARF report at the 
apparently originating domain.

The mailbox is abuse@domain in both cases. Although it may seem 
desirable to have different addresses for incoming and outgoing 
reports, I doubt such distinction will ever be effective. Indeed, the 
forwarded case is ambiguous.

A mail domain worth its salt should be able to recognize if the 
original message had been mailed out from its premises, and who is its 
blamed author or sender. Policies spell out sequent actions.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 9 Feb 2010 08:45:41 -0800

On Feb 9, 2010, at 8:32 AM, Alessandro Vesely wrote:
> 
> There's a whole theory of other ARF messages that may arrive at a domain's abuse@ mailbox. A domain's user, or someone writing to a forwarded address of that domain, writes a message that is reported as spam, either correctly or by mistake. As part of an FBL or other trust-chain, the message comes back wrapped in an ARF report at the apparently originating domain.
> 
> The mailbox is abuse@domain in both cases. Although it may seem desirable to have different addresses for incoming and outgoing reports, I doubt such distinction will ever be effective. Indeed, the forwarded case is ambiguous.

If you think that any part of this chain is involving mail sent to abuse@ anywhere your model of it is a long way from how I understand the situation.

Rather there's one part of the chain that involves an end users MUA reporting a TiS button hit to their mail provider in a machine readable manner. That may well be done via SMTP, but if so it'll be to a dedicated email address (or set of email addresses) used solely for that function.

The other part of the chain involves feedback loops, which are sent in response to the TiS hit. Pretty much all current ones are sent via SMTP, but not typically to an abuse@ address (it's certainly not best practice to do it that way). Again, they're intended for entirely automated handling and so are machine readable.

Both parts of the service involve solicited, machine readable messages sent under a contractual agreement. That's very different from an abuse@ alias, which is dominated by unsolicited messages that are not intended to be machine readable.

Cheers,
  Steve

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 17:38:12 +0000

--On 9 February 2010 17:32:42 +0100 Alessandro Vesely <[email-masked]> 
wrote:

> The mailbox is abuse@domain in both cases. Although it may seem desirable
> to have different addresses for incoming and outgoing reports, I doubt
> such distinction will ever be effective. Indeed, the forwarded case is
> ambiguous.
>
> A mail domain worth its salt should be able to recognize if the original
> message had been mailed out from its premises, and who is its blamed
> author or sender. Policies spell out sequent actions.

That's right. We're talking about messages with a sender address in our 
domain, that were NOT sent using our MSA. We don't permit that. We'll 
reject the message.

Actually, I think I said we won't look at the message, but that's not 
right. We check the message headers to identify messages that were 
originally routed through the MSA. For abuse reports from our domain, 
though, they're not going to go out of our system and back again.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 9 Feb 2010 09:49:47 -0800

On Feb 9, 2010, at 9:38 AM, Ian Eiloart wrote:

> 
> 
> --On 9 February 2010 17:32:42 +0100 Alessandro Vesely <[email-masked]> wrote:
> 
> That's right. We're talking about messages with a sender address in our domain, that were NOT sent using our MSA. We don't permit that. We'll reject the message.
> 
> Actually, I think I said we won't look at the message, but that's not right. We check the message headers to identify messages that were originally routed through the MSA. For abuse reports from our domain, though, they're not going to go out of our system and back again.

This is nothing to do with abuse reports, though, nor mail sent to abuse@ anywhere. It's mail to a specific special address used solely for TiS notifications.

Even in a setup such as yours with strange rules for general mail delivery, it'd be possible to special case that specific special address should you choose to do so. (In fact it would likely be in an entirely different domain, making that easy to do).

Cheers,
  Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Feb 2010 19:05:12 +0100

> If you think that any part of this chain is involving mail sent to abuse@ anywhere your model of it is a long way from how I understand the situation.

The abuse-mailbox is an attribute in some whois db (e.g. RIPE). The 
form abuse@domain is standardized by rfc 2142. Some people (e.g. 
Abusix) may plan to send machine generated complaints at such addresses.

Besides that, I don't feel my model is much different than yours.

> Rather there's one part of the chain that involves an end users MUA reporting a TiS button hit to their mail provider in a machine readable manner. That may well be done via SMTP, but if so it'll b…

I agree that's a possibility. I've proposed abuse@authserv-id, which 
may or may not be simpler. I don't think it makes a big difference.

> The other part of the chain involves feedback loops, which are sent in response to the TiS hit. Pretty much all current ones are sent via SMTP, but not typically to an abuse@ address (it's certainl…

Yes, but I've used [email-masked] for the FBL(s) I've subscribed to. 
Perhaps if I had a ponderous ARF traffic I'd be better off using a 
different address. However, that would be more of a nuisance if then 
I'd have to redirect there other ARF messages that somehow reach the 
abuse mailbox instead of my dedicated address.

> Both parts of the service involve solicited, machine readable messages sent under a contractual agreement. That's very different from an abuse@ alias, which is dominated by unsolicited messages tha…

Again, splitting the traffic may be convenient for heavy loads. 
However, I just whitelisted my abuse@ address from spam filtering. The 
moment I'll get a lot of ARF reports, it will be easy to add a 
recipient-filter that processes incoming messages only if they are in 
ARF format and leaves them in the current folder otherwise.

-- 
P.S. apologies for using the term /theory/ improperly in

  There's a whole theory of other ARF messages[...]

above. I really meant "a whole lot of other ARF messages", but my 
English didn't support me. There is no full blown theory yet, AFAIK.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 9 Feb 2010 10:15:59 -0800

On Feb 9, 2010, at 10:05 AM, Alessandro Vesely wrote:

> The abuse-mailbox is an attribute in some whois db (e.g. RIPE). The form abuse@domain is standardized by rfc 2142. Some people (e.g. Abusix) may plan to send machine generated complaints at such addresses.

None of that has anything to do with TiS buttons, though, which this thread is about. (Nor is it anything to do with feedback loops, which this thread is tangentially about).

> Besides that, I don't feel my model is much different than yours.

It is quite different (and I think wrong :)) which is why I'm stressing it.

We're not talking about abuse complaints in this thread, nor anything that would be sent to an existing role account.

That doesn't mean that a particular user might decide that sending either TiS notifications or FBL reports to a role address like sales@, postmaster@ or abuse@ is a good idea, but it's certainly not a requirement or even an expected behaviour[1].

> I agree that's a possibility. I've proposed abuse@authserv-id, which may or may not be simpler. I don't think it makes a big difference.
> 
> Yes, but I've used [email-masked] for the FBL(s) I've subscribed to. Perhaps if I had a ponderous ARF traffic I'd be better off using a different address. However, that would be more of a nuisance if then I'd have to redirect there other ARF messages that somehow reach the abuse mailbox instead of my dedicated address.
> 
> Again, splitting the traffic may be convenient for heavy loads. However, I just whitelisted my abuse@ address from spam filtering. The moment I'll get a lot of ARF reports, it will be easy to add a recipient-filter that processes incoming messages only if they are in ARF format and leaves them in the current folder otherwise.

Yup, and that all works mostly OK (though you'll find some problems if you go the recipient-filter route). It's not the way I'd advise anyone to set things up as it won't scale well, but is quite workable for a small domain.

Cheers,
  Steve

[1] Sending FBL reports to sales@ does have a certain charm, though.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 9 Feb 2010 13:29:01 -0500

> Abusix) may plan to send machine generated complaints at such addresses.

And they'll learn very very soon that that doesn't work.

Been there/done that in a limited fashion, and even in that limited 
fashion, it don't work.

Do NOT assume that TiS buttons have anything to do whatsoever with 
RFC2142, standardized role accounts, or whois "abuse-mailbox" entries.

Filter tuning doesn't, nor do FBLs (ARF'd or otherwise).  While abuse@ 
_may_ get derivations of TiS reports via ARF in some specific cases that 
are pre-arranged in advance, in no sense should we encourage such role 
accounts to be target for a raw MUA (or even MTA) stream of complaints.

> may or may not be simpler. I don't think it makes a big difference.

@authserv-id may well be a good idea, but _not_ to "abuse" or any other
pre-existing role account intended, as in the old way, for human 
consumption.

> abuse mailbox instead of my dedicated address.

It'd be more than a nuisance if the standard forces a one-size-fits-all 
targetting of all MUA-generated ARFs at abuse@everywhere.

Best to simply not go there.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Feb 2010 19:38:08 +0100

> though, they're not going to go out of our system and back again.

What about forwarding? Many sites have come to some sort of agreement 
with forwarders, e.g. in order to whitelist them from SPF checks. So 
if your user reports a forwarded message as spam, you may want to 
re-send the complaint to the forwarder, just like the Yahoo->Gmail 
case that has been exemplified earlier.

Now, suppose the report eventually reaches the original author. She 
may be the first human actually reading it, and realizes that the 
recipient hit TiS by mistake. Won't she protest? Eventually, the 
forwarder may send you back the ARF claiming that it has been your 
user's error and to please readjust their reputation.

What are the addresses involved?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Feb 2010 20:08:21 +0100

> None of that has anything to do with TiS buttons, though, which this thread is about. (Nor is it anything to do with feedback loops, which this thread is tangentially about).

Correct. They are just worth being considered when one thinks about 
where on an MTA should the ARF parsing software be installed.

> We're not talking about abuse complaints in this thread, nor anything that would be sent to an existing role account.

We are: an ARF report is an automated form of an abuse complaint.

> That doesn't mean that a particular user might decide that sending either TiS notifications or FBL reports to a role address like sales@, postmaster@ or abuse@ is a good idea, but it's certainly no…

I agree that specific agreements or standardization may let an ARF 
consumer specify a different address. Using role addresses is not 
eccentric, though.

> Yup, and that all works mostly OK (though you'll find some problems if you go the recipient-filter route). It's not the way I'd advise anyone to set things up as it won't scale well, but is quite w…

Hm... scaling can be achieved by splitting traffic. One may give 
different TiS addresses to different users, but using several or 
multihomed MXes may make for similar results.

> [1] Sending FBL reports to sales@ does have a certain charm, though.

:-)

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Feb 2010 20:20:21 +0100

> Been there/done that in a limited fashion, and even in that limited

Why not, _what_ goes wrong?

> accounts to be target for a raw MUA (or even MTA) stream of complaints.

It seems to me that a simple filter could determine ARF/non-ARF 
quality of a message in a fraction of the time that spamassassing 
would take to process it, assuming abuse@ boxes are whitelisted.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 9 Feb 2010 11:25:36 -0800

On Feb 9, 2010, at 11:20 AM, Alessandro Vesely wrote:

> It seems to me that a simple filter could determine ARF/non-ARF quality of a message in a fraction of the time that spamassassing would take to process it, assuming abuse@ boxes are whitelisted.

You (and others) are obsessing about the MIME format of inbound email, which is something of a scarlet fish.

Any real ISP is going to be getting ARF formatted reports from all over the place, most solicited, some not. So it's not really much more meaningful than the mail coming in as MIME or in German, or with an attachment.

What you need to be able to identify is who sent it to you, for what purpose, under what agreement and what you need to do with the data in it. Those are entirely orthogonal to the trivial implementation detail of the MIME structure of the email. Once you've done that, then you know what you need to do with the mail, and the details of how it's formatted become relevant.

Cheers,
  Steve

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 9 Feb 2010 17:51:40 -0500

> Why not, _what_ goes wrong?

The extant methods for determining where abuse reports are (a) usually 
wrong or missing and we're not going to bail that ocean, (b) 
insufficiently granular (both report types, but worse, breakdowns of 
space to responsible parties, ie resellers) and (c) without aggregation, 
too high volume even for automation.

[email-masked] is for reports of abuse originating _at_ 
[email-masked], not for reports of abuse (eg: spam) originating 
elsewhere that example.com's users want to report.

In other words, our TiS should _not_ go to [email-masked].  It goes 
elsewhere.  If I changed my mind for convenience, I wouldn't change the 
TiS to go to [email-masked], I'd change the mail system to alias it.

I did some experimentation with automatic aggregation and 
hand-configured destinations for a small fraction of reports.  That 
worked somewhat, but not worth the effort to keep touching the config.

> would take to process it, assuming abuse@ boxes are whitelisted.

A single bot run could fill up the abuse box so quickly that a "simple 
filter" can't do anything about it.

For the rare occasion that you want your TiS button goes to abuse@<you>,
a simple forwarding alias is far easier than the more common 
circumstance of having to construct some sort of content filter to split 
ARFs from non-ARFs.  And less likely to completely break down during a 
flood.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 10 Feb 2010 10:38:23 +0100

On 09/Feb/10 20:25, Steve Atkins wrote:
> What you need to be able to identify is who sent it to you, for what purpose, under what agreement and what you need to do with the data in it.

Correct. I just implied that the "To" header field may not be the most 
convenient data item for identifying the processing that a report 
deserves. IMHO, until we have a handful of FBLs it may be a good 
practice to cleverly partition each one using different addresses as 
labels. However, if they become several dozens, we'd probably better 
off classifying them by type rather than by agreement.

Let me try and fantasize about possible actions our handler may take, 
besides assessing filters and adjusting reputations, which are always 
possible.

Stratum 0 reports come from TiS buttons. We feed FBLs, including our 
internal FBL --i.e. check if we host the sender.

Stratum 1 reports come from subscribed FBLs. We check whether the 
original message had been sent through our MSA, in this case we apply 
relevant policies. However, we might have just forwarded the original 
message, or be anyhow involved in some trust chain. We can drop those 
reports, or we can generate stratum 2 ones.

It seems that in any case we should check whether our MSAs can be 
blamed for the original message. In case, we apply policies; that is, 
we implicitly acknowledge the report. IMHO, it may be worth to provide 
for error checking here, unless there is an overwhelming number of 
unanimous reports: if the author appeals claiming that the TiS button 
had been pushed by mistake, and her reputation is good, possibly ask 
the recipient(s) to double check it. Only when sender and recipient(s) 
(definitively) disagree, the relevant abuse teams will have to 
manually inspect the original message (and punish the guilty.)

If our MSAs are not responsible for having injected the original 
message into the mail system, we should check if we have a trust 
relationship leading to the Reported-Domain. Perhaps it is convenient 
to use the stratum data, or other agreement characteristics, as 
weights for finding a minimum spanning tree. At any rate, the problem 
of reaching a trusted domain through a trust chain can be stated 
independently of how trust relationships are established.

If the Reported-Domain is not trusted, the report should be delivered 
to the relevant connection provider, à la Abusix. It is an isolated 
MTA or a bot.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 10 Feb 2010 10:56:08 +0100

> too high volume even for automation.

You probably meant "where to send" or "where to receive", which makes 
(a) ambiguous.

For (b), the responsible party --the list controller-- is generically 
referred to as "the user". However, if they are reseller, it may be 
convenient to treat them as if they where a (trusted) domain and just 
resend ARF reports to them. We should check they apply agreed upon 
policies.

Aggregation is more subtle, unless it's done for copies of the same 
message. If reports are used for unsubscribing, a list is needed 
anyway. Would you make an attachment to the ARF report?

> elsewhere that example.com's users want to report.

Agreed. From a user's perspective, though, the abuse originates at the 
inbox example.com provides :-/

> worked somewhat, but not worth the effort to keep touching the config.

Couldn't that result from a clever algorithm and an automatically 
maintained database?

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 10 Feb 2010 12:43:06 +0000

--On 9 February 2010 09:49:47 -0800 Steve Atkins <[email-masked]> wrote:

> This is nothing to do with abuse reports, though, nor mail sent to abuse@
> anywhere. It's mail to a specific special address used solely for TiS
> notifications.

I was using the term abuse report generically, to include any email that 
might be generated as a result of a user hitting a TiJ button. I'm hoping 
it's not going to use the word "spam".

> Even in a setup such as yours with strange rules for general mail
> delivery, it'd be possible to special case that specific special address
> should you choose to do so. (In fact it would likely be in an entirely
> different domain, making that easy to do).

It's not such a strange thing to enforce use of Message Submission Agents, 
is it? What I do is roughly equivalent to insisting on DKIM or SPF for my 
domain. I'm expecting that to become widespread, and I know that I'm not 
alone among institutional mail admins.

However, I'm definitely NOT going to exempt TiJ submissions. That would be 
tantamount to an invitation to spammers to poison my spam filters. If 
anything, I'm going to be more strict about the origins of those messages, 
not less.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 10 Feb 2010 12:46:17 +0000

--On 9 February 2010 19:38:08 +0100 Alessandro Vesely <[email-masked]> 
wrote:

> with forwarders, e.g. in order to whitelist them from SPF checks. So if
> your user reports a forwarded message as spam, you may want to re-send
> the complaint to the forwarder, just like the Yahoo->Gmail case that has
> been exemplified earlier.
>
> Now, suppose the report eventually reaches the original author. She may
> be the first human actually reading it, and realizes that the recipient
> hit TiS by mistake. Won't she protest? Eventually, the forwarder may send
> you back the ARF claiming that it has been your user's error and to
> please readjust their reputation.

> What are the addresses involved?

It's like this: if you want to send mail to my system with a sender domain 
that I own, then you have to authenticate to our servers (unless you're 
forwarding an email that was originally submitted to our servers over 
authenticated SMTP).

We don't permit spoofed email from our domains. It works very nicely, and 
keeps our "internal" email pretty much spam free.