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

From: Simon Hradecky <[email-masked]>
Date: Thu, 28 Jul 2011 11:18:25 -0700 (PDT)

I am the author of the message forwarded regarding the virus feedback type and the _report subdomain. I decided to now join the mailing list and comment on a couple of points raised. This mail may not get properly threaded though for the lack of in-reply-to and reference fields that I can't insert into the mailer.

ad Point evidence
-----------------

I see the name of the virus together with the name of the virus scanner producing the identification as equivalent to the actual byte stream, I actually compare it to a compression utility in that sense, just that there's a lot better compression factor.

If we start to discuss, whether that combination of virus name and virus scanner is really sufficient as evidence, then we will also need to raise the question, whether the full message is any evidence at all. The message could be tampered with (could be modified), the message could never ever have been sent, ... The MARF could actually be sent by a bad guy trying to lure the ISP's abuse department into taking action against an innocent customer! With that in mind, it does make perfect sense to publish the IP address of permitted MARF senders for a particular domain, similiar to SPF.

ad point prevent sending malware in first place
-----------------------------------------------

Of course, that would be the ideal case. However, as always with regulations and law, there are always people not adhering and sending such stuff nonetheless.

Now, in order to enforce a regulation is it possible to violate the regulation? Certainly not. So, as we agree that malware should not be transmitted over the Internet (and Netiquette as well as RFCs actually require to not send such abuse), why would we then ENFORCE sending such malware in abuse reports? We agree, malware should not be sent, hence the abuse reporting mechanism should provide for that. That's the generic idea behind my proposal.

ad ARIN database:
-----------------

thanks, Alessandro, I am delighted about that announcement.

ad input from malware folks, drop malware reporting altogether:
---------------------------------------------------------------

I suspect that just like me those good folks didn't see a lot of need so far, more or less free format mails were generated so far. However, a number of ISPs have started to require ARF format for all mail arriving at their abuse department, so malware reporting has started to become an issue and feedback will probably start to flow in.

MARF represents mail abuse reporting format, not just spam reporting format, hence it should be able to cater for proper malware reporting, too. By dropping, or not supporting a proper malware reporting, MARF could actually contribute to malware authors escaping any form of control/abuse handling.

ad "Reported-CVE-Id":
---------------------

Full support on my side, I actually forgot about that. I'd treat this as an optional field for those virus scanners, the database of which permit to identify attached CVE IDs. The scanners I am aware of currently do not cater for that facility.

ad encryption of malware:
-------------------------

Bandwidth is an issue despite encryption, as I said above, identifying the virus can be seen as a very effective compression, and at the same time removes the requirement of sending malware across the internet (to a possibly unexpecting receiver).

The malware may well be in the order of several 100K, maybe even MBs of attachment, while the virusname is a matter of possibly 128, maybe 512 bytes. Is that line as well as mailbox congestion really worth sending an attachment, that is fully identified by the virusname anyway so that the recipient could go in his database, fetch a sample of that thing and knows the identified malware exactly byte by byte?

Who does need and can take use of the actual malware body? Those who write virus scanners, obviously, they however had according (expecting) reporting channels already via their websites.

What would the ISP do with the binary file he gets sent? The human eye wouldn't see anything, he might run his own virus scanner over it to get the same result the sender already had, and all we achieve is using up bandwidth on Internet and CPU power. And I'd need to again raise the question whether that attachment has any value as evidence whatsoever.

If we don't trust that the MARF report contains accurate data, why would we assume the contained message is accurate? It could as well be just produced from any place without any actual mail having been received.

If the receiver of the MARF report doubts the identification, he'd certainly inquire with the sender and they both will agree how to produce something that both accept as reliable evidence.

ad FBL:
-------

The MARF contains a clear free text section, feedback section and evidence section for good reason. The MARF can that way be processed by either any human monitoring an abuse mailbox, an automatic handling tool and/or both. So, why then restrict the use of MARF to only those who actually expect a MARF? Would the abuse department not requiring nor being prepared for MARF not be interested in seeing the spam mail, or know about what malware was sent from where? So, whether or not it is MARF, the abuse report does need to contain such stuff. So, why not send MARF (and "promote" it that way) on ANY abuse report if the complainer's reporting utility is capable of MARF?

However, then MARF must not assume that the recipient is expecting and capable of handling such unsafe content, which again is another argument of shaping the evidence section according to need.

Sorry again for the long sermon, and sorry for most likely breaking the threading of this discussion.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jul 2011 12:06:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Hradecky
> Sent: Thursday, July 28, 2011 11:18 AM
> To: [email-masked]
> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain
> 
> If we start to discuss, whether that combination of virus name and
> virus scanner is really sufficient as evidence, then we will also need
> to raise the question, whether the full message is any evidence at all.
> The message could be tampered with (could be modified), the message
> could never ever have been sent, ... The MARF could actually be sent by
> a bad guy trying to lure the ISP's abuse department into taking action
> against an innocent customer! With that in mind, it does make perfect
> sense to publish the IP address of permitted MARF senders for a
> particular domain, similiar to SPF.

My understanding is that the general practice of an FBL is that they are not typically established in an automated fashion.  That may change a little as we do the reporting discovery work, but at the moment I don't think there are any parties that just start sending or accepting FBLs and assuming they're all valid.  Thus, there's already an out-of-band component to establishing an FBL, and it makes sense to prearrange a list of authorized IP addresses in that process rather than in the base protocol.

That said, we could entertain the idea of supporting this in the reporting discovery work.  I suggest you write actual text you'd like to see added to that document to support this idea, and then we can debate it.

> Now, in order to enforce a regulation is it possible to violate the
> regulation? Certainly not. So, as we agree that malware should not be
> transmitted over the Internet (and Netiquette as well as RFCs actually
> require to not send such abuse), why would we then ENFORCE sending such
> malware in abuse reports? We agree, malware should not be sent, hence
> the abuse reporting mechanism should provide for that. That's the
> generic idea behind my proposal.

You cited RFC3834 in previous email as your basis for the "RFCs" claim above.  I disagree that it applies to FBLs, which are typically activated by humans and not by software to report spam, and thus aren't automated messages.

I believe someone (you or someone else) claimed that nobody has implemented an FBL that reports viruses so far.  If that's the case, we could consider updating the registry to mark it as historic.  Those are the places where RFC3834 might apply.

But later you say virus FBLs are likely, so then the above text doesn't apply.

> I suspect that just like me those good folks didn't see a lot of need
> so far, more or less free format mails were generated so far. However,
> a number of ISPs have started to require ARF format for all mail
> arriving at their abuse department, so malware reporting has started to
> become an issue and feedback will probably start to flow in.
> 
> MARF represents mail abuse reporting format, not just spam reporting
> format, hence it should be able to cater for proper malware reporting,
> too. By dropping, or not supporting a proper malware reporting, MARF
> could actually contribute to malware authors escaping any form of
> control/abuse handling.

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.

> ad "Reported-CVE-Id":
> ---------------------
> 
> Full support on my side, I actually forgot about that. I'd treat this
> as an optional field for those virus scanners, the database of which
> permit to identify attached CVE IDs. The scanners I am aware of
> currently do not cater for that facility.

Can you (or someone) propose specific new text to the base document we should be considering?

> Bandwidth is an issue despite encryption, as I said above, identifying
> the virus can be seen as a very effective compression, and at the same
> time removes the requirement of sending malware across the internet (to
> a possibly unexpecting receiver).

There may be FBLs (such as one run by a malware analysis company) that want to get every variant of a virus.  Reporting only the virus name and detection software would mean the details of a variant are lost.  I don't know if this is an issue or not.

> Who does need and can take use of the actual malware body? Those who
> write virus scanners, obviously, they however had according (expecting)
> reporting channels already via their websites.

They might wish to switch to FBLs as a standard way of doing this.  Perhaps we should ask them.

> If we don't trust that the MARF report contains accurate data, why
> would we assume the contained message is accurate? It could as well be
> just produced from any place without any actual mail having been
> received.

This, I believe, is a restatement of the out-of-band issue; we know (or at least assume) that reports from random sources can't be trusted.

> ad FBL:
> -------
> 
> The MARF contains a clear free text section, feedback section and
> evidence section for good reason. The MARF can that way be processed by
> either any human monitoring an abuse mailbox, an automatic handling
> tool and/or both. So, why then restrict the use of MARF to only those
> who actually expect a MARF? Would the abuse department not requiring
> nor being prepared for MARF not be interested in seeing the spam mail,
> or know about what malware was sent from where? So, whether or not it
> is MARF, the abuse report does need to contain such stuff. So, why not
> send MARF (and "promote" it that way) on ANY abuse report if the
> complainer's reporting utility is capable of MARF?
> 
> However, then MARF must not assume that the recipient is expecting and
> capable of handling such unsafe content, which again is another
> argument of shaping the evidence section according to need.

It's not clear to me what change you're proposing here.

-MSK

---

From: zav961 <[email-masked]>
Date: Thu, 28 Jul 2011 17:14:36 -0700 (PDT)

Hello, Murray,

> My understanding is that the general practice of an FBL is
> that they are not typically established in an automated
> fashion.  That may change a little as we do the
> reporting discovery work, but at the moment I don't think
> there are any parties that just start sending or accepting
> FBLs and assuming they're all valid.  Thus, there's
> already an out-of-band component to establishing an FBL, and
> it makes sense to prearrange a list of authorized IP
> addresses in that process rather than in the base protocol.
> ...
> You cited RFC3834 in previous email as your basis for the
> "RFCs" claim above.  I disagree that it applies to
> FBLs, which are typically activated by humans and not by
> software to report spam, and thus aren't automated
> messages.

I see the autoresponders fully involved here - MARF is actually an ideal tool to be used by spam filters, virus scanners and the like, long term they'll certainly take advantage of the possibilities of MARF.

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.

We certainly do spam and malware reporting fully automated. A brief look into history:

In 2002, at the height of the first large virus outbreaks, we decided our mailservers would all get virus scanners (long before any of the large ISPs even began to think about it), and we wrote our first own spamfilter, which would also decode the mails (the virusscanners then couldn't cope with the mail format) and send the decoded parts through the virusscanner. As a result, only for virusses then (we didn't trust our own spamfiltering), we parsed the whois entries for the originating IP addresses of infected mails and sent fully automated malware reports to the relevant abuse mail address. This was quite effective, as quite a lot of malware infected machines got cleaned as result and the load on our mailservers reduced noticeable. We have kept that concept, in the meantime the spam filtering has gotten sufficiently reliable too, and hence our tools now do automated reporting on both issues. With a very few exceptions amongst the ISPs spam bots amongst
their customers get identified and cleaned very quickly as a result.

When Yakov presented his I think second draft on the abuse feedback format, I touched base with him and we discussed one or two details. As result I changed our spam reporting to ARF (but left the malware reporting in our original free text reporting).

In the meantime all large ISPs started to introduce their virus filtering, spam filtering became the norm, and the load overall reduced, especially malware seemed to be a thing of the past. After the shut down of the Russian Business Network our filter software did not catch a single malware for about 2, maybe 3 years. However, we are again seeing malware mails increasing in numbers and our filter probably catches a dozen or two every day again. So, malware reporting is still necessary. In the last few weeks a few of our free text malware reports bounced, one with a large ISP, who said in its bounce message, that MARF is expected for abuse reports. That's basically the trigger of why I checked the current definitions and started implementation of MARF feedback-type virus into our utility until I realized the issues (which resulted in the initial mail to you).

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.

In my opinion, the currently released documents do not create any problem with the spam reporting side. In the malware reporting side however, there is a serious issue I already pointed out.

> I believe someone (you or someone else) claimed that nobody
> has implemented an FBL that reports viruses so far.  If
> that's the case, we could consider updating the registry to
> mark it as historic.  Those are the places where
> RFC3834 might apply.

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

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

> There may be FBLs (such as one run by a malware analysis
> company) that want to get every variant of a virus. 
> Reporting only the virus name and detection software would
> mean the details of a variant are lost.  I don't know
> if this is an issue or not.

Malware analysis companies have established their own channels of how to receive malware samples. That's not a consideration for reporting mail abuse, in my opinion.

Mail abuse reports, as I see it, should trigger an action at the offender's end to stop identified abuse. Therefore it is irrelevant to see what variants exist - if the virusscanner at the complainer's side has detected a malware, there'll be a report that unambiguously identifies the malware. If the virus scanner did not recognize the threat, there will obviously be no report anyway and the malware go through - and may cause damage at the recipient's end, which then will trigger the malware being submitted to malware analysers. You see therefore, these are two very distinct steps, where malware analysers or abuse reports come into play.

So we should remain focussed on the reporting side of identified abuse, which as far as I understand it is the purpose of MARF (mail abuse reporting format).

To hammer the point in: It doesn't matter whether an abuse has been identified by the human pushing a button in his mailer, or whether the abuse has been identified by a spamfilter on established criteria or the abuse has been identified by a virus scanner based on its database and detection criteria. In every case, the abuse has been identified somehow and may lead to a MARF report.

