Re: [Asrg] Spam button scenarios

[Ian Eiloart <[e-mail]>]

--On 8 February 2010 15:05:13 +0000 John Levine <[e-mail]> 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.
>>>>
>>>
>>> The user trusts his good outgoing mail to that MTA - why should she not
>>> 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.
>
> 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.

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
> whether it's a problem that the spam report takes a detour through someone
> else's mail system on its way.

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.





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