Subject: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 24 Jul 2011 15:53:21 -0700

<co-chair>
Barry and I received the following feedback about the ARF base document from someone who does not wish to join the mailing list and does not wish to participate in the working group directly.  We've agreed to forward these comments to the working group for its consideration, but also agree that one person's concerns (especially when that person doesn't want to do the work of advancing them through the working group) are not sufficient to spin up an update effort.

So, if the working group wants to do something with some or all of this material, great, we can talk about starting that effort.  If not, then that's fine too.

Some of this stuff also applies to a couple of our open documents, so the various authors (JD mostly, I think) could consider them there.
</co-chair>

<participant>
As far as the base stuff goes, some of this stuff looks reasonable, but none of it looks critical to me.   Thus, if there's no critical mass to create an RFC5965bis effort, they could just be logged as errata or something like that so they fall in the "deal with this someday" bucket.
</participant>

<feedback>
I am just working through the most recent version to update our filters to 
use the latest proposal, and am in the process of also converting our virus 
reporting to the ARF. In that process I found a number of concerns with ARF 
and aborted that conversion:

1) I consider it extremely rude and dangerous to transmit malware across the 
Internet even in the form of an ARF, apart from the fact that virus filters 
at the ISP level and/or the recipient's level may well catch the malware, 
create a report of that malware (thus creating a loop), and at the same time 
firewall the offending IP (our mail server). Hence the proposal to return the 
complete message in case of reporting a virus is a very bad idea. Instead, 
only the header of the offending message should be returned.

The proposal should therefore prohibit the return of the full message in case 
of feedback type virus and instead require the return of the mail header 
only.

This also requires to change the content type of the last ARF section from 
message/RFC822 to text/RFC822-Headers (or whatever else is deemed suitable).

2) Because with just returning the header the recipient is no longer able to 
determine which malware was being sent, an according reporting field is 
needed in the ARF. I'd propose to use:

Reported-Description: 

or

Reported-Malware: 

the first of which can be used not only for virus reporting, but should be 
required for feedback type virus and should contain the full name of the 
virus as reported by the virus scanner.

3) Because the virus names vary from each virus scanner tool, we also need to 
identify the virus scanner reporting the malware. The name of the virus 
scanner should therefore be included as:

Reporting-Utility: 

Required for feedback type virus, optional for other feedback types.

4) The Source IP address should be mandatory for feedback type virus.

5) I'd phase out the feedback type virus in favour of feedback type malware 
(which is the same, just broadening the use to include worms, downloaders, 
.. which are not virus type), alternatively introduce malware as equivalent 
to virus (keeping both feedback types permanently alive). I feed virus would 
be too limiting for that type of reporting (virus by definition is self re-
producing, while worms, downloaders etc. are not self re-producing and 
therefore by definition are not virusses).

That concludes my virus/malware-related comment to your excellent tool.

A suggestion may be whether the keyword virus should not be phased out in 
favour of the word malware to open the abuse report for more generic purpose 
(although virus generally is now being understood like malware anyway).

Another comment regarding the _report.domain DNS TXT entry ...

In principle that seems to be a reasonable idea, however, there's a duplicate 
created that way. Right now abuse addresses are mandatory for the IP address 
entries in ARIN, RIPE, ... The problem there, the databases are not really 
consistent, but consistent enough that parsing of the entries for abuse 
addresses is possible indeed.  

I'd rather leave the (legally binding, because that is part of the contract 
between ARIN/RIPE/... for IP address assignment) abuse reporting facility 
with the IP assigning entities and create a standard there in either their  
databases (whois) or via a global abuse address server under control of one 
entity (ARIN or whoever, supplied and updated only by ARIN and IP assigning 
authorities delegated by ARIN) with the entry of the source IP address and 
return of the abuse mail address (could be name server, http, whois, ...)

There is actually a huge problem with the _report.domain ... The name server 
may not be under control of the ISP, subdomains may well be added by the 
client. Hence a malicious client could redirect the abuse reporting to his 
own mail address that way and as such completely disable abuse reporting.

Hence I consider the proposal for _report.domain TXT field to publish the 
abuse mail address as serious risk and detrimental to the purpose of ARF.

I'd therefore recommend to drop that proposal in favour of what I lined out 
above, most likely and easiest by creating consistency across the whois 
databases (introduce a specific abuse report field there, which is currently 
missing and abuse e-mail addresses are only published in the comment 
fields!).

To give you an idea: our spam- and virus reporting utilities fetch the abuse 
address of the ISP via whois indeed and do all the necessary parsing of the 
whois entries via the source IP address.
</feedback>

---

From: Tony Hansen <[email-masked]>
Date: Sun, 24 Jul 2011 23:20:20 -0400

I definitely understand the concerns of passing around the malware via 
email. If we feel that they *must* be sent, we *could* encrypt the 
attachment (pick your poison, such as AES), and include the password in 
another header.

Just thinking out loud,

     Tony Hansen

On 7/24/2011 6:53 PM, Murray S. Kucherawy wrote:
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 24 Jul 2011 20:28:10 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Hansen
> Sent: Sunday, July 24, 2011 8:20 PM
> To: Message Abuse Report Format working group
> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report
> subdomain
> 

<participant>
I'm less concerned about it.  An FBL is typically addressed to a person or a piece of software specifically equipped to handle abusive email, usually by prior arrangement.  It's not like the FBL mail containing a piece of malware is being sent scattershot at people that aren't prepared to receive it.
</participant>

---

From: "John Levine" <[email-masked]>
Date: 25 Jul 2011 04:10:32 -0000

>I'm less concerned about it.  An FBL is typically addressed to a
>person or a piece of software specifically equipped to handle abusive
>email, usually by prior arrangement.

That's pretty much what I was going to say.  If you're not prepared for
people to send back whatever crud you send out, you have a pretty poor
excuse for a feedback loop.

Also, I can tell you from experience that I've been sending lightly
denatured virus reports (the first few bytes of the base64 changed to
xxx so it's not executable), and I've never gotten into a loop or
anything else particularly bad.  The worst that happened was that a
rather dim BL operator insisted that I was sending viruses because
their virus detectors said so.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Sun, 24 Jul 2011 21:28:00 -0700

> I'm less concerned about it.  An FBL is typically addressed to a person or a piece of software specifically equipped to handle abusive email, usually by prior arrangement.  It's not like the FBL ma…

From experience, many FBL handlers are behind the primary corporate MX. Often configured to avoid filters. Sometimes not. Sometimes configured to do so until the MX (which is not under control of the people operating the FBL eater) is upgraded or outsourced.

If FBL messages contain hostile content they're fairly likely to be silently dropped or quarantined at a small fraction of recipients today. That fraction would probably increase if more organizations than the current selection (ESPs and some ISPs) start to take advantage of them - which is something I'd really like to happen in the case of FBLs based on detection of malware emission.

Cheers,
  Steve

---

From: "Alex Bobotek" <[email-masked]>
Date: Sun, 24 Jul 2011 23:13:47 -0700

The use of in-band reporting mechanisms (e.g., message/rfc822 atop an
SMTP relay chain), for all their benefits, have some complications.  The
complexity may increase with gateways and longer SMTP relay chains.  

MTAs (and gateways) might need to allow uninhibited passage of malign
embedded spam or virus reports (e.g., based on MIME type, destination
address, or some other mechanism).  

MUAs might need to recognize that a message/rfc822 embedded inside a
feedback report may be unsafe for execution/storage.  

Tony's suggested method, encryption with a declared key, strikes me as a
better mechanism than simply requiring special handling of designated
MIME types.  An ignorant MUA would be unable to execute malware, and an
ignorant MTA would pass reported messages freely.  

IMHO we should shoot for a more extensible/future-proof reporting
mechanism; one that would be more likely to work beyond an ISP1-->ISP2
over SMTP reporting scenario.  The trend is towards more gateways and
increasing delivery path complexity in general.

Regards,

Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Steve Atkins
Sent: Sunday, July 24, 2011 9:28 PM
To: Message Abuse Report Format working group
Subject: Re: [marf] FW: Feedback on: ARF feedback typeVirus/_report
subdomain

person or a piece of software specifically equipped to handle abusive
email, usually by prior arrangement.  It's not like the FBL mail
containing a piece of malware is being sent scattershot at people that
aren't prepared to receive it.

>From experience, many FBL handlers are behind the primary corporate MX.
Often configured to avoid filters. Sometimes not. Sometimes configured
to do so until the MX (which is not under control of the people
operating the FBL eater) is upgraded or outsourced.

If FBL messages contain hostile content they're fairly likely to be
silently dropped or quarantined at a small fraction of recipients today.
That fraction would probably increase if more organizations than the
current selection (ESPs and some ISPs) start to take advantage of them -
which is something I'd really like to happen in the case of FBLs based
on detection of malware emission.

Cheers,
  Steve

---

From: Jacqui Caren-home <[email-masked]>
Date: Mon, 25 Jul 2011 07:25:21 +0100

> virus as reported by the virus scanner.

IMHO This is too simplistic...

The above makes sense for vendor names such as Foobarv1.2

but I would add an optional

Reported-CVE-Id: 2010 0042

with the CVE numbers for any known infections seperated by comma's.

This should be in format as used by http://cve.mitre.org/

Jacqui

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Jul 2011 03:01:39 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain
> 
> silently dropped or quarantined at a small fraction of recipients
> today. That fraction would probably increase if more organizations than
> the current selection (ESPs and some ISPs) start to take advantage of
> them - which is something I'd really like to happen in the case of FBLs
> based on detection of malware emission.

Does that mean you feel this justifies a change to the base draft?

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Jul 2011 08:18:29 -0700

> Does that mean you feel this justifies a change to the base draft?

I don't think so, no, definitely not if doing so would increase implementation
complexity further. 

But it's something to be aware of if ARF is pushed
beyond it's original scope of reporting "My user thinks this is spam" to
things it's less well suited for (where the obvious payload of the report is
not really a message/rfc822 attachment).

