[feedback-report] Feedback types & e-mail drop boxes
rjgodoy at fich.unl.edu.ar
Fri Jul 24 11:57:01 PDT 2009
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
> 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
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.
Universidad Nacional del Litoral
Facultad de Ingeniería y Ciencias Hídricas
Santa Fe - Argentina
More information about the abuse-feedback-report