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
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg