Re: [Asrg] Adding a spam button to MUAs

[Alessandro Vesely <[e-mail]>]

On 02/Feb/10 19:01, Chris Lewis wrote:
> Alessandro Vesely wrote:
>> An ARF received at a domain's "abuse@" mailbox may arrive from an
>> authenticated client, and it won't be DKIM-signed in that case.
>> However, the abusive message being reported may have signatures.
>>
>> Or it may arrive from a third party. A third party presumably rewrites
>> both the boilerplate and the machine-readable parts, and I would
>> expect it DKIM-signs them. An MTA should only receive reports where
>> the Reported-Domain field indicates its own domain. Generic operators
>> may also receive reports that they are supposed to "forward"
>> --possibly rewriting and signing the first two parts in turn.
>
> I was referring on the _client_ trusting the header its front end would
> have inserted to indicate where/how to send a report. If we only add
> these headers at the receiving end, the receiving end zaps all prior
> instances of the TiS header and inserts its own, and the client knows
> that the receiving end inserts this header, then there's only the issue
> of the client roaming somewhere else and getting a forward.

The receiving end does not /have/ to zap prior instances of the same 
field. It filters off any maliciously forged Authentication-Results 
bearing its own authserv-id, but they wouldn't have provided a 
different target anyway. Users who receive considerable traffic 
through a forwarding MTA may wish to enable its authserv-id as well. 
When reporting such a message as spam, a MUA may send multiple copies. 
Semantically, that's fine. However, the last MX should avoid to route 
a second AR to the forwarder, in this case. (See picture in 
http://wiki.asrg.sp.am/wiki/Abuse_Reporting)

> Your above appears to be on the abuse@ mailbox (or whatever) deciding to
> trust the report it got from the client. That's a different affair.

In general, a (trusted) report from a client should reach the 
originating domain, whose operators can make the best use of it, 
assuming they're honest. It seems advisable that clients delegate such 
routing decisions to their servers. The servers, in turn, delegate 
that to some other trusted operator, unless they have specific 
arrangements with the reported domain. I tend to consider this 
indirection a consequence of the MSA/MX design.

>> Perhaps an MTA should verify on its own that an AR is correct. For
>> authenticated clients, it may check its receive log. For reports
>> routed by third parties, it may also verify its own signatures.
>
> That might be an option, but that ties the abuse@ rather more intimately
> and automatically to the MTAs (and their logs etc) than you'd like.
>
> I wouldn't necessarily want the MTA to handle abuse@ reports. Eg: you
> have multiple MTAs. You want a central report point, and let _it_ know
> how to propagate the choices it's going to make, and don't insist that
> it necessarily has logs (or logs timely enough) to do real-time
> verifies. Best not to design it with that much close-coupling _not_
> required.

I agree we must not specify how to do verifications. It may be a 
custom local filter, as it supposedly knows where to find the logs or 
whatever it needs. It may even be possible to filter ARF messages in 
transit through an MSA, such as at the last MX case above: the trust 
that the user has conferred can be acknowledged by filling, say, the 
Reporting-MTA field.

As for tying an MTA to abuse reports handling, I think it is the most 
convenient choice. The kind of spam that we may be able to control by 
properly routing ARs does not require the immediateness of HTTP.