Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely wrote:
> On 02/Feb/10 05:44, Chris Lewis wrote:
> > As long as the client "knows" whether its front ends support this
> > functionality (might be config value of administrative domain), and
> > ignores them if it isn't, the security issues are fairly limited.
> >
> > Still need DKIM?
> 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.
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.
> > If the sender is "permitted" to insert them, for them to mean much, you
> > get into the same issues as end-to-end DKIM on email has. You know that
> > the signature verifies or not, but you still don't know whether you want
> > to trust the information.
> 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.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg