Subject: [marf] I-D Action: draft-ietf-marf-as-07.txt

From: [email-masked]
Date: Tue, 07 Feb 2012 22:39:17 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF.

	Title           : Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
	Author(s)       : J.D. Falk
                          M. Kucherawy
	Filename        : draft-ietf-marf-as-07.txt
	Pages           : 13
	Date            : 2012-02-07

   RFC 5965 defines an extensible, machine-readable format intended for
   mail operators to report feedback about received email to other
   parties.  This document describes common methods for utilizing this
   format for reporting both abuse and authentication failure events.
   Mailbox Providers of any size, mail sending entities, and end users
   can use these methods as a basis to create procedures that best suit
   them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-as-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-07.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Feb 2012 22:42:46 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, February 07, 2012 10:39 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-marf-as-07.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Messaging Abuse Reporting
> Format Working Group of the IETF.
> 
> 	Title           : Creation and Use of Email Feedback Reports: An
> Applicability Statement for the Abuse Reporting Format (ARF)
> 	Author(s)       : J.D. Falk
>                           M. Kucherawy

Incorporated Shmuel's tweaks, and also reworked the text to make it clear which parts apply to conventional ARF reports and which parts apply to automated reports like authentication failures as Scott pointed out.

Still in WGLC until Friday.  Have at it.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Wed, 8 Feb 2012 06:26:33 -0800

> Still in WGLC until Friday.  Have at it.

8.1 talks about sending unsolicited reports of authentication failure while 9.1 states that unsolicited reports of authentication failure MUST NOT be sent. One of those likely needs to change (probably 8.1).

8.6 implies that the d= domain is always a good place to send an unsolicited report if it leads to a deliverable email address. Is that what we mean to say?

Cheers,
  Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 08 Feb 2012 17:21:11 +0100

> Still in WGLC until Friday.  Have at it.

*Abstract*

The abstract says "end users can use these methods", which may be
somewhat misleading.  How about "and conceivably even end users", or
equivalent English text?

*Generating and Handling Unsolicited Abuse Reports*

I'd suggest the leading paragraph be more similar to that of Section
9, instead of:

 The following advice is offered for the case of reports that are not
 solicited:

For example:

 There are cases where no sending parties have requested reports,
 possibly because they did not know how to apply, or didn't care.

*Generating Automatic Authentication Failure Reports*

Barry's advice on numbering is missing.

Paragraph 2 seems to be overly restrictive.  IMHO, it suffices to say
that the report "MUST NOT be sent automatically".  That way, a
generator can still produce its data for local debugging or manual
forwarding.

I'm unable to understand the first sentence of paragraph 3.  Reports
have to be new messages irrespectively of whether the original message
was accepted or rejected.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 08 Feb 2012 17:29:24 +0100

On 08/Feb/12 15:26, Steve Atkins wrote:
> 
> 8.1 talks about sending unsolicited reports of authentication
> failure while 9.1 states that unsolicited reports of authentication
> failure MUST NOT be sent.

No, 8.1 talks about sending unsolicited abuse reports.

> 8.6 implies that the d= domain is always a good place to send an
> unsolicited report if it leads to a deliverable email address. Is
> that what we mean to say?

No.  A "reasonable candidate" implies a few attempts can be done.

We are unable to order the candidate destinations described in 4 and 6
according to some criteria.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 8 Feb 2012 08:56:48 -0800

> No, 8.1 talks about sending unsolicited abuse reports.

"Such criteria might include direct complaint
        submissions from MUAs, reports triggered by mail sent to "spam
        trap" or "honeypot" addresses, reports of authentication
        failures, and virus reports."

That's talking about "reports of authentication failure".

s/reports of authentication failures,// is the obvious fix.

> No.  A "reasonable candidate" implies a few attempts can be done.

I'm not sure what you mean there.

8.6 fairly strongly implies that the only reason that a DKIM d= might
not be an appropriate place to notify is if the d= is being used to
distinguish reputation streams. That's only one of several reasons
it may not be a reasonable candidate.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Feb 2012 11:14:21 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Wednesday, February 08, 2012 6:27 AM
> To: Message Abuse Report Format working group
> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt
> 
> 8.1 talks about sending unsolicited reports of authentication failure
> while 9.1 states that unsolicited reports of authentication failure
> MUST NOT be sent. One of those likely needs to change (probably 8.1).

Right; fixed.  I only found one reference though; let me know if there are others.

> unsolicited report if it leads to a deliverable email address. Is that
> what we mean to say?

I don't agree that it says "always", since the words are "likely" and "not universally true".

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Feb 2012 11:18:43 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Wednesday, February 08, 2012 8:21 AM
> To: [email-masked]

How is it misleading?

> I'd suggest the leading paragraph be more similar to that of Section 9,
> instead of:
> 

I think that says effectively the same thing.

> Barry's advice on numbering is missing.

Added.

> generator can still produce its data for local debugging or manual

OK.

> was accepted or rejected.

The focus isn't on new messages, it's on SMTP.  If the delivery method isn't SMTP, then the rest of that paragraph doesn't apply because its loop-avoidance technique isn't applicable.

-MSK

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 08 Feb 2012 11:54:39 -0500

In <[email-masked]>, on
02/08/2012

>MUST NOT be sent. One of those likely needs to change (probably 8.1).

I agree. If there's no abuse issue and the sender has not requested
feedback on authentication failure then there's not much point in
sending the feedback. If the e-mail client is sending legitimate mail
that fails validation then the potential volume should be enough to
justify the MUST NOT.

8.5 and 9.2 also have MUST. In the case of 8.5, it does not seem to
satisfy 6. in RFC 2119. In the case of 9.2, I believe that it is
legitimate in order to prevent loops. 

-- 
     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: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Feb 2012 12:26:38 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shmuel Metz
> Sent: Wednesday, February 08, 2012 8:55 AM
> To: [email-masked]

As you cited, Section 6 of RFC2119 says normative keywords "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)".

It seems to me that providing a mechanism to tell a report generator to knock it off certainly does fit within the second part of that admonition.  Think of the extreme case where a report generator is mailbombing some address extracted by heuristics.

The MUST there seems quite appropriate to me.

-MSK

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 08 Feb 2012 16:02:40 -0500

In
<[email-masked]>,
on 02/08/2012
   at 12:26 PM, "Murray S. Kucherawy" <[email-masked]> said:

>It seems to me that providing a mechanism to tell a report generator
>to knock it off certainly does fit within the second part of that
>admonition.  Think of the extreme case where a report generator is
>mailbombing some address extracted by heuristics.

If it's sending only one report per abusive message received and
sending it to the owner of the source IP then it's not mailbombing.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Feb 2012 13:06:46 -0800

> Sent: Wednesday, February 08, 2012 1:03 PM
> To: [email-masked]
> >It seems to me that providing a mechanism to tell a report generator to
> >knock it off certainly does fit within the second part of that

If the reports are for some reason inactionable, then we're already saying elsewhere that they shouldn't be sent in the first place.

---

From: "John Levine" <[email-masked]>
Date: 8 Feb 2012 23:11:29 -0000

>sending it to the owner of the source IP then it's not mailbombing. 

If the heuristic guessed wrong and it's some poor schnook getting a
mountain of someone else's abuse reports, it most definitely is.  No
source of contact information is infallible.

For the N+1'th time, standards can't make people do anything they're
not inclined to do.  Forcing abuse reports on people who don't want
them will not make the abuse stop, nor accomplish anything else
useful.

R's,
John

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 08 Feb 2012 21:45:52 -0500

In
<[email-masked]>,
on 02/08/2012
   at 01:06 PM, "Murray S. Kucherawy" <[email-masked]> said:

>If the reports are for some reason inactionable, then we're already
>saying elsewhere that they shouldn't be sent in the first place.

Indeed; SHOULD NOT. The question is whether there is a case for MUST
NOT.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Feb 2012 23:02:33 -0500

On Wednesday, February 08, 2012 01:06:46 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Shmuel Metz Sent: Wednesday, February 08, 2012 1:03 PM
> > To: [email-masked]
> > >to
> If the reports are for some reason inactionable, then we're already saying
> elsewhere that they shouldn't be sent in the first place.

Yes, but it's said in context of content analysis.

If you send me reports because someone spoofed my domain and I've not 
indicated somehow that I want those reports (e.g. what's discussed under auth 
failure reporting) then it's inactionable and MUST not be sent.

I really object to an RFC that's going to legitimize random idiots who don't 
understand that SMTP and address spoofing filling my postmaster inbox with crap 
from random spammers that used my Mail From in their last spam run.

I would propose adding between 8.6 and 8.7:

6.5.  A report generator MUST NOT send abuse reports to the Mail From domain 
if the message has an SPF result other than Pass, None, or Neutral.

This is a special case of an inactionable report that I think is worth calling 
out.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Wed, 8 Feb 2012 20:07:46 -0800

> This is a special case of an inactionable report that I think is worth calling 

I'm not sure it is. It's no different from a report in any other format sent
to abuse@wherever.

Where the problem appears is when someone automates the process.
Those are the people who may be aware of this spec, and those are
the people who'll generate a noticeable volume. It's only those people
developing automation software that most of this is aimed at, and they
are not the ones who need to have SPF explained to them[1].

Cheers,
  Steve

[1] Well, OK, some of them are. But they're not going to pay any
attention anyway. Filter their mail and move on, just like we all have
with certain automated reporters already.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Feb 2012 23:14:19 -0500

On Wednesday, February 08, 2012 08:07:46 PM Steve Atkins wrote:
> > indicated somehow that I want those reports (e.g. what's discussed under
> > auth failure reporting) then it's inactionable and MUST not be sent.
> > 
> > I really object to an RFC that's going to legitimize random idiots who
> > don't understand that SMTP and address spoofing filling my postmaster
> > inbox with crap from random spammers that used my Mail From in their
> > last spam run.
> > 
> > 6.5.  A report generator MUST NOT send abuse reports to the Mail From
> > domain if the message has an SPF result other than Pass, None, or
> > Neutral.
> > 
> > This is a special case of an inactionable report that I think is worth
> > calling out.
> 

That's all true, but I don't think it's not a reason to put it in here.  This 
is the document we're writing on how to do abuse reporting.  If we were 
writing a more global document, I'd want it in that too, but we aren't.  The 
entire document is rife with advice that is also applicable to non-ARF abuse 
reports, so this is no different in that regard.

One of the reasons SPF was created was to reduce the number of bounces people 
received due to spoofed messages.  I feel very strongly we ought to avoid 
recreating that problem.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Feb 2012 23:38:58 -0500

On Tuesday, February 07, 2012 10:42:46 PM Murray S. Kucherawy wrote:
...
> Still in WGLC until Friday.  Have at it.
...

In paragraph 11.2 (forgeries), the last section of it:

   Perhaps the simplest means of mitigating this threat is to assert
   that these reports should themselves be signed with something like
   DKIM.  On the other hand, if there is a problem with the DKIM
   infrastructure at the Verifier, signing DKIM failure reports may
   produce reports that aren't trusted or even accepted by their
   intended recipients.

I think it would useful to mention both SPF and DKIM here as one may offset 
failures in the other (along the lines of what DMARC is doing).  Proposed 
text:

   Perhaps the simplest means of mitigating this threat is to assert
   that these reports should themselves be signed with something like
   DKIM or authorized with SPF.  On the other hand, if there is a problem with
   the DKIM infrastructure at the Verifier, signing DKIM failure reports may
   produce reports that aren't trusted or even accepted by their
   intended recipients.  There may be similar issues with SPF evaluation.  Use
   of both technologies can mitigate this risk to a degree.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Feb 2012 23:42:06 -0500

On Wednesday, February 08, 2012 11:38:58 PM Scott Kitterman wrote:
>    DKIM or authorized with SPF.  On the other hand, if there is a problem
> with the DKIM infrastructure at the Verifier, signing DKIM failure reports
> may produce reports that aren't trusted or even accepted by their
>    intended recipients.  There may be similar issues with SPF evaluation. 
> Use of both technologies can mitigate this risk to a degree.

I should have mentioned that this is consistent with combining the input from 
both the DKIM and SPF drafts into the AS draft.  The SPF draft currently says:

   Perhaps the simplest means of mitigating this threat is to assert that
   these reports should themselves pass SPF checks and/or use other
   email authentication technologies such as DKIM.

I'm currently working on an update to the SPF draft and am assuming you'll do 
something along these lines.  If not, I think I need to put the forgeries 
consideration back into the SPF draft.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Feb 2012 20:59:39 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, February 08, 2012 8:03 PM
> To: [email-masked]

That sounds a little like establishing an SPF requirement on use of ARF.  How about:

If a report generator applies [SPF] to arriving messages, and an arriving message's SPF evaluation produced something other than a Pass, None or Neutral result, a report SHOULD NOT be generated.

...and add similar not-on-failure advice to the DKIM text as well.

?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Feb 2012 21:08:35 -0800

> Sent: Wednesday, February 08, 2012 8:39 PM
> To: [email-masked]
> I think it would useful to mention both SPF and DKIM here as one may
> offset failures in the other (along the lines of what DMARC is doing).
> Proposed text:
> 

Quite right, and what everyone's been espousing in that space for quite a while.  Updated accordingly.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 09 Feb 2012 00:22:56 -0500

On Wednesday, February 08, 2012 08:59:39 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Wednesday, February 08, 2012 8:03 PM
> > To: [email-masked]
> If a report generator applies [SPF] to arriving messages, and an arriving
> message's SPF evaluation produced something other than a Pass, None or
> Neutral result, a report SHOULD NOT be generated.
> 

I'm generally OK with this, but I think it should be MUST NOT vice SHOULD NOT.

In this case you know that sending an ARF to the domain that was spoofed is 
non-actionable.  All it's going to get is return complaints, your mail 
blackholed, or abuse reports against the sending domain.  The reports are 
known pointless and will do only harm.

It's different for auth failure reports where the receiver has said they want 
such reports.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Feb 2012 21:36:14 -0800

> Sent: Wednesday, February 08, 2012 9:23 PM
> To: [email-masked]

I suggested SHOULD NOT because RFC2119 defines that as basically "MUST NOT, unless you've given serious thought to why you're ignoring that advice."

Does that sound any better?

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 09 Feb 2012 00:54:39 -0500

On Wednesday, February 08, 2012 09:36:14 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Wednesday, February 08, 2012 9:23 PM
> > To: [email-masked]
> I suggested SHOULD NOT because RFC2119 defines that as basically "MUST NOT,
> unless you've given serious thought to why you're ignoring that advice."
> 

No.  I've read RFC 2119.

The only case I can think of where I can envision not heeding this advice is 
if you think the senders authentication is broken.  In that case I believe you 
should be looking at how to send auth failure reports.

I think this is a MUST NOT.  All it will lead to is pain.

I will confess it's possible that I'm overly cynical about the ability of 
giving serious thought reliably producing the correct result here, but I 
really think that for whatever corner case that may exist, there's globally 
more harm associated with given people a free pass to think it over.

Scott K

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 09 Feb 2012 11:24:50 -0500

In <8745247.6SOmXc3d5b@scott-latitude-e6320>, on 02/08/2012

>domain  if the message has an SPF result other than Pass, None, or

I'd suggest

6.5.  A report generator SHOULD NOT send abuse reports to the Mail
>From domain unless the domain has been authenticated, e.g., if the
message has an SPF result of Pass, None, or Neutral. Similarly, a
report generator SHOULD NOT send abuse reports to the  header From
domain unless the domain has been authenticated.

I'd support MUST NOT for both if we make a case that "it is actually
required for interoperation or to limit behavior which has potential
for causing harm", as specificed in RFC 2119.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 09 Feb 2012 11:29:10 -0500

In
<[email-masked]>,
on 02/08/2012
   at 08:59 PM, "Murray S. Kucherawy" <[email-masked]> said:

>If a report generator applies [SPF] to arriving messages, and an
>arriving message's SPF evaluation produced something other than a
>Pass, None or Neutral result, a report SHOULD NOT be generated.

I'd rather make it more general and also require authentication for
anything not based on the source IP or a domain resolving to the
source id.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 09 Feb 2012 18:03:16 +0100

On 08/Feb/12 17:56, Steve Atkins wrote:
>> 8.1 talks about sending unsolicited abuse reports.
> 

Mistake?

> s/reports of authentication failures,// is the obvious fix.

The whole snippet quoted above seems to be somewhat misplaced, as
those are all cases of "mechanical reports" that the concluding
sentence of that paragraph discourages.

> I'm not sure what you mean there.

Even if the d= domain is a reasonable candidate, one should stop
sending reports if any of the following is determined to be true:

* abuse@domain is undeliverable,
* nobody acknowledges the reports (paragraph 13), or
* the recipients opt-out (paragraph 5).

> it may not be a reasonable candidate.

Abusive parties (paragraph 14) make another class of unreasonable
candidates.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 09:50:14 -0800

> Scott Kitterman
> Sent: Wednesday, February 08, 2012 9:55 PM
> To: [email-masked]
> The only case I can think of where I can envision not heeding this
> advice is if you think the senders authentication is broken.  In that
> case I believe you should be looking at how to send auth failure
> reports.
> 
> I will confess it's possible that I'm overly cynical about the ability
> of giving serious thought reliably producing the correct result here,
> but I really think that for whatever corner case that may exist,
> there's globally more harm associated with given people a free pass to
> think it over.

If I may paraphrase John Levine, no amount of MUST NOTting will prevent a pinhead from being a pinhead.  In those cases, I prefer to pick RFC2119 words geared toward the competent reader.  That's why I went with SHOULD NOT here.

But I'll go with consensus, also accepting that the IESG might correct us in either direction.  Thus, what do others think?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 09 Feb 2012 18:54:53 +0100

On 09/Feb/12 06:54, Scott Kitterman wrote:
> I will confess it's possible that I'm overly cynical about the
> ability of giving serious thought reliably producing the correct
> result here, but I really think that for whatever corner case that
> may exist, there's globally more harm associated with given people
> a free pass to think it over.

A corner case: an ISP configure SPF according to their own mail
traffic, e.g. "v=spf1 mx:ISP.example ~all".  The ISP don't trust their
customers enough to point WHOIS records directly to their
abuse-mailboxes, but does count-and-forward according to 8.10.  Now,
an ISP's customer sends spam with MAIL FROM:<[email-masked]>.  The
abuse-mailbox resulting from WHOIS lookup of the source address is
[email-masked].  That domain failed SPF authentication and thus,
you say, it cannot be the target of unsolicited complaints.  Why?

As for the whole idea, may I ask why softfail is considered less bad
than neutral?  AFAIK people use them interchangeably when they don't
dare -all.

We are already saying that the domain in MAIL FROM is likely a
reasonable candidate if SPF gave "pass".  Doesn't that already mean
you should not use it if SPF gave any other result?  Why do we need to
add that fail, softfail, temperror, and permerror, in particular, are
not good?

Rather, I'd s/the domain that has been verified/the domain that has
been verified ("pass")/, in case that isn't clear enough.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 10:06:07 -0800

