Subject: Re: [marf] MUA plugins, was feedback type Virus

From: "J.D. Falk" <[email-masked]>
Date: Mon, 1 Aug 2011 19:42:41 -0700

On Jul 30, 2011, at 1:08 AM, Alessandro Vesely wrote:

> On 29/Jul/11 22:23, J.D. Falk wrote:
>> Using ARF for reports from MUAs has been discussed many times, but
>> hasn't really ever been implemented (except for a Thunderbird
>> plugin, years ago, now lost to history.)  I'd love to see somebody
>> try it, but until they do I don't think we can call it a common
>> practice.
> 
> Where is it?  I've been looking for one since we discussed this
> question in ASRG[*], and eventually started to roll my own stuff.
> However, I never completed, nor released, my plugin.  Previous
> experience may probably help me... any pointer?

Lost to history, as far as I know.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 3 Aug 2011 06:35:01 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Friday, July 29, 2011 10:34 AM
> To: [email-masked]
> Subject: [marf] Automated vs. manual reporting, was feedback type Virus
> 
> > Hence, to word a request to the MARF group: design the MARF drafts
> > not only with manual, but also with automated responders in mind. I
> > am convinced, that automated responders will create most of the
> > feedback messages in not too distant future.
> 
> +1, possibly we should add a field such as Report-Trigger: human/auto.

How would that alter one's handling of such a report on receipt?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 18 Aug 2011 14:44:55 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Friday, July 29, 2011 1:23 PM
> To: Message Abuse Report Format working group
> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report
> subdomain
> 
> hasn't really ever been implemented (except for a Thunderbird plugin,
> years ago, now lost to history.)  I'd love to see somebody try it, but
> until they do I don't think we can call it a common practice.

However, "Report Spam" buttons, including ours, do send proprietary feedback of some kind in a lot of instances.  Having an ARF implementation would be great.

Maybe we should chase down that Thunderbird plugin...  :-)

> MARF is already widely accepted.  There are dozens of report generators
> and literally thousands of report consumers, nearly all following the
> use case described in draft-jdfalk-marf-as.  That's part of why there's
> disagreement -- we don't want to change MARF in ways which would be
> incompatible with the established userbase.

There are some people in MAAWG from the AV vendors.  I wonder if they'd be interested in FBLs that use ARF for the purpose of reporting suspected virus payloads.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 18 Aug 2011 15:47:35 -0700

Apologies for not replying to this sooner.  The Quebec City IETF conference was quite busy, and I'm only now de-queuing various pending MARF work.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of zav961
> Sent: Thursday, July 28, 2011 5:15 PM
> To: [email-masked]
> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain
> 
> Of course, MARF also has its use in Outlook or similiar Mail Software
> where a user can push a button to mark a mail spam, or not spam, and
> the sending ISP (and/or filter provider) automatically gets informed
> upon that user intervention. A fully manual MARF report would seem over
> the top however.

I don't think anyone envisioned construction of ARFs by hand, the same as one would never imagine generating an MDN or DSN by hand.  But getting support for it in more MUAs would be very desirable.  I imagine it's a lot like any new mail protocol though: Producers are waiting for consumers, and vice-versa.

To the general question of sending malware payloads in ARF reports, perhaps this is something JD could add to the reporting discovery draft, i.e., whether or not an FBL consumer expresses willingness to accept malware payloads.

> Well, if that claim of no-one ever reporting malware automatically ever
> existed, our implementation is the living example to the contrary.

Naturally any such claim is based on one's own knowledge.  It just means we've never heard of one, which in turn means we have no experience with them.

> > If people concur that this is an issue, I would suggest
> > updating the base document to provide a requirement that a
> > virus report include the name of the reporting software and
> > the virus name it used, and restrict the third MIME part to
> > be text/rfc822-headers.
> 
> I obviously support that motion!

I would suggest then that you or someone interested in seeing that change made take some time to produce an individual submission draft and then submit it to the working group for consideration.  I'm happy to provide guidance on how to do that if needed.

