<br><br><div class="gmail_quote">On Wed, Dec 29, 2010 at 4:31 AM, Alessandro Vesely <span dir="ltr"><<a href="mailto:vesely@tana.it">vesely@tana.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 24/Dec/10 22:44, Mark Foster wrote:<br>
> 2010/12/24 Tobias Knecht <<a href="mailto:tk@abusix.com">tk@abusix.com</a> <mailto:<a href="mailto:tk@abusix.com">tk@abusix.com</a>>><br>
<div class="im">>>  We are already working on a format, that is used by more and more<br>
>>  people. It is meant as an extension to the well known RFC 5965 ARF.<br>
>>  Called X-ARF. <a href="http://xarf.org" target="_blank">http://xarf.org</a><br>
><br>
</div><div class="im">> Anything that makes reporting abuse harder for the victim, is<br>
> counter-productive, IMHO.<br>
<br>
</div>Automation is supposed to make reporting easier for the victim, not<br>
harder.  Many webmail sites already have a "Report as Spam" button.<br>
It should be added to regular (POP3/IMAP) mail clients too.<br></blockquote><div><br>Yes, and this is a key point.<br>Standard formats for abuse reporting via email will in turn allow email client developers to embed the tech required to simplify reporting of abuse.<br>
However by making it easier, you also increase the chances that the report is inadvertant?  For example Gmail allow you to 'undo' reporting as Spam.  This would also need to be an option available to a user....<br>
<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> This to me is all an attempt to make abuse-complaint-receivers better<br>
> equipped to use automation to deal with complaints.<br>
<br>
</div>Yes, for the good and the bad of it.  Among the goodies, it should be<br>
feasible to to route spam reports so that a network provider gets a<br>
copy and forwards it to the relevant mailbox provider, thereby<br>
allowing the former to somehow control the latter.<br></blockquote><div><br>Concur, though again the use of automation means that the network provider can turn a blind eye to it and claim that appropriate action is being taken... it doesn't inspire folks to manually check to ensure action is infact being taken, that reports aren't repeat in nature, etc.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> Noone who reports abuse likes talking to automation.<br>
<br>
</div>I think you mean noone who /manually/ reports abuse, as in the OP BofA<br>
case.  If an abuse@ mailbox is equipped with software that recognizes<br>
automatic formats, human recipients might still be able to read the<br>
rest in the usual way.<br>
<br>
Whether a hand-written complaint should be sent to an abuse@ address<br>
depends on how report formats will take on.  This consideration may<br>
explain why some organizations try and push a specific format.  The<br>
abuse@ address is just mentioned by RFC 2142, but issuing a spam<br>
report does not necessarily require even SMTP, although it seems to be<br>
the most natural way of reporting email abuse.<br>
<br>
BTW, there is a third format, developed in the framework of RFC 6045.<br>
<br>
</blockquote></div><br>My main personal frustration is that as a 'power' end-user, I read email in various ways; serverside commandline mail program, webmail tool, various pop3/imap tools.  At work i'm either using the COE email application or a CRM system that manages email.  None of these will support a common, standards-driven method of generating abuse@ reports for spam, etc, for some time. In the meantime i'm constantly frustrated by the time that i'm obliged to waste either a) reporting abuse in the method that ISP X demands, or b) trashing large volumes of junk because to do anything else would taken even _ longer_.<br>
<br>I'm not averse to standard (infact i'm a big fan) but i'm also a big fan of ensuring a human remains in the loop and able to accept reports that're not within the standard format, at least until it's reasonable to expect _everyone_ to be using the standard format (which could take years)...<br>
<br>Mark.<br>