> doing this.  Perhaps we should ask them.

No need to, that's a waste of resources as I lined out above, malware analysers mainly get involved on unidentified threats that already caused damage. They have their own ways of getting those samples.

> This, I believe, is a restatement of the out-of-band issue;
> we know (or at least assume) that reports from random
> sources can't be trusted.

Roger, so we are clear on this point.

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.

Now, I guess, this would hamper introduction of MARF, especially before it gets widely accepted, hence there should be a compromise which allows MARF senders without such identification.

I'd propose to look at the implementation of SPF, and instead of the service selector SPF use MARF, otherwise just import the SPF RFC. Implementations of MARF receiving processors checking the name servers thus could easily use the SPF library with some minor modifications to the source code. The syntax and format, apart from the service, could and should remain identical as the purpose is the same: SPF identifies IP addresses to transmit mails with the specific sender domain, MARF DNS identifies IP addresses permitted to transmit mail abuse reports for a particular entity.

The imported SPF draft will need two additions:

S.1: for reverse DNS resolving (IP address translated into domain name) the relevant MARF entry should be looked up at the full URL, if no entry is found there, drop the most inner part of the URL (e.g. in ip-x-y-z.xyzdomain.co.uk drop the ip-x-y-z) and retry (now on xyzdomain.co.uk) until all parts of the URL are used up (the root domains like com, co.uk, ... might want to publish a MARF entry too, who knows?). Stop at the first discovery of a MARF entry and check originating IP address against those results. (Reason: reverse resolving usually remains under control of the ISP due to name server granularity issues).

S.2: for DNS name resolving (URL as input) resolve the IP address, then determine the MARF entry using S.1 (via reverse resolving). (Reason: malicious domain registrations still need some ISP to host their stuff, and we reach the ISP, not the malicious user that way).

The draft should still nail down that the name server(s) being checked may be under control of a not trustworthy source, and any such identified MARF sender may still be needed to be treated with caution. If an ARIN entry exists identifying the permitted MARF sender, that entry overrules whatever is stated in the name server's MARF entry.

So, in order to summarize the current standing of the discussion and proposals:

A) feedback-type: virus

I propose to change the keyword virus to malware.

To facilitate the malware feedback type, the evidence section (section 3) of MARF should be changed from message/RFC822 to text/RFC822-Headers and contain only and only the complete header of the offending message.

In the report section following fields become mandatory:

Source-IP:  reports the IP address the reporting server received the offending mail directly from

Reported-Malware:  the name of the malware as identified by the reporting malware scanner

Reporting-Utitlity: the name of the reporting malware scanner, ideally also identifying the database in use

An optional field: 

Reported-CVE-ID: the CVE ID numbers, separated by commas, identifying the threats, along http://cve.mitre.org

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.

A sample MARF report:
=====================

From: "Complainer" <[email-masked]>
To: <[email-masked]>
Subject: MARF report
Date: Thu, 28 Jul 2011 21:08:47 +0200
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
    boundary="----=_NextPart_000_004A_01CC4D6A.8AA038D0"

This is a multi-part message in MIME format.

This is a MIME-formatted message.
Portions of this message may be unreadable without a MIME-capable mail program.

------=_NextPart_000_004A_01CC4D6A.8AA038D0
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is an example MARF compliant complaint: we received malware "W32/Mytob.AT@mm" from your IP address 192.168.0.45 at 21:08:45 +0200

Find the full header of the message below. We ask to have this machine checked and cleaned or temporarily disconnected until it has been cleaned.

------=_NextPart_000_004A_01CC4D6A.8AA038D0
Content-Type: message/feedback-report

Feedback-Type: malware
User-Agent: sample MARF generator
Version: 1
Source-IP: 192.168.0.45
Reported-Malware: W32/Mytob.AT@mm
Reporting-Utility: Sample Virus Scanner, database 2011-07-28-5142
Reported-CVE-ID: CVE-1999-0067, CVE-1999-0068

------=_NextPart_000_004A_01CC4D6A.8AA038D0
Content-Type: text/RFC822-Headers

Return-Path: <[email-masked]>
Received: from ([192.168.0.45])
    by mail.complainer.com with ESMTP id p6SJ82qN000353
    for <[email-masked]>; Thu, 28 Jul 2011 19:08:45 GMT
Date: Thu, 28 Jul 2011 19:08:45 GMT
To: [email-masked]
From: [email-masked]
Subject: Your documents attached

------=_NextPart_000_004A_01CC4D6A.8AA038D0--

A sample DNS entry:
===================

marf.sample.com.     1D IN TXT         "v=marf1 ip4:192.168.0.48 -all"

@            1D IN TXT        "v=marf1 redirect=marf.sample.com"

---

From: "John Levine" <[email-masked]>
Date: 29 Jul 2011 13:38:38 -0000

>I see the name of the virus together with the name of the virus
 scanner producing the identification as equivalent to the actual byte
 stream

Please do not assume that everyone else's system works the same way
that yours does.

For the virus reports I send, I have no idea what virus it is.  My
system makes the fairly safe assumption that any message with an
attached EXE sent to a spam trap is a virus.  I lightly denature the
report by changing the first few bytes of the bas64 attachment to xxxx
so it's not executable any more, just in case some misconfigured piece
of mail software tries to do something unwise with it.

> why would we then ENFORCE sending such malware in abuse reports?

Because decades of experience have taught us that a full, unredacted
copy of the message being reported is the most useful thing you can
send to a feedback consumer.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Jul 2011 19:34:19 +0200

On 29/Jul/11 02:14, zav961 wrote:
> I see the autoresponders fully involved here - MARF is actually an
> ideal tool to be used by spam filters, virus scanners and the like,
> long term they'll certainly take advantage of the possibilities of
> MARF.
> 
> [...]
> 
> 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.

Automatically triggered reports to discovered (not FBL) consumers may
actually correspond to the etymological DSN origin or ARF.  An MTA
decides to quarantine a message, either UBE or virus, and issues a
report.  The report should be sent with an empty smtp.mailfrom in this
case, so it may be an alternative to "Report-Trigger".  I concur that
text/rfc822-headers is enough for automatically discovered viruses, if
Reported-Malware is set.

How about UBE?  Such reports probably also need to be handled
differently, according to their human/auto origin.

> Malware analysis companies have established their own channels of
> how to receive malware samples. That's not a consideration for
> reporting mail abuse, in my opinion.

I disagree on this.  Many companies have, or used to have, email
addresses specific for (suspected) virus submission by humans, e.g.
[email-masked], [email-masked], [email-masked], ...
Most of them recommend to use zip files, possibly password-protected
so that sender-side mail scanners won't block them.

> If the virus scanner did not recognize the threat, there will 
> obviously be no report anyway and the malware go through - and may
> cause damage at the recipient's end, which then will trigger the
> malware being submitted to malware analysers.

That is to say, there will be a report, but to a different consumer.

jm2c

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 29 Jul 2011 13:23:29 -0700

> 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 get…

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.

> In the meantime all large ISPs started to introduce their virus filtering, spam filtering became the norm, and the load overall reduced, especially malware seemed to be a thing of the past. After t…

Perhaps if you were to contact Yahoo!, they'd set up a trusted channel for your ARF reports where they'll be given a higher priority than random mail to abuse@.

> Now, I guess, this would hamper introduction of MARF, especially before it gets widely accepted, hence there should be a compromise which allows MARF senders without such identification.

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.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 30 Jul 2011 10:08:27 +0200

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?

The larger part of feedback comes from webmail systems.  They /are/
MUAs, although somewhat more loosely constrained by mail protocols.

-- 
[*] 9 Dec 2009 00:35:03 -0500
http://www.ietf.org/mail-archive/web/asrg/current/msg15780.html
http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs
http://wiki.asrg.sp.am/wiki/Abuse_Reporting

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 31 Jul 2011 09:57:24 -0400

In <[email-masked]>, on
07/28/2011
   at 05:14 PM, zav961 <[email-masked]> said:

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

That would seem to be a case where it is desirable to include the full
message; the typical end user cannot be trusted to make an accurate
determination.

>B.2 Require ARIN/delegated authorities published abuse addresses to
>unconditionally accept MARF reports

Even if they have registered a separate address for MARF?

-- 
     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: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 31 Jul 2011 10:03:21 -0400

In <[email-masked]>, on
07/29/2011
   at 01:23 PM, "J.D. Falk" <[email-masked]> said:

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

Keep in mind that once a large corporation is requiring that abuse
reports be in ARF, the case for the MUA sending reports in MARF is
much stronger. While I consider it inexcusable to ignore text
complaints sent to abuse, I don't see the offenders backing off.