Re: [Asrg] Spam button scenarios

[Steve Atkins <[e-mail]>]

On Feb 7, 2010, at 10:28 PM, John R. Levine wrote:

> 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?

> 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


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