[feedback-report] Feedback types & e-mail drop boxes

[Javier Godoy]

On 2009-07-24T11:10, Steve Atkins wrote:

> Abuse desks typically don't read ARF reports at all. That's sort of
> the point, as they're intended to be machine-readable and processed
> mechanically.
>
> Unless you have an agreed relationship with the ISP you're sending
> the report to, ARF is probably not the best format to use. Instead
> send plain text, with the message inline and a brief (5 line or less)
> intro telling them what the drop box is and why.
>
> There are people who send unsolicited reports to abuse@ in ARF
> format, but those reports are not treated in any way differently to
> any other email sent to abuse at . If the ticketing system being used
> to handle abuse@ doesn't handle MIME well, then the report
> in ARF format is far less use than one sent as plain text, and may
> well be ignored. This isn't ideal, but that's just how some abuse
> desk infrastructure is built.

I do not agree. In my experience (+1500 reports sent as an end-user) abuse 
desks which ignore ARF, usually also ignores text/plain. So far, nobody 
complained about the format.

If with "doesn't handle MIME well" you mean it doesn't understand multipart, 
then it is severly flawed since end users may send the report as 
multipart/alternative with text/plain and text/html parts, or multipart/mixed 
with text/plain and the evidence attached (assuming they use a conventional 
MUA). On the other hand, if the software at the abuse desk handles multipart, 
(even though it does not reconize reports, or does not understand the ARF 
report type) it would be expected to treat some parts as attachments. In this 
case there would be a text/plain part (which introduces the report and 
instruct to see the other parts for the evidence), an unknown part (the ARF 
itself) and an "attached email" which is the evidence.

I developed a piece of software for reporting the spam I receive.

My procedure for reporting spam is:
 1. sending ARF with full evidence attached and request a delivery 
notification.
 2. if no acknologment is received, send ARF with a header only attachment 
(some ISP rejects the report because the attached evidence scores too high! I 
realized this because one of them was kind enough to reject the message in the 
SMTP conversation, instead of devnulling it). This issue usually also affects 
text/plain reports. Sometimes the problem is at the sending MTA, which if it 
implements outbound spam filters.
 3. if I am explicitly informed there was an issue with the content type, I 
will send a text/plain message. Usually I just modify the Content-Type header 
and leave the content as ARF.
 4. mantain per abuse desk statistics in order to avoid sending ARF to 
unresponsive abuse desks (I don't like to spam with spam reports!).

In most cases I have either obtained a positive response by sending ARF, or I 
haven't received any response at all.
About item 3, I first tried sending text/plain report when ARF+header seems to 
be ignored, but then I concluded this practice has little impact in the 
outcome of the reporting.


Best Regards

Javier Godoy

----------------
Universidad Nacional del Litoral
Facultad de Ingeniería y Ciencias Hídricas
Santa Fe - Argentina