Cheers,
  Steve

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 25 Jul 2011 08:43:43 -0400

In
<[email-masked]>,
on 07/24/2011
   at 03:53 PM, "Murray S. Kucherawy" <[email-masked]> said:

>1) I consider it extremely rude and dangerous to transmit malware
>across the Internet even in the form of an ARF,

I consider it extremely rude to send an abuse report without
supporting documentation. I wouldn't expect an ISP to act on a virus
complaint that didn't document the alleged virus.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Jul 2011 16:26:22 -0700

> ignorant MTA would pass reported messages freely.  

Yup. Something with the power and flexibility of ROT13 might suit
that well.

> increasing delivery path complexity in general.

That's not really what ARF is, though. ARF has had significant uptake
mostly because it's very simple, and very well suited to it's original
role.

I'm not sure whether it'll maintain a useful level of uptake if it's
made more complex to use, and aimed at roles it's not well
suited to. So I'm not sure whether it's the right place to start when
crafting something intended to report all sorts of unrelated things
via a variety of channels.

( http://xkcd.com/927/ is probably relevant here).

Cheers,
  Steve

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 26 Jul 2011 08:03:50 -0700

> only the header of the offending message should be returned.

There's some validity to these arguments, but what they're convincing me of is that the "virus" type should be removed entirely.  It's never really been tested at scale, and we didn't have much input from the malware reporting/research community.

Is anyone aware of any implementations that do anything special with Feedback-Type: virus?

Is anyone aware of serious malware reporting/research institutions using ARF?

> addresses is possible indeed.

We talked about this earlier.  The published abuse@ address is intended for communication from humans; it would be rude to assume abuse@ is set up for ARF.  By publishing a separate record, the domain owner is saying "I know about ARF, and I process ARF at this address."

It's a shame that this person is not willing to participate in the conversation.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jul 2011 20:48:26 +0200

> only the header of the offending message should be returned.

This is already provided for, albeit not recommended.

> of feedback type virus and instead require the return of the mail header 

Err... wouldn't it be safer to prohibit people from sending viruses in
the first place?

> virus as reported by the virus scanner.

Sounds good.  "Reported-Malware" better conveys that the "virus"
Feedback-Type is somewhat of a misnomer (see below).

> Required for feedback type virus, optional for other feedback types.

"Scanner" may better distinguish it from "User-Agent".  Is it useful?
 (It can often be inferred from the virus names it reports.)  I'd
recommend it be fully optional, anyway, especially its update version :-/

> therefore by definition are not virusses).

Sticking to established albeit wrong names seems to be more orthodox
than correcting them (remember the "Referer".)  For a partial
justification, let me note that worms and other malware are often
detected by products commonly called "anti-virus".

> addresses is possible indeed.  

ARIN's announcement was posted on Mon, 18 July 2011
https://www.arin.net/announcements/2011/20110718.html

RIPE hasn't yet said so, AFAIK.

I don't know whether they will recommend ARF, but the fact that they
strive to avoid rate-limit for that data suggests that they intend it
to be for automated use, the same as _report.domain.  So, yes, there
seems to be some overlapping here.

> own mail address that way and as such completely disable abuse reporting.

Good point.  Ideally, ISPs could set abuse@ISP in the RIR's DB, and
then count and redirect complaints to the relevant postmasters.  It
would be great if they also checked that complaints are actually acted
upon.  More likely, ISPs will just set POCs as clients tell them to,
including /dev/null.  Reporters can also compare WHOIS data with
_report.domain, and send to whomever they like.

IMHO, our docs should

* mention RIRs and registrars WHOIS databases,
* cover comparison considerations, and
* insist that end users should report to their postmasters if at all
  possible.

jm2c