> Sent: Thursday, February 09, 2012 8:25 AM
> To: [email-masked]
> 6.5.  A report generator SHOULD NOT send abuse reports to the Mail From
> domain unless the domain has been authenticated, e.g., if the message
> has an SPF result of Pass, None, or Neutral. Similarly, a report
> generator SHOULD NOT send abuse reports to the  header From domain
> unless the domain has been authenticated.

Neither DKIM nor SPF do anything to authenticate the header From domain.  What other mechanism are you proposing we introduce?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 10:08:21 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Thursday, February 09, 2012 9:50 AM
> To: [email-masked]
> If I may paraphrase John Levine, no amount of MUST NOTting will prevent
> a pinhead from being a pinhead.  In those cases, I prefer to pick
> RFC2119 words geared toward the competent reader.  That's why I went
> with SHOULD NOT here.
> 
> But I'll go with consensus, also accepting that the IESG might correct
> us in either direction.  Thus, what do others think?

Now that I think of it, another compromise would be language like "SHOULD NOT ... unless ..." followed by an explicit example of when we would think it's safe to violate the SHOULD NOT.  That strengthens it without going all the way to a MUST NOT.

Any suggestions?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 10:14:53 -0800

> Sent: Thursday, February 09, 2012 9:03 AM
> To: [email-masked]
> The whole snippet quoted above seems to be somewhat misplaced, as those
> are all cases of "mechanical reports" that the concluding sentence of
> that paragraph discourages.

The methods listed in 8.1 all name things that warrant corrective action.  User submission are active demands for corrective action; mail arriving at spam traps and honeypots are always either from spammers or poorly managed mailing lists, and virus false positives are (as far as I know) few and far between.  What we took out was spam filtering and authentication failures, both of which are far more FP-prone.

> * the recipients opt-out (paragraph 5).

Don't we already cover those cases, then?

> > distinguish reputation streams. That's only one of several reasons it
> > may not be a reasonable candidate.
> 

Added to the end of 8.6: "...,  or the verified domain is a fake and discardable domain created by a bad actor for the purpose of sending abusive mail."

Anything else?

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Thu, 9 Feb 2012 10:29:14 -0800

> Added to the end of 8.6: "...,  or the verified domain is a fake and discardable domain created by a bad actor for the purpose of sending abusive mail."

One common case is where the d= domain is that of the entity owning
the mailing list and generating the content, while outsourcing the
delivery of the mail to an ESP.

In those cases (and it's a very common case) notifying anyone
other than the ESP is probably a waste of time, while notifying the
ESP will be extremely effective.

I'm not sure whether we want to try and teach people what some
decent heuristics are, or just put in enough suggestions to mitigate
the harm done to others if they get it wrong, though.

Cheers,
  Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 09 Feb 2012 19:31:50 +0100

On 08/Feb/12 20:18, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>> *Abstract*
>> 

Sorry, Murray, forget it.  I thought (as said in 8.2) that reporting
is no MUA's business.  Thinking twice, however, it is not bad if MUA
developers have a look at this I-D, even if most methods are not
suitable for them.

> The focus isn't on new messages, it's on SMTP.  If the delivery
> method isn't SMTP, then the rest of that paragraph doesn't apply
> because its loop-avoidance technique isn't applicable.

Well, that focus adds to the confusion, since the preceding sections
only do SMTP.  You are not talking about failed authentication of
non-SMTP messages (doseta), are you?

It is the parenthesized "versus" that drives me astray.  I tend to
understand the beginning of that paragraph as if it were just:

 3.  The envelope sender address of the report needs to be chosen so
     that these reports will not generate mail loops, so as to avoid
     amplification attacks, deliberate or otherwise.

What am I missing?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 10:33:48 -0800

> Sent: Thursday, February 09, 2012 10:29 AM
> One common case is where the d= domain is that of the entity owning the
> mailing list and generating the content, while outsourcing the delivery
> of the mail to an ESP.
> 
> In those cases (and it's a very common case) notifying anyone other
> than the ESP is probably a waste of time, while notifying the ESP will
> be extremely effective.
> 
> I'm not sure whether we want to try and teach people what some decent
> heuristics are, or just put in enough suggestions to mitigate the harm
> done to others if they get it wrong, though.

It seems to me we're starting down the road of cluttering the document with counter-examples if we add this.

Can someone suggest some more generic text here about cases where reporting to the "d=" is a bad idea, hopefully in ways that the report generator can detect?

If not, the two examples we have set the stage nicely, I think.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 10:36:39 -0800

> Sent: Thursday, February 09, 2012 10:32 AM
> To: [email-masked]
> only do SMTP.  You are not talking about failed authentication of non-
> SMTP messages (doseta), are you?
> 

It is a little convoluted, I agree.  How about:

"When sending a new report via SMTP, it is necessary to construct the message so as to avoid amplification attacks, deliberate or otherwise."

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 09 Feb 2012 19:55:58 +0100

On 09/Feb/12 19:36, Murray S. Kucherawy wrote:
> 
> How about:
> 
> "When sending a new report via SMTP, it is necessary to construct
> the message so as to avoid amplification attacks, deliberate or
> otherwise."

Much clearer, thanks.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 9 Feb 2012 11:11:43 -0800

> If not, the two examples we have set the stage nicely, I think.

I think the examples are the problem. The implication they give is that
if the d= domain is a "real" domain, it's a good place to send reports
to.

It's a really minor issue, but I guess I should come up with some
alternate wording.

*** draft-ietf-marf-as-07.txt   2012-02-07 22:38:33.000000000 -0800
--- new.txt     2012-02-09 11:11:01.000000000 -0800
***************
*** 307,317 ****
     6.   Where an abusive message is signed using a domain-level
          authentication technology such as DKIM ([RFC6376]) or SPF
          ([RFC4408]), the domain that has been verified by the
!         authentication mechanism is likely a reasonable candidate for
!         receiving feedback about the message.  However, this is not
!         universally true, since sometimes the domain thus verified
!         exists only to distinguish one stream of mail from another (see
!         Section 2.5 of [RFC6377]), and cannot actually receive email.
     7.   Recipients of unsolicited ARF reports SHOULD, in general, handle
          them the same way as any other abuse reports.  However, they MAY
          take advantage of the standardized parts of the ARF format to
--- 307,318 ----
     6.   Where an abusive message is signed using a domain-level
          authentication technology such as DKIM ([RFC6376]) or SPF
          ([RFC4408]), the domain that has been verified by the
!         authentication mechanism is oftenlikely a reasonable candidate for
!         receiving feedback about the message. For DKIM, though, while
!         the authenticated domain has some responsibility for the mail
!         sent it often will not be a good contact point for abuse issues
!         (for example, it may be the author of the message rather than
!         the sender or it may be a domain that doesn't accept email at all).
     7.   Recipients of unsolicited ARF reports SHOULD, in general, handle
          them the same way as any other abuse reports.  However, they MAY
          take advantage of the standardized parts of the ARF format to

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 11:24:54 -0800

> Sent: Thursday, February 09, 2012 11:12 AM
> [...]

Fine with me, except that I'd also mention the d= could identify the bad actor, in which case reporting the abuse is unlikely to be effective.

Good enough?

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Thu, 9 Feb 2012 11:55:55 -0800

> Fine with me, except that I'd also mention the d= could identify the bad actor, in which case reporting the abuse is unlikely to be effective.

Sure.

Cheers,
  Steve

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 09 Feb 2012 15:08:56 -0600

>you say, it cannot be the target of unsolicited complaints.  Why?

There's no reliable way to distinguish that scenario from regular spoofing, so it's pointless to use to drive design. ISP can police his own network without external help, so it's not a useful distinction in any case.

>than neutral?  AFAIK people use them interchangeably when they don't

SPF is opt-in, so I can't punish none results. The one receiver policy MUST in RFC 4408 is neutral MUST be treated the same as none.  My proposed text is consistent with this. 

>been verified ("pass")/, in case that isn't clear enough.

It's a little more complicated than that and I think the suggested text navigates the complexity correctly.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 09 Feb 2012 15:11:57 -0600

"Murray S. Kucherawy <[email-masked]> wrote:

>Now that I think of it, another compromise would be language like
>"SHOULD NOT ... unless ..." followed by an explicit example of when we
>would think it's safe to violate the SHOULD NOT.  That strengthens it
>without going all the way to a MUST NOT.
>
>Any suggestions?

If I could come up with a useful case for after the unless, I'd be happy with this.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 09 Feb 2012 15:18:16 -0600

"Murray S. Kucherawy" <[email-masked]> wrote:

>the
>Can someone suggest some more generic text here about cases where
>reporting to the "d=" is a bad idea, hopefully in ways that the report
>generator can detect?
>

In Steve's example if i= is explicitly set, it may be a better choice.  I'm not sure though.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 21:31:29 -0800

> Sent: Thursday, February 09, 2012 1:12 PM
> To: [email-masked]

How about:

Similarly, if a report generator applies SPF to arriving messages, and that evaluation produced something other than a "Pass", "None" or "Neutral" result, a report addressed to the RFC5321.MailFrom domain SHOULD NOT be generated as it might be a forgery and thus not actionable.  A valid exception would be specific knowledge that the SPF check is expected to fail for that domain under those circumstances.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 10 Feb 2012 10:56:46 +0100

On 09/Feb/12 22:08, Scott Kitterman wrote:
>> traffic, e.g. "v=spf1 mx:ISP.example ~all".  The ISP don't trust 
>> their customers enough to point WHOIS records directly to their 
>> abuse-mailboxes, but does count-and-forward according to 8.10. An
>> ISP's customer sends spam with MAIL FROM:<[email-masked]>.
> 
> There's no reliable way to distinguish that scenario from regular
> spoofing, so it's pointless to use to drive design.

Except that we'd be providing a recipe for building non-reportable
forgeries.

> ISP can police his own network without external help, so it's not a
> useful distinction in any case.

The amount of support that ISPs may want to give to abuse reporting is
unknown at this time.  Requiring them to proactively policing abusive
use of domain names in outgoing mail is probably not an option, also
because that might interfere with contractual habits (more than
explicit complaints from third parties.)

Advice that abuse-mailboxes shouldn't be spam-filtered is spread
throughout several papers.  That the domain part of abuse-mailboxes
should not be SPF-protected would be a new, somewhat obscure
requirement, that is not going to improve SPF adoption.

>> reasonable candidate if SPF gave "pass".  Doesn't that already
>> mean you should not use it if SPF gave any other result?
> 

We mention how to derive a destination address from

* WHOIS,
* rDNS, and
* "pass" for SPF/DKIM domain.

Any other destination is dicey, and SHOULD NOT be used.  IOW, an
address derived from WHOIS, rDNS, or DKIM does not need to be doubly
checked against SPF none/neutral.  And let me stress this once more:
we are talking _only_ of addresses derived in one of those three ways.

Yes, it is more complicated.  For example, if I get DKIM pass and SPF
fail for the same domain, I should hypothesize a replay attack which
might be better reported as an authentication failure.  But that's
well beyond what this I-D is going to specify/state.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Feb 2012 07:06:45 -0500

>explicit complaints from third parties.)

This would only be relevant for their own domain, some other domain would be a different case. What I suggest isn't nearly so broad as you infer. 

>requirement, that is not going to improve SPF adoption.

I don't agree. I don't see such a requirement. 

>well beyond what this I-D is going to specify/state.

I think the DKIM pass with the same domain is a reasonable case.  I can imagine a rouge ESP scenario where notifying the domain owner is a good idea.

Thanks.

I'll go back and modify my answer to Murray.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Feb 2012 07:15:41 -0500

"Murray S. Kucherawy  <[email-masked]> wrote:

>Similarly, if a report generator applies SPF to arriving messages, and
>that evaluation produced something other than a "Pass", "None" or
>"Neutral" result, a report addressed to the RFC5321.MailFrom domain
>SHOULD NOT be generated as it might be a forgery and thus not
>actionable.  A valid exception would be specific knowledge that the SPF
>check is expected to fail for that domain under those circumstances.

Allesandro provided a scenario that I think is reasonable. If you add:

(i.e. a message with DKIM pass for the same domain)

at the end and change "expected to fail" to "not definitive" I think I'm good.

Scott K

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 09 Feb 2012 16:25:40 -0500

In
<[email-masked]>,
on 02/09/2012
   at 10:06 AM, "Murray S. Kucherawy" <[email-masked]> said:

>Neither DKIM nor SPF do anything to authenticate the header From
>domain.  What other mechanism are you proposing we introduce?

I'm not; I'm proposing that we be neutral on any potential future
authenticatiobn standards. Or is there reason to believe that there
will never be an RFC for signing domain names in the header?

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 10 Feb 2012 16:33:57 +0100

On 10/Feb/12 13:06, Scott Kitterman wrote:
> This would only be relevant for their own domain, some other domain
> would be a different case. What I suggest isn't nearly so broad as
> you infer.
> 
>> That the domain part of abuse-mailboxes should not be
>> SPF-protected would be a new, somewhat obscure requirement, that
>> is not going to improve SPF adoption.
> 

If some leased addresses can get (soft)fail for ISP.example, the ISP
needs to scan outgoing SMTP transactions --if they are not cyphered--
in order to avoid non-reportable cases.  Otherwise a bot-master could
MAIL FROM:<[email-masked]> from those addresses and get
away with it.

(And that assuming that ISPs don't publish abuse-mailboxes for the
sole purpose of keeping admin and technical contacts clear of spam
complaints.)

> I think the DKIM pass with the same domain is a reasonable case.  I
> can imagine a rouge ESP scenario where notifying the domain owner
> is a good idea.

Author's domain should be the preferred reporting path, for example
for newcomers or naive spammers, in order to have them admonished by
their own postmasters.

However, DKIM signatures can break for other reasons.  In that case, a
broken signature gives no hints about deriving the same reporting
target from some other heuristics.

> I'll go back and modify my answer to Murray.

I hope he won't get down to convoluted scenarios.  Examples belong to
appendixes, and one or few actual cases would be clearer than lengthy
discussions, IMHO.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Feb 2012 10:43:25 -0500

On Friday, February 10, 2012 04:33:57 PM Alessandro Vesely wrote:
...
...

I think you are mixing things together that are separate.

I do think it's up to a network owner (such as an ISP) to police their IP 
space.  If they don't want mail using their domain name to be sent out of 
their network except through their official MTAs, they can prevent that easily 
enough.

The problem though is it's difficult to reliable separate this case from generic 
SPF non-pass conditions, so I don't think we should create a space for an 
unreliable solution to a problem that network operators can solve on their own 
if they care to.

None of this has any impact on the SPF status of the postmaster inbox.  The 
message we are discussing here that didn't pass SPF was the original one 
believed to be abusive.  That's got no bearing on the SPF status of any report 
to postmaster@.  That's completely separate.

I can see having an discussion about should postmaster addresses filter/reject 
based on SPF, but I don't think anything we are doing in the MARF group has 
any impact on the answer to that question.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 Feb 2012 09:21:51 -0800

> Sent: Thursday, February 09, 2012 1:26 PM
> To: [email-masked]

S/MIME and PGP also allow you to sign the From: field of a message, but they make no statement about whether what got signed is true or not.

DKIM and SPF confirm that the use of the domain was effectively authorized.  DKIM, S/MIME and PGP confirm that the domain wasn't changed post-signing.  None of them make any statement about whether or not the domain itself is valid in context, true, or anything else.

I can't conceive of an Internet-based technology that can confirm intent or legitimacy of the signer/author/whatever.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 Feb 2012 09:30:39 -0800

> Sent: Friday, February 10, 2012 1:57 AM
> To: [email-masked]

That's true, but I don't think it's something MARF needs to consider.  These are really operational choices that have nothing to do (directly) with ARF generation or acceptance.  Or am I missing something?

> requirement, that is not going to improve SPF adoption.

If you're proposing a text change about whether or not email addresses that lead to abuse inboxes SHOULD NOT be spam-filtered, I've lost track of it.  Can you point me to it?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 Feb 2012 09:33:53 -0800

> Sent: Friday, February 10, 2012 4:16 AM
> To: [email-masked]

Slightly different, and assuming I got your proposal right:

Similarly, if a report generator applies SPF to arriving messages, and that evaluation produced something other than a "Pass", "None" or "Neutral" result, a report addressed to the RFC5321.MailFrom domain SHOULD NOT be generated as it might be a forgery and thus not actionable.  A valid exception would be specific knowledge that the SPF result is not definitive for that domain under those circumstances (e.g., a message that is also DKIM-signed by the same domain, and that signature validates).

That work?

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Fri, 10 Feb 2012 09:42:43 -0800

> Similarly, if a report generator applies SPF to arriving messages, and that evaluation produced something other than a "Pass", "None" or "Neutral" result, a report addressed to the RFC5321.MailFrom…

We're imposing an awful lot of detailed micromanagement on an application developer that's probably making assumptions about the heuristics they chose for their app that aren't generally applicable, and generally discussing detailed implementation decisions about something we're not developing (and, mostly, have little experience developing).

Can we just say what we'd like the end result to be, and leave it to the developer to make the choices needed to get there?

Cheers,
  Steve

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Feb 2012 13:09:32 -0500

On Friday, February 10, 2012 09:33:53 AM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Friday, February 10, 2012 4:16 AM
> > To: [email-masked]
> Similarly, if a report generator applies SPF to arriving messages, and that
> evaluation produced something other than a "Pass", "None" or "Neutral"
> result, a report addressed to the RFC5321.MailFrom domain SHOULD NOT be
> generated as it might be a forgery and thus not actionable.  A valid
> exception would be specific knowledge that the SPF result is not definitive
> for that domain under those circumstances (e.g., a message that is also
> DKIM-signed by the same domain, and that signature validates).
> 
> That work?

might be a forgery/probably is a forgery

e.g./i.e.

and I'm happy.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 Feb 2012 10:13:43 -0800

> Sent: Friday, February 10, 2012 9:43 AM
> We're imposing an awful lot of detailed micromanagement on an
> application developer that's probably making assumptions about the
> heuristics they chose for their app that aren't generally applicable,
> and generally discussing detailed implementation decisions about
> something we're not developing (and, mostly, have little experience
> developing).
> 
> Can we just say what we'd like the end result to be, and leave it to
> the developer to make the choices needed to get there?

You must've expected this:

Can you suggest specific changes?

I can handle "Strike 8.x", but I'd like some actual text for the "say what we'd like the end result to be" part.

I'll post what we have now in a moment and you can use that to hack away.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Fri, 10 Feb 2012 10:15:55 -0800

> Can you suggest specific changes?

Sure did. I'm already working on them, but I thought I'd give the general idea
a chance to be shot down as well.

Cheers,
  Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 10 Feb 2012 20:26:49 +0100

> I think you are mixing things together that are separate.

Sorry, I thought I depicted the case clearly...

> their network except through their official MTAs, they can prevent that easily 

No. ISP.example is a network provider, like softlayer.com leasing
208.43.65.50 to controlledmail.com.  MAIL FROM:<[email-masked]>
sent from 208.43.65.50 (mailout03.controlledmail.com) would get a
softfail, if I'm not mistaken.  Where should it be reported, if
abusive?  ABUSE1025-ARIN tells [email-masked], but one cannot use
it as target because of the softfail.

> unreliable solution to a problem that network operators can solve on their own 

Agreed, but the more difficult the solution, the less likely they'll
be to take care.  We could say that, given their SPF record, their
abuse POC should have been [email-masked], but...

> believed to be abusive.

Yes

> That's got no bearing on the SPF status of any report to
> postmaster@.  That's completely separate.

It /was/ completely separated.  Since -08 it triggers a SHOULD NOT.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Feb 2012 14:59:54 -0500

On Friday, February 10, 2012 08:26:49 PM Alessandro Vesely wrote:
> > their network except through their official MTAs, they can prevent that
> > easily enough.
> 

I think I haven't been clear (and maybe the text needs more work), but this is 
reasonable.  Where I would object is if you wanted to send the report to 
[email-masked] because they were used in mail from.

> > The problem though is it's difficult to reliable separate this case from
> > generic SPF non-pass conditions, so I don't think we should create a
> > space for an unreliable solution to a problem that network operators
> > can solve on their own if they care to.
> 

This is where I think you've confused things.  The relevant SPF check here 
would be on the domain you are sending the report from.  It's got nothing to 
do with their SPF record or status of messages sent mail from their domain.

> > None of this has any impact on the SPF status of the postmaster inbox. 
> > The message we are discussing here that didn't pass SPF was the
> > original one believed to be abusive.
> 
> Yes
> 

No it doesn't.  Even if it does, it's got nothing to do with if SPF not-pass 
messages are accepted by their postmaster.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 11 Feb 2012 10:30:51 +0100

On 10/Feb/12 20:59, Scott Kitterman wrote:
>> ISP.example is a network provider, like softlayer.com leasing
> I think I haven't been clear (and maybe the text needs more work),
> but this is reasonable.  Where I would object is if you wanted to
> send the report to [email-masked] because they were used in
> mail from.

Yes, the current wording can be interpreted badly.  8.5 says report
generators can derive an address from RFC5321.MailFrom if they have
spf=pass.  8.6 says they can do so even with none or neutral.

>> We could say that, given their SPF record, their abuse POC should
>> have been [email-masked], but...
> 
> This is where I think you've confused things.  The relevant SPF
> check here would be on the domain you are sending the report from.
> It's got nothing to do with their SPF record or status of messages
> sent mail from their domain.

The subdomain would be needed to allow report generators to use that
address even if its domain-part is the same of the RFC5321.MailFrom.
Non-spf-protected.softlayer.com must result in spf=none, in the
original message, hence can be used to report it.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sat, 11 Feb 2012 19:38:56 -0500

In
<[email-masked]>,
on 02/10/2012
   at 09:21 AM, "Murray S. Kucherawy" <[email-masked]> said:

>S/MIME and PGP also allow you to sign the From: field of a message,
>but they make no statement about whether what got signed is true or
>not.

By "authenticate" and "sign" I was refering to authentication of
permission, not to authenticating that the message had not been
altered.

>I can't conceive of an Internet-based technology that can confirm
>intent or legitimacy of the signer/author/whatever.

How about a public key in a TXT RR?

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sat, 11 Feb 2012 19:54:29 -0500

In <4961976.nBIT92DZ3y@scott-latitude-e6320>, on 02/10/2012

>e.g./i.e.

e.g. is correct; it's an example, not an explanation.

---

From: "Bank Security" <[email-masked]>
Date: 12 Feb 2012 01:28:19 -0000

>How about a public key in a TXT RR?

OK, what's the intent and legitimacy of this message?  The DKIM
signature should be 100% valid.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 11 Feb 2012 22:03:58 -0500

>e.g. is correct; it's an example, not an explanation.

I think it's a complete list. What would you add to make it complete?

Scott K

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 12 Feb 2012 11:11:29 -0500

In <[email-masked]>, on 02/12/2012
   at 01:28 AM, "Bank Security" <[email-masked]> said:

>To: [email-masked]
>Cc: [email-masked]

Please don't do that; one copy is sufficient.

>OK, what's the intent and legitimacy of this message?

How is that relevant? The only TXT RR for banqofamerika.com is the SPF
RR. What I was saying was that a technolgy was feasible whereby, e.g.,
the Return-Path, the From address, was encrypted with a private key
and the public key was available in a TXT[1] RR.

[1] A different type of RR would work as well.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 12 Feb 2012 11:16:07 -0500

> I think it's a complete list. What would you add to make it complete?

1. Opinion: We can't predict the future, or what situations others may find
themselves in, so it's a bad idea to make an absolute pronouncement here.

2. Chair evaluation: You are in the rough on this one; you are the only one
who wants this to be written as an exhaustive list.  Let's move on.

3. Because many people don't properly use or understand the distinction
between "i.e." and "e.g.", I think it's better (and easy enough) to avoid
them.  Murray, please consider changing to "for example", "such as", or
some similar English replacement.

Barry, chair-ish

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 12 Feb 2012 11:39:36 -0500

> who wants this to be written as an exhaustive list.  Let's move on.

Fair enough.  Moving on ...

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 12 Feb 2012 08:45:40 -0800

Done.  (If I could figure out how to make Outlook not top-post, I would; apologies.)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Sunday, February 12, 2012 8:16 AM
To: Scott Kitterman
Cc: Message Abuse Report Format working group
Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt

> I think it's a complete list. What would you add to make it complete?

1. Opinion: We can't predict the future, or what situations others may find themselves in, so it's a bad idea to make an absolute pronouncement here.

2. Chair evaluation: You are in the rough on this one; you are the only one who wants this to be written as an exhaustive list.  Let's move on.

3. Because many people don't properly use or understand the distinction between "i.e." and "e.g.", I think it's better (and easy enough) to avoid them.  Murray, please consider changing to "for example", "such as", or some similar English replacement.

Barry, chair-ish

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 12 Feb 2012 08:53:24 -0800

> Sent: Sunday, February 12, 2012 8:11 AM
> Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-
> marf-as-07.txt
> 
> How is that relevant?

Despite DKIM passing on a message for any given domain, you don't know whether or not that domain name represents the entity claimed in the message header or body.  The legitimacy, therefore, cannot be established even by cryptographic means.

> The only TXT RR for banqofamerika.com is the SPF
> the Return-Path, the From address, was encrypted with a private key and
> the public key was available in a TXT[1] RR.

Doing so would also tell you nothing about the legitimacy of the content.

In any case, if we were to speculate on any possible future authentication technology, this document will suffer more bloat than it already has.

-MSK

---

From: "Bank Security" <[email-masked]>
Date: 12 Feb 2012 18:02:58 -0000

>Please don't do that; one copy is sufficient.

Sigh.

>RR.

Sigh++.  If you'd looked at the message you were complaining about,
you'd have seen a valid DKIM signature with d=banqofamerika.com.  You
can't tell whether that's a phish or a joke without external knowledge
about the domain.

As Murray says, speculation about the design of reputation systems or
of other kinds of authentication are utterly out of scope here.

R's,
John

PS: Any replies to this message MUST be sent to both the list and me.
If you do anything else, that's so wrong as to be unworthy even of
discussion.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 12 Feb 2012 11:51:32 -0500

In <[email-masked]>, on
02/11/2012
   at 10:03 PM, Scott Kitterman <[email-masked]> said:

>I think it's a complete list.

At the moment. Will it remain a complete list for the life of the RFC?
If not, then it should be "e.g.,".

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 12 Feb 2012 15:15:41 -0500

In
<[email-masked]>,
on 02/12/2012
   at 08:53 AM, "Murray S. Kucherawy" <[email-masked]> said:

>Despite DKIM passing on a message for any given domain, you don't
>know whether or not that domain name represents the entity claimed in
>the message header or body.

How is DKIM relevant to potential future standards?  The statement was
"I can't conceive of an Internet-based technology that can confirm
intent or legitimacy of the signer/author/whatever.", not "I can't
conceive of a DKIM-based technology that can confirm intent or
legitimacy of the signer/author/whatever."

>In any case, if we were to speculate on any possible future
>authentication technology, this document will suffer more bloat than
>it already has.

I was suggesting that we shorten it rather than lengthen it, by making
a general statement rather than listing specific technologies.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 12 Feb 2012 15:24:30 -0500

In <[email-masked]>, on 02/12/2012
   at 06:02 PM, "Bank Security" <[email-masked]> said:

>you'd have seen a valid DKIM signature with d=banqofamerika.com.

Indeed, but neither DKIM nor SPF is relevant.

>You
can't tell whether that's a phish or a joke 

That's because DKIM doesn't provide for the functionality, not because
it can't be done.

>without external knowledge about the domain.

A TXT RR containing a public key would be external knowledge of the
domain.

>As Murray says, speculation about the design of reputation systems
>or of other kinds of authentication are utterly out of scope here.

Then we should be neutral with regard to future technology, not
preclude it.

>PS: Any replies to this message MUST be sent to both the list and

Then why isn't there a ReplyTo header field?

---

From: "BANK SECURITY" <[email-masked]>
Date: 12 Feb 2012 15:54:01 -0500

> A TXT RR containing a public key would be external knowledge of the

Sorry, that makes no sense at all.  Every DKIM verification record is a 
TXT record containing a public key.

The basic fact is that there is nothing I can say to improve my reputation 
unless it's confirmed by someone that the reputation user finds credible. 
So I can publish text records to prove that something is from me, but not 
to prove that I'm nice.

R's,
John

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 13 Feb 2012 13:04:57 -0500

In <[email-masked]>, on 02/12/2012
   at 03:54 PM, "BANK SECURITY" <[email-masked]> said:

>Sorry, that makes no sense at all.  Every DKIM verification record is
>a TXT record containing a public key.

We seem to be talking at cross purposes. I'm not saying that DKIM or
SPF infrastructure can be used for the purpose, I'm saying that it is
possible to define and deploy a means of authenticating addresses in
the header.

>The basic fact is that there is nothing I can say to improve my

I'm not addressing reputation. Verifying that the sender is authorized
to use a domain name in no way implies that he is legitimate. In fact,
spammers were early adopters of SPF, as you know.

>So I can publish text records to prove that something is from me,
>but not to prove that I'm nice.

I was addressing authentication, not reputation.

---

From: "Bank Security" <[email-masked]>
Date: 13 Feb 2012 21:36:56 -0000

>I was addressing authentication, not reputation.

This makes no sense at all.  DKIM and SPF do authentication right now.
If for some reason you want authentication of the From: line, you know
where to find Sender-ID or DMARC.

>How about a public key in a TXT RR?

You can tell that the From: line is tied to a DNS entry, but you can't
tell from that DNS entry whether the sender is the person who he
claims to be, or whether his intent is to phish you or tell you that
your bank account really is overdrawn.

This argument has been beaten to death N times, no need for another round.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 13 Feb 2012 13:50:19 -0800

I just scanned this sub-thread.  It appears to be one that started badly and got 
worse.  From what I can see, there's little change that trend will change.

I guess I should also note that I don't see it's relevance to marf.

d/

On 2/13/2012 1:36 PM, Bank Security wrote:
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf
>

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 13 Feb 2012 22:18:10 -0500

In <[email-masked]>, on 02/13/2012
   at 09:36 PM, "Bank Security" <[email-masked]> said:

>This makes no sense at all.  DKIM and SPF do authentication right
>now. If for some reason you want authentication of the From: line,
>you know where to find Sender-ID or DMARC.

That's tied to the IP address.

>You can tell that the From: line is tied to a DNS entry, but you
>can't tell from that DNS entry whether the sender is the person who
>he claims to be, or whether his intent is to phish you or tell you
>that your bank account really is overdrawn.

We're still talking at cross purposes. I'm talking about the
posibility of the sender providing a field that contains text
encrypted with a private key and the receiver attempting to decrypt it
using a public key. I'm not addressing the issue of associating the
sender with an organization, just with his right to use the domain in
the header.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Feb 2012 09:26:52 -0800

> Sent: Monday, February 13, 2012 7:18 PM
> To: [email-masked]
> Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.txt
> 
> We're still talking at cross purposes. I'm talking about the posibility
> of the sender providing a field that contains text encrypted with a
> private key and the receiver attempting to decrypt it using a public
> key. I'm not addressing the issue of associating the sender with an
> organization, just with his right to use the domain in the header.

I believe this is off-topic for MARF.  Please don't reply to this thread unless you have an argument to make that it's germane to one of the documents under development.

-MSK, as co-chair

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 15 Feb 2012 12:10:10 -0500

In
<[email-masked]>,
on 02/14/2012
   at 09:26 AM, "Murray S. Kucherawy" <[email-masked]> said:

>I believe this is off-topic for MARF.  Please don't reply to this
>thread unless you have an argument to make that it's germane to one
>of the documents under development.

The context for this is that I wanted the language to be general
rather than limited to specific protocols. From Message-Id:
<[email-masked]>

"I'd rather make it more general and also require authentication for
anything not based on the source IP or a domain resolving to the
source id." The intent is that the AS not automatically become
obsolete should the IETF ever publish a new authentication protocol.