> When I mentioned advertising the IP address of the potential MARF
> report transmitter similiar to SPF, I overlooked an important security
> question (that's always the danger of a single brain thinking). SPF and
> MARF have a decisive difference in the use for the bad boys. SPF is
> hardly exploitable even if it gets under full control of a malicious
> user. However, MARF could become a dangerous tool in the hands of a
> malicious user misleading ISPs/regulating bodies or launching DoS
> attacks against abuse departments. Which leads me to think on a second
> thought that the MARF senders should be identified through ARIN and
> their delegated authorities, too, just like the abuse mail addresses.
> That approach immediately puts the out of band topic to rest, too.

There's a separate document in the working group (which I think you've seen) discussing a method to advertise the preferred destination for feedback reports.  I think, for both political and technical reasons, that venue is a lot more likely to be successful than an attempt to change what's available through WHOIS.

We already do say (or at least, I'm pretty sure we do) that ARF reports shouldn't be accepted or trusted other than by prior arrangement, specifically to reduce the threat of injection of false reports.  Some of that includes suggestions like ensuring reports are signed somehow so that their authenticity can be verified.  I'm sure some implementations also check SPF.

> A) feedback-type: virus
> 
> I propose to change the keyword virus to malware.

A straight rename is probably a problem in case it's already in widespread use.  You might get away with defining "malware" and deprecating "virus", although I have some doubts about that too.

> In the report section following fields become mandatory:
> [...]

I suggest putting this stuff in a draft and bringing it to the working group.

> B) MARF Discovery (_report subdomain)
> 
> B.1 Rethink the whole draft in view of automated responders, malicious
> abuse and ongoing ARIN database extensions, I'd think the current
> proposal could be dropped
> 
> B.2 Require ARIN/delegated authorities published abuse addresses to
> unconditionally accept MARF reports (they automatically do as it stands
> due to the humanly readable first part and third part containing the
> relevant evidence)
> 
> B.3 Introduce a MARF sender identification (via IP address(es)) with
> ARIN/IP assignment authorities similiar to abuse address registration
> 
> B.4. As long as ARIN/IP assignment authorities are not featuring such
> MARF database entries import the SPF RFC replacing selector SPF with
> MARF for identifying authorised MARF transmitters.

As I'm learning now with the fledgling WEIRDS effort, the IETF has no purview to cause ARIN or any RIR to do anything in terms of what data they require from registrants or make available via WHOIS.  That's something you'd have to pursue with ICANN, as it's entirely a matter of policy and not one of technology.  (I'm not sure how that logic jives with RFC2142, however.)

If this is important to your vision, I suspect dropping the reporting-discovery document is in fact the wrong thing to do, and instead we should work at updating it to match your needs in a way that achieves consensus.

-MSK

---

From: SM <[email-masked]>
Date: Thu, 18 Aug 2011 20:08:48 -0700

> > due to the humanly readable first part and third part containing the

If a sender fills your queue with a misdirected ARF report every 
second, would you unconditionally accept it or take other action?

>As I'm learning now with the fledgling WEIRDS effort, the IETF has 
>no purview to cause ARIN or any RIR to do anything in terms of what 
>data they require from registrants or make available via 
>WHOIS.  That's something you'd have to pursue with ICANN, as it's 
>entirely a matter of policy and not one of technology.  (I'm not 
>sure how that logic jives with RFC2142, however.)

For the IP address angle, use existing RIR processes to get what you 
want.  I doubt that ICANN can do much in that area.  It's better to 
avoid the RFC 2142 logic as it leads to unproductive discussions.

Regards,
-sm

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Fri, 19 Aug 2011 07:57:50 -0400

In
<[email-masked]>,
on 08/18/2011
   at 03:47 PM, "Murray S. Kucherawy" <[email-masked]> said:

>To the general question of sending malware payloads in ARF reports,
>perhaps this is something JD could add to the reporting discovery
>draft, i.e., whether or not an FBL consumer expresses willingness to
>accept malware payloads.

How about a separate flag as to whether the consumer wants full text,
only header or full text except for malware?

-- 
     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)