Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely wrote:
> On 02/Feb/10 19:01, Chris Lewis wrote:
> > 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.
No, it doesn't technically have to, but it _will_ have to give the 
client a hand in making sure the client doesn't trust bogus/malicious 
ones or ones outside of the receiving site's policies.
Removing the ones it doesn't want the client to respect and/or rewriting 
the ones it does want the client to respect, or simply replacing them 
all with its own is the best way of doing that.
> It filters off any maliciously forged Authentication-Results 
> bearing its own authserv-id, but they wouldn't have provided a 
> different target anyway.
Why not?  Why wouldn't a scammer attempt to divert the recipient's TiS 
buttons to /dev/null, DDOS someone else, or divert complaints away from 
their provider who might zap them?
> 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.
And assuming that meets the recipient server's policies.  As a 
corporate, for example, we must have the final word on what reporting 
our users do and to where.  That will often _not_ be where the sender or 
forwarder is trying to tell the client.
For simplicity, you may well want to have the core specification require 
that the receiving MTA makes all the choices at transit time, and 
removes all forwarding instructions that it doesn't agree with.
That means that the client, assuming that the client knows that the 
receiver is doing all the work, doesn't have to do any cryptographic 
verification, and the receiver may not need to either.
> 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.
The indirection may well be desirable, but you have to ensure that it is 
convenient to do so (in other words, make sure that the client's 
provider's AR handling _know_ what routing decisions they're being asked 
to assess and implement).
> 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.
The MTA is only essential to abuse report handling insofar as the abuse 
reports may adjust the filters.  It'll be convenient to do the AR 
handling on the MTA in some instances, but in many it will be not a good 
choice.  An specificiationd esign that makes AR handling independent of 
the MTA is a better one.  You can run it co-resident if you wish.  But 
you don't have to.  Making the spec require too much of the MTA function 
would be a mistake in that regard.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg