We've more-or-less reset the discussion to emailing ARF reports (most
people are satisfied with emailed ARF reports without other options)..
I think we need to reset it again, yet further. The reason being that
the discussion touches too many pieces at once, and the
security/practicality issues of remotely-specified ARF destinations are
obscuring the fact that why bother with specifying them at all? Let the
user's ARF handling service do it. We need to very specifically
disentangle MUA/MTA functions and simplify yet again.
So we get rid of inband abuse report instructions altogether.
I propose two specifications:
1) a spec for MUAs that says nothing more than "if the TiS button is
pushed, the selected email[s] get sent in ARF format to <some standard
address>, via the usual mail submission methods it uses". I recommend,
so as to not stomp/overload existing naming conventions, that it be
"arf(_at_)arf(_dot_)<domain in the RCPT TO that reached the user>". Or, "ar", or
whatever. I don't care what it is (if you really don't want to use
"arf") as long as it doesn't collide with existing conventions and
standards. Eg: IMAP/POP/SMTP/SPAM et. al. are unacceptable.
This also allows <domain> to use DNS to map them to somewhere else entirely.
Then,
2) a followon spec that specifies what goes on at arf(_at_)arf(_dot_)<domain>" in
terms of remote report forwarding (if any). Rather than relying on
inband ARF destination signalling, I think we should consider doing
something with DNS ala SPF/SenderID and DKIM.
Astute readers will notice that (1) is a trivially simple MUA hack, and
that (2) isn't necessary for many installations wanting TiS info (for
filter tuning) and don't forward them anywhere.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg