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.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg