Re: [Asrg] Adding a spam button to MUAs

[Alessandro Vesely <[e-mail]>]

On 04/Feb/10 22:46, Chris Lewis wrote:
> I'm envisaging a situation where the email as received by the UA has one
> or more sets of instructions of how to send a TiS report, and where.
> _Most_ of the time it _may_ be the MUA communicating back to its MTA
> (perhaps by IMAP). The MTA can simply insert those as per site policy.
> But the MTA may choose to allow upstream instructions through as well
> (if it chooses to trust them).

Isn't that unnecessarily complicated?

>>> 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?
>>
>> That's not possible: the authserv-id is just a naked token.
>
> It can if the instructions contain where and how to report.

That's one complication resulting from having instructions.

> I'm specifically referring to the MTA indicating _which_ TiS
> "instructions" the MUA is permitted to follow (perhaps simply by
> removing whatever instructions it elects not to permit). Not necessarily
> that the MTA send the ARF reports. In fact (as below), it wouldn't be
> the MTAs that send an ARF report in my infrastructure.

Ok, it doesn't have to be the MTA proper. It can be done by any 
machine on the server side. However, if clients dumbly send ARs to the 
authserv-id, some handler on the server side has to take care of 
routing them appropriately.

>> The client can rely on the fact that all messages in a given mailbox
>> have been received by the relevant server. However, a server doesn't
>> know that an ARF contains a message that it had previously delivered
>> to the reporter. This is different from webmail.
>
> Doesn't necessarily need to, especially if it's told/allowed the MUA to
> send the report directly.

It becomes intricate to first filter incoming messages in order to zap 
any ARF destination which is rejected by policy, and then filter 
outgoing reports to check that the MUA accomplished. It seems more 
straightforward to just do what is appropriate.

> This has nothing to do with transports, but everything to do with
> destinations.

It shouldn't be difficult, on the server side, to redirect traffic 
destined to abuse@ to the most convenient machine for processing it.

If I got your point correctly, you don't want that machine to 
necessarily host an SMTP server. I agree. A message can be transferred 
to its destination by any means. However, it may be convenient to make 
some discrimination earlier. E.g. whether a message is from an 
authenticated user reporting abuse, rather than from a third party 
routing reports to the Reported-Domain. In addition, the result of 
processing may involve sending an ARF message out. In some cases, 
however, reporting is only accepted via HTTP (e.g. 
http://www.dnswl.org/abuse/)

> The filters could have rules on how to add/adjust inbound abuse
> reporting instructions. I'd like nothing more than to accept/implement
> "forward to X" instructions from sites I trust. Whether the MUA or the
> control server actually executes the instructions I don't care that much.

The "forward to X" instructions might consist of 
Authentication-Results and VBR-Info fields. The handler should check 
that the MUA hasn't already included any of them, to avoid duplication.

"Trust" in this case would really mean "know", just to avoid noise and 
bounces. ARs about messages with no valid authentication don't deserve 
being forwarded, except possibly to the connection provider. INCH may 
be a better notification protocol, in case the handler can determine 
that a botnet is involved.