Subject: [marf] The case of forwarding spam reports to 3rd parties, in reporting-discovery

From: Alessandro Vesely <[email-masked]>
Date: Tue, 13 Jul 2010 19:50:54 +0200

J.D. has committed the additions I proposed to his [DRAFT], which, 
among other things, discourage forwarding abuse reports to 3rd 
parties.  However, that recommendation does not match with items #3 
"Connection provider" and #4 "Reputation tracker" in the report flow 
depicted in [AR].

How come?  My understanding is that MARF, and the [DRAFT] in 
particular, focus on /tractable/ spam.  That is, cases where a 
responsible party is readily identifiable and willing to cooperate. 
In such circumstance, it may make sense to drop any interest on how 
opt-in practices had been carried out, and instruct an informal 
process that will cure the issue at hand.

Forwarding to the connection provider is more akin to reporting 
network incidents.  It suits botnets and other "intractable" spammers, 
and may be better dealt with using IODEF-style reporting.  Whatever 
the style, the current [DRAFT] wording is that "feedback generators 
SHOULD NOT send reports to ADMDs that are not responsible for the 
reported message", thus it would be enough to hold that a carrier /is/ 
in some sense responsible for the message transmission.

Reputation trackers are needed to avoid that cooperative senders 
actually become opt-out operators with licence to spam.  This topic is 
not yet well understood --at least by me.  However, feedback is a 
fundamental ingredient of any reputation systems, so preventing it is 
not a good idea.  However, there is no equivalent of the WHOIS LIR 
assignments databases in order to ascertain the involvement of a 
reputation tracker.  How are we going to make up for that?

-- 
[DRAFT] http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery
[AR] 
http://wiki.asrg.sp.am/wiki/Abuse_Reporting#The_Feedback_Loop_.28FBL.29_and_other_usage_of_abuse_reports

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 26 Jul 2010 18:54:04 +0200

I'd been leaving this for discussion during the meeting tomorrow, but just re-read it and realized I can answer these questions now.

On Jul 13, 2010, at 7:50 PM, Alessandro Vesely wrote:

> Forwarding to the connection provider is more akin to reporting network incidents.  It suits botnets and other "intractable" spammers, and may be better dealt with using IODEF-style reporting.  Whatever the style, the current [DRAFT] wording is that "feedback generators SHOULD NOT send reports to ADMDs that are not responsible for the reported message", thus it would be enough to hold that a carrier /is/ in some sense responsible for the message transmission.

The carrier (which I'd call an "access provider") is responsible for the connection to the source of the message.  I suppose that's not the same ADMD, so far as mail transport is concerned, so this may require clarification.  (Note that I'm referring to current practice, there, so it's a matter of adequately describing the practice rather than justifying its validity.)

> Reputation trackers are needed to avoid that cooperative senders actually become opt-out operators with licence to spam.  This topic is not yet well understood --at least by me.  However, feedback is a fundamental ingredient of any reputation systems, so preventing it is not a good idea.  However, there is no equivalent of the WHOIS LIR assignments databases in order to ascertain the involvement of a reputation tracker.  How are we going to make up for that?

[AR] doesn't adequately depict the relationship between mailbox providers and reputation trackers.

There are two ways that complaint feedback reports get to a reputation tracker today.  One is that the end user can configure their MUA to send the feedback to the reputation tracker directly, generally by installing a plug-in; this is how spamcop operates.  The other is that the end user's mailbox provider enters into a relationship with the reputation tracker, either by contract (which is what we do for senderscore) or by purchasing a particular vendor's anti-spam software (i.e. Cisco/Ironport, which then feeds senderbase.)

It could be argued that either of these two latter scenarios actually place the reputation tracker within the mailbox provider's ADMD, so far as mail transport is concerned.

> [AR] http://wiki.asrg.sp.am/wiki/Abuse_Reporting#The_Feedback_Loop_.28FBL.29_and_other_usage_of_abuse_reports

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 27 Jul 2010 14:25:55 +0200

On 26/Jul/10 18:54, J.D. Falk wrote:
>>  Forwarding to the connection provider [...]
>
> The carrier (which I'd call an "access provider") is responsible
> for the connection to the source of the message.  I suppose that's
> not the same ADMD, so far as mail transport is concerned, so this
> may require clarification. (Note that I'm referring to current
> practice, there, so it's a matter of adequately describing the
> practice rather than justifying its validity.)

I attach my attempt.  I haven't mentioned abusix [AX] explicitly, as 
"specific projects' databases".  Do they deserve a reference?

BTW, they are currently working with an "x-arf" project [XA], 
formatted using yaml.

>>  Reputation trackers [...]
>
> There are two ways that complaint feedback reports get to a
> reputation tracker today.  One is that the end user can configure
> their MUA to send the feedback to the reputation tracker directly,
> generally by installing a plug-in; this is how spamcop operates.

I didn't know about their plug-in and helper scripts [SC].

IMHO, their Reporting Service plays the role that a "Last MX" should 
cover, rather than that of a reputation tracker proper --well, they 
also track reputations, but those activities, in their own words, 
"operate independently of each other, [although] they also rely on 
each other to operate effectively".

I've updated [AR] to take that into account.  Is it any better?

> The other is that the end user's mailbox provider enters into a
> relationship with the reputation tracker, either by contract (which
> is what we do for senderscore) or by purchasing a particular
> vendor's anti-spam software (i.e. Cisco/Ironport, which then feeds
> senderbase.)

How would you depict that?

> It could be argued that either of these two latter scenarios
> actually place the reputation tracker within the mailbox provider's
> ADMD, so far as mail transport is concerned.

Hm.. "within" suggests access to data available at the mailbox 
provider's.  For the Reporting Service, this is limited to a message's 
topmost header fields.  Do SenderScore's contracts or Ironport provide 
for more data exchange?

>>  [AR] http://wiki.asrg.sp.am/wiki/Abuse_Reporting#The_Feedback_Loop_.28FBL.29_and_other_usage_of_abuse_reports

[AX] http://abusix.com/
[XA] http://www.x-arf.org/specification.html
[SC] http://www.spamcop.net/fom-serve/cache/166.html

--- draft-jdfalk-marf-reporting-discovery-01.xml	2010-06-26 12:36:52.000000000 +0200
+++ draft-jdfalk-marf-reporting-discovery-0a.xml	2010-07-27 12:55:44.000000000 +0200
@@ -348,6 +348,22 @@
 				that address.  Otherwise, if a "pass" is obtained for the
 				HELO/EHLO name, that domain name.</t>
 			</section>
+			<section title="Access provider of transmitter's IP">
+				<t> The IP address of the SMTP client that has transmitted the
+				reported message belongs to a block that one of the five Regional
+				Internet Registries has allocated to an access provider.  Choosing
+				the 1st level (largest) range most often results in a different
+				organization --the network that hosts the transmitter.  Contacts
+				can be obtained querying either WHOIS or specific projects'
+				databases designed for this very task.</t>
+				<t> In addition, validating the IP address using the "iprev"
+				method may lead to one or more ADMDs that the relevant IP is
+				affiliated with.</t>
+				<t> In both cases, the resulting ADMDs may correspond to
+				organizations that are only indirectly responsible for sending the
+				reported message, but may act as arbitrators for the abuse case at
+				hands.</t>
+			</section>
 		</section>
 
 		<section anchor="IANA" title="IANA Considerations">
@@ -382,6 +398,11 @@
 				at an ADMD that handled a given message could have intercepted the
 				message when they signed or relayed it, if they wanted to,
 				therefore it is less of a concern to forward abuse reports there.</t>
+				<t> Third parties that are only indirectly responsible for the
+				transmission of a message are unable to intercept the message, e.g.
+				in case of encrypted SMTP sessions.  Their compliance with relevant
+				policies should be ascertained stemming from their institutional
+				role, in these cases.</t>
 				<t> Contact addresses for a given domain name should bear such
 				name as their domain parts.  Generators may treat non-conforming
 				addresses with great suspicion, possibly avoiding to relay to them.