On 2/5/2010 11:10 AM, Chris Lewis wrote:
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".
+1
This greatly simplifies the model and the specification details. At that, there
is still plenty to debate. (I'm not going into the details of what I happen to
this is the 'plenty' because the higher-level concern is creating a simplified,
focused effort.)
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.
+ 0.5.
I suspect this will be much more difficult to work on, because I suspect there
is far less de facto industry consensus on the topic.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg