Subject: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01

From: "J.D. Falk" <[email-masked]>
Date: Wed, 12 May 2010 15:34:48 -0600

The xml2rfc issues are fixed, so I submitted an -01 which should be easier to read -- and incorporates many of the suggestions offered thus far.

(Next, I need to figure out why the submission tool grabs my organization name instead of my actual name.)

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: May 12, 2010 3:30:27 PM MDT
> To: [email-masked]
> Subject: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 
> 
> 
> A new version of I-D, draft-jdfalk-marf-reporting-discovery-01.txt has been successfully submitted by Return Path and posted to the IETF repository.
> 
> Filename:	 draft-jdfalk-marf-reporting-discovery
> Revision:	 01
> Title:		 Advertising and Discovering Willingness to Provide or Receive ARF Reports
> Creation_date:	 2010-05-12
> WG ID:		 Independent Submission
> Number_of_pages: 11
> 
> Abstract:
> This document defines a method for network operators to advertise
> their willingness to send feedback about received email to other
> parties, and for those other parties to advertise their willingness
> to receive such feedback.
> 
> 
> 
> The IETF Secretariat.
> 

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: Barry Leiba <[email-masked]>
Date: Wed, 12 May 2010 20:33:28 -0400

> name instead of my actual name.)

Just for the fork of it, try re-ordering the attributes in the
"author" element, to put them in the order "initials", "surname",
"fullname".  See if that makes any difference.

And, by the way, you can remove the "month" attribute from the "date"
element, and it will fill in the current month (and day).  That way,
you don't have to change it every month.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 May 2010 20:01:30 -0700

I also suggested he open a bug about the submission tool, because really that shouldn't be an issue.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 13 May 2010 05:50:56 -0400

In <[email-masked]>, on
05/12/2010
   at 03:34 PM, "J.D. Falk" <[email-masked]> said:

>The xml2rfc issues are fixed, so I submitted an -01 which should be
>easier to read -- and incorporates many of the suggestions offered
>thus far.

Isn't it desirable to allow a consumer to specify a policy of rp=r?

   r Open to reports only after the prospective generator has
     completed a registration process, which may be found by the
     by the URI defined by the u? tag below.
     ...
   u? URI for additional information.  This field SHOULD be
      defined for a policy of "c", "o" or "u", and MUST be
      defined when the policy is "r".  Otherwise, the field is
      optional; there is no default.

As an alternative to a new u?=<URI> field, the definition of uu=<URI>
could be expanded.

-- 
     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: Alessandro Vesely <[email-masked]>
Date: Thu, 13 May 2010 18:34:57 +0200

>>  Creation_date:	 2010-05-12

Three points:

*Consumers vs generators*
The new paragraph about generators is rather puzzling, as it considers 
a generator who wishes to send a report to a consumer. It may be worth 
to note --in an earlier section-- that a (prospect) consumer is one 
who sends a message and is worried about its worthiness. That is, if 
the sending MTA is wary, e.g. because the number of recipients exceeds 
some limit, it may want to check each recipient's domain.

An ADMD would keep a database of the domains with whom they have 
established an FBL already. For new domains, this I-D describes how to 
discover whether it is possible to establish a new FBL. But how? 
Scalability requires that an application process can be started right 
away, automatically, while the message is being relayed.

Please note that we have an alternative to DNS here. The FBL policy 
can also be advertised in an ehlo-line, e.g.

  250-FBL_report gp=r; gu=http://postmaster.example.com/

That would save a query, but is only available for client software 
that has access to the full ehlo response of each server.

*Record format intro*
There should be some text introducing the tags, near the beginning of 
section 5. I'd propose something like

  Each resource record consists of a list of "tag=value" elements
  terminated by a semicolon.

*Consistency with other mailboxes*
An abuse-mailbox is often defined in whois records of registered 
domains (where it is subject to query limits.) In addition, RFC 2142 
mandates [email-masked]. Should the published "r=" address match 
any of these? In some cases, shouldn't it default to that 
[email-masked]?

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 13 May 2010 17:02:41 -0600

> I also suggested he open a bug about the submission tool, because really that shouldn't be an issue.

They say they don't know why it's happening, but a new version should be released soon which won't have that problem.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Fri, 14 May 2010 06:17:39 -0400

In <[email-masked]>, on 05/13/2010

>  250-FBL_report gp=r; gu=http://postmaster.example.com/

IMHO that's the wrong way to do it. There's a well defined mechanism
for extending SMTP; why not use it instead of relying on ad hoc
parsing of free text fields?

 C: EHLO example.com
 S: 250-Welcom to bar.com
 S: 250-MARF
 S: 250 8BITMIME
 C: MARFINFO
 S: 250 FBL_report gp=r; gu=http://postmaster.example.com/

>domains (where it is subject to query limits.) 

If we're going to suggest relying on whois data then we should specify
the syntax of the relevant line in the whois record.

>RFC 2142 mandates [email-masked].

It mandates having a functional abuse mailbox; it doesn't prohibit
having other role accounts. It might make sense to have distinct
default mailboxes for report and text.

---

From: [email-masked]
Date: Fri, 14 May 2010 10:16:47 -0400

Why do it during the SMTP transaction?  That data is not needed at the time the message is delivered.  It is needed at the time feedback is generated.

-----Original Message-----
From: Shmuel (Seymour J.) Metz <[email-masked]>
To: [email-masked]
Sent: Fri, May 14, 2010 3:17 am
Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01

 C: EHLO example.com
 S: 250-Welcom to bar.com
 S: 250-MARF
 S: 250 8BITMIME
 C: MARFINFO

_______________________________________________
marf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/marf

---

From: Douglas Otis <[email-masked]>
Date: Fri, 14 May 2010 10:51:56 -0700

On 5/14/10 3:17 AM, Shmuel (Seymour J.) Metz wrote:
> > can also be advertised in an ehlo-line, e.g. 250-FBL_report gp=r;
> > gu=http://postmaster.example.com/
>
>  C: EHLO example.com S: 250-Welcom to bar.com S: 250-MARF S: 250
>  8BITMIME C: MARFINFO S: 250 FBL_report gp=r;
>  gu=http://postmaster.example.com/

This suggests contacting an inbound server to ask where to send feedback 
related to some other outbound server which means this path can be 
easily abused.
Without a method to verify a message is associated with a specific 
feedback server, the path is likely to be targeted for abuse, as abuse@ 
has been.

> > *Consistency with other mailboxes* An abuse-mailbox is often
> > defined in whois records of registered domains (where it is
> > subject to query limits.)
>  If we're going to suggest relying on whois data then we should
>  specify the syntax of the relevant line in the whois record.

Automation related to feedback needs a defensive strategy.  Allow 
clients to indicate where feedback is to be directed. This path should 
be within the EHLO domain that permits the outbound servers address to 
be verified with a forward referenced address or APL.

  C: EHLO mx-001.example.com
  S: 250-Welcome mx-001.example.com [192.168.1.1] to bar.com
  S: 250-MARF
  S: 250 8BITMIME
  C: MARFPATH <[email-masked]>
  S: 250 Ok

The server might also respond with 252 or 554 Unable to verify 
mx-001.example.com.
This approach would exclude typical bot spam engines while also 
providing a method to defend the feedback path.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 15 May 2010 13:54:30 +0200

Douglas Otis wrote:
> related to some other outbound server

Not really. It is contacting an inbound server to ask where to 
_apply_ in order to receive feedback in case messages originating by 
this client will be reported as spam. Such info is not tied to the 
specific message at hand, except that since the client is sending 
mail there, it may be interested in the FBL.

Currently, clients get the few existing URLs of this type by word of 
mouth. In addition, those "postmaster" sites are designed for 
interactivity. A non-scalable setup.

> which means this path can be easily abused.

Correct, nevertheless.

> feedback server, the path is likely to be targeted for abuse

What is a "feedback server", the generator or the consumer?

> as abuse@ has been.

Has it?

>> specify the syntax of the relevant line in the whois record.

Because of the usability limit, it may rather work the other way 
around: provide hints for verifying whois data consistency.

> be verified with a forward referenced address or APL.

(APL?)

>  C: MARFPATH <[email-masked]>

I'm not sure what you mean by "within the EHLO domain". What if 
example.com outsources ARF processing to some 3rd party?

> providing a method to defend the feedback path.

Why cannot it be abused just like the MAIL FROM path?

The defense implied by relegating that datum in the envelope poses 
some difficulties in case of multi-hops, and it cannot be DKIM-signed.

IMHO, abuse at an abuse-box is pretty unavoidable. Since we are 
talking about publishing and advertising an address, we cannot 
require that it remains secret. But then, hey, getting spam in an 
abuse-box is like discovering bugs during tests, we should just 
thank our luck.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sat, 15 May 2010 21:24:08 -0400

In <[email-masked]>, on
05/14/2010
   at 10:16 AM, [email-masked] said:

> Why do it during the SMTP transaction? 

I wasn't taking a position on whether to do it during the SMTP
transaction. Rather, I was taking a position on using free text fields
as a mechanism for carrying machine-readable data. If we do it during
SMTP at all then I strongly believe that we should use the defined
extension mechanism rather than an ad hoc overloading of an existing
response.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 16 May 2010 18:19:34 -0700

On 5/15/10 4:54 AM, Alessandro Vesely wrote:
> > This suggests contacting an inbound server to ask where to send
> > feedback related to some other outbound server

Some messages are incorrectly identified as spam.  As such, a 
relationship needs to be established between outbound clients and a 
feedback server, regardless of the discovery process.  Confirmation of 
this relationship is needed to protect confidentiality with false 
positive detections.

>  interactivity. A non-scalable setup.

Agreed.

>  What is a "feedback server", the generator or the consumer?

A feedback server accepts problematic messages originally emitted by an 
associated outbound client, or messages appearing to spoof an associated 
domain.   A third-party authorization scheme for DKIM could be used to 
safely exclude apparent spoofing as well as to authorize feedback 
domains.  More to follow.

>  Has it?

Yes, from my experience.  When there is abuse, having a method to change 
the path can help thwart abusive campaigns, and expose the source.

> > clients to indicate where feedback is to be directed. This path
> > should be within the EHLO domain that permits the outbound servers
> > address to be verified with a forward referenced address or APL.
>  (APL?)

Some domains will likely desire strict control of their feedback path.  
Overloading MARF feedback validation with SPF intended to authorize a 
client's use of Mail-From parameters or PRA headers would prove 
problematic.  After all, SPF is applied against clients handling 
messages from thousands of domains.

APL stands for Address Prefix List (See RFC 3123).  This single 
transaction alternative could be used in the few cases where address 
record sets prove inadequate.

>  example.com outsources ARF processing to some 3rd party?

An MX record at the mx-001.example.com node could target any desired 
feedback server.   This assumes the EHLO verified the administrative 
domain of the outbound client.  With the domain verified, it can be 
relied upon to indicate where feedback for the client's messages are to 
be directed.

Source spoofing would be a different issue, where the definition of 
spoofing would likely be based upon the From header.  Hence ADSP.   To 
suppress the noise generated by many exceptions in a From domain 
criteria, a third-party authorization scheme could help.

>  Why cannot it be abused just like the MAIL FROM path?

The MARF extension can raise expectations of being able to verify the 
EHLO.  Ascertaining the domain an abusive source provides simpler 
defensive strategies.

>  some difficulties in case of multi-hops, and it cannot be

The third-party authorization scheme proposed for DKIM offers a single 
transaction able to associate any number of domains without use of 
signatures.

>  abuse-box is like discovering bugs during tests, we should just thank
>  our luck.

By having a scheme that collects information related to abuse sources, 
and that modulates paths as needed, this would not rely upon luck.

A dependable feedback scheme is needed.  Many large ISPs have discovered 
that processing high volumes of submission traffic requires elaborate 
strategies to defend account identifications and authorizations. :^(

A responsible ISP must quickly respond to evidence of abuse by rate 
limiting sources and disabling accounts.  Email accounts represent a 
weak link in security, since email is often used to recover lost 
passwords for other highly sensitive services.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 17 May 2010 10:32:19 +0200

Douglas Otis wrote:
>> [...gu=...] is [for] contacting an inbound server to ask where to 

Well, that's not /regardless/ of the discovery process. In this 
case, the discovery process provides the starting point for 
establishing that relationship. I tend to consider it a peculiar 
kind of relationship between two ADMDs, rather than between specific 
hosts of theirs. It doesn't have to be a symmetric relationship, as 
it provides for different roles of outbound clients and feedback 
consumers for one ADMD, STMP servers and feedback generators for the 
other ADMD.

Confidentiality is certainly a concern, but I don't think it is the 
only reason for requiring that relationship. Validating a feedback 
generator's input to an abuse-box is another one.

Yet, in some cases, reports are transmitted with no prior agreement.

> domain.

Fine. I'd stick with the term "consumer", as it seems less ambiguous.

> A third-party authorization scheme for DKIM could be used to 
> domains.

Agreed. Abuse reports DKIM-signed by the generating ADMD, allow 
third parties. I'd require generated feedback to be _always_ 
DKIM-signed, irrespective of any signature that may be present or 
required in the reported message.

> APL stands for Address Prefix List (See RFC 3123).

Thanks for the explanation. I think APL or SPF may be used, 
according to local policies, for establishing a relationship between 
two ADMDs. However, IP addresses or ranges should not be part of the 
relationship records: When a mailbox provider changes one or more of 
its network providers, its IP addresses also change. Current FBL 
subscription procedures that check IP vs domain relationship have to 
be re-done in such occasions, which is non-scalable.

Tracking domain's registrants may be a better strategy.

> relied upon to indicate where feedback for the client's messages are to 

Hm... EHLO cannot be used to verify a domain. VHLO --that's the name 
John Klensin suggested for "Verified HelLO"-- would be needed for it.

> transaction able to associate any number of domains without use of 

This would imply too much interpretation of DNS names, IMHO. Since 
it is not possible to reliably learn zone cuts and delegations, I 
would refrain from specifying the feedback consumer that way.

An abuse-box's script should be able to sort out good reports by 
checking its trusted feedback generators list for the ADMD 
corresponding to the report's signature "d=" tag.

> passwords for other highly sensitive services.

OK, but let's stick to minimal requirements for generalizing FBLs. 
If this will fly, it may happen to become a building block for the 
"mythical global reputation systems". However, if we require 
anything that may resemble a reputation system for building this, 
chances are we'll never even reach the runway.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 May 2010 12:20:31 -0700

On 5/17/10 1:32 AM, Alessandro Vesely wrote:
>> feedback server, regardless of the discovery process.  Confirmation 
>> of this relationship is needed to protect confidentiality with false 
>> positive detections.
>
> Well, that's not /regardless/ of the discovery process. In this case, 
> the discovery process provides the starting point for establishing 
> that relationship. I tend to consider it a peculiar kind of 
> relationship between two ADMDs, rather than between specific hosts of 
> theirs. It doesn't have to be a symmetric relationship, as it provides 
> for different roles of outbound clients and feedback consumers for one 
> ADMD, STMP servers and feedback generators for the other ADMD.
>
One might assume the reason for having an automated discovery process 
for feedback servers would be to allow messages lacking prior agreements.

There are two possible criteria might be applied when selecting a 
feedback server.  Selection might be based upon:
a) messages from clients associated with feedback servers through some 
mechanism.
b) apparent spoofing of a domain associated with feedback servers 
referenced by that domain.

'a' represents the best criteria for identifying problematic accounts.
'b' represents the best criteria for content filters and vetting sources.

>> A feedback server accepts problematic messages originally emitted by 
>> an associated outbound client, or messages appearing to spoof an 
>> associated domain.
Consumer of what?  Problematic messages, or reports of problematic 
messages.  Client / server still seems better defined.
>> A third-party authorization scheme for DKIM could be used to safely 
>> exclude apparent spoofing as well as to authorize feedback domains.
> Agreed. Abuse reports DKIM-signed by the generating ADMD, allow third 
> parties. I'd require generated feedback to be _always_ DKIM-signed, 
> irrespective of any signature that may be present or required in the 
> reported message.
Agreed.
> Thanks for the explanation. I think APL or SPF may be used, according 
> to local policies, for establishing a relationship between two ADMDs. 
> However, IP addresses or ranges should not be part of the relationship 
> records: When a mailbox provider changes one or more of its network 
> providers, its IP addresses also change. Current FBL subscription 
> procedures that check IP vs domain relationship have to be re-done in 
> such occasions, which is non-scalable.
Are you suggesting that feedback servers should only be located using 
reverse DNS, rather than using any forward reference?
> Tracking domain's registrants may be a better strategy.
I don't know what that means in regard to ensuring only correct feedback 
servers receive the selected feedback.
>> relied upon to indicate where feedback for the client's messages are 
>> to be directed.
>
The MARF extension could be used in conjunction with an assurance that 
EHLOs be verifiable.
>> The third-party authorization scheme proposed for DKIM offers a 
>> single transaction able to associate any number of domains without 
>> use of signatures.
>
> This would imply too much interpretation of DNS names, IMHO. Since it 
> is not possible to reliably learn zone cuts and delegations, I would 
> refrain from specifying the feedback consumer that way.
You should review how association are made.  There is no dependence upon 
zone boundaries.

http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03
> corresponding to the report's signature "d=" tag.
Of course, but that is a separate issue from selecting the feedback 
server.  Bad actors should not be able to intercept a portion of an SMTP 
client's traffic when criteria 'a' is being used.
>> A dependable feedback scheme is needed.  Many large ISPs have 
>> discovered that processing high volumes of submission traffic 
>> requires elaborate strategies to defend account identifications and 
>> authorizations. :^(
>>
> OK, but let's stick to minimal requirements for generalizing FBLs. If 
> this will fly, it may happen to become a building block for the 
> "mythical global reputation systems". However, if we require anything 
> that may resemble a reputation system for building this, chances are 
> we'll never even reach the runway.
Criteria 'a' represents information most relevant to managing SMTP clients.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 May 2010 18:14:59 -0700

The MARF discovery draft raises troubling issues. It defines roles 
strictly in terms of domains, which is wrong of course.

The draft describes administrative management domains as feedback 
consumers who publish in DNS at domains matching DKIM 'd=' values of 
outgoing signatures, domains matching those present in SMTP MAIL 
commands for sending mail, and/or domains referenced by reverse DNS PTR 
records of the IP address used by outbound border MTAs.

The draft offers little guidance in respect to who should be expected to 
act, and whether it is okay issue reports based upon unverified domain 
information present within SMTP mail messages and commands.

MARF Responsible Parties should be defined as follows:

_Most_Responsible_Entity_. Administrators of an Autonomous System (IP 
address owners), see RFC 4271 for BGP details.

These owners are managed by AfriNIC, APNIC, ARIN, LACNIC, RIPE-NCC who 
are Regional Internet Registries that identify owners by offering whois 
at whois.afrinic.net, whois.apnic.net, whois.arin.net, whois.lacnic.net, 
whois.ripe.net respectively.

Only owners of the IP address space are able to mitigate abuse from 
_any_ source making them the most responsible for mitigation. These 
owners are identified by their Autonomous System Number, which is used 
to advertise IP address space. The related address space is _always_ 
kept current with BGP advertisements, since this is how Internet traffic 
is routed.

_Next_Responsible_Entity_, Email Service Providers as determined by the 
IP address used by their system.

ESPs acquire access from those managing an AS. Only use of an IP address 
provides a verifiable relationship between an Email Service Provider and 
the AS or Domain.

Domains do not directly represent a responsible entity. A domain can 
claim use of any IP address within their DNS zone without any claim 
being true. Only when the domain resolves the IP address of an 
interacting host, can responsibility be established, but this is 
confined to these IP addresses.

As an analogy, consider the U.S. Online Copyright Infringement Liability 
Limitation Act (OCILLA), part of the U.S. Digital Millennium Copyright 
Act. It uses the term "service provider" to mean an entity offering the 
transmission, routing, or providing of connections for digital online 
communications, between or among points specified by a user, of material 
of the user’s choosing, without modification to the content of the 
material as sent or received. Routing and an transmission is the AS 
bailiwick.

"Service provider" also means an Online Service Provider (OSP) or 
Internet Access Provider (IAP), or the operator of facilities for OSPs 
or IAPs. For the purpose of MARF, this would be within the ESP Bailiwick.

Protection under OCILLA requires the service provider to act 
expeditiously to take down infringements, and to not benefit from 
infringing activity. This is construed to include attracting more users. 
While the service provider has no duty to monitor for infringements, 
they must respond to notifications of infringement which includes within 
a single message the following:

i) A signature of a person authorized to act on behalf of entity making 
the allegation.

ii) identify or list infringements.

iii) identify the infringing material to be removed.

iv) offer sufficient information to locate the infringement.

v) a statement that notification is being made in good faith.

vi) a statement that the notification is accurate, and under penalty of 
perjury, they are authorized to act on behalf of the owner.

Does email need a copyright notice on the use of the From Header? There 
is an easy way for a domain to specially authorize third-parties to 
include their From headers. One wonders whether there should be 
boiler-plate language that makes OCILLA like declarations, where 
infringement includes violation of a From header copyright.

Clearly, MARF messages must go to an entity able to take action. Since 
most spam is emitted by compromised systems, _only_ the AS able to act 
in these cases. So in general, MARF discovery fails in the most 
important case. In the cases where a domain is extracted from an SMTP 
command or message, this should only occur when the sender provides a 
method to verify that the domain is managed by the outbound system 
through specific references and demonstration of use.

-Doug