Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.txt

From: [email-masked]
Date: Tue, 28 Jun 2011 15:04:09 -0700

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           : Authentication Failure Reporting using the Abuse Report Format
	Author(s)       : Hilda L. Fontana
	Filename        : draft-ietf-marf-authfailure-report-00.txt
	Pages           : 19
	Date            : 2011-06-28

   This memo registers an extension report type to ARF to be used for
   reporting forensic information about messages that fail one or more
   message authentication schemes in use by the purported sender of the
   message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-00.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-authfailure-report-00.txt

---

From: Hilda Fontana <[email-masked]>
Date: Tue, 28 Jun 2011 15:10:51 -0700

This is the first draft of the split out document for the ARF reporting.
Please review and let me know how best to improve it.

thanks
H

On Tue, Jun 28, 2011 at 3:04 PM, <[email-masked]> wrote:

> 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.
>
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf
>

-- 
Hilda L Fontana
 VP, Technology
eCert, Inc.
One Market Street, Suite 3600
San Francisco, CA 94105
p: 626.676.8852
f:  415.651.8932

**eCert - Trust the MessageTM
*www.ecertsystems.com* <http://www.ecertsystems.com/>
* *
----------------------------------------

CONFIDENTIALITY NOTICE

The information contained in this e-mail and any attachments is CONFIDENTIAL
and is intended only for the use of the addressee. Any unauthorized use,
disclosure, distribution, dissemination, or copying is strictly prohibited
and may be unlawful. If you are not the intended recipient, you are
prohibited from any further viewing of the e-mail or any attachments or from
making any use of the e-mail or attachments. If you believe you have
received this e-mail in error, please notify us immediately and permanently
delete the e-mail, any attachments, and all copies from any drives or
storage media and destroy any printouts of the e-mail or attachments and any
copies of such printouts. Thank you for your cooperation.

<http://www.ecertsystems.com/>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Jun 2011 18:26:09 -0400

> Please review and let me know how best to improve it.

Paragraph 3.3 ...

spf:  The evaluation of the sending domain's SPF record produced a
      "fail" or "softfail" result.?

Please change to:

spf:  The evaluation of the sending domain's SPF record produced a
      "Fail", "SoftFail", or "PermError" result.

The capitalization is consistent with the way RFC 4408 describes the results.  
This also better aligns this draft with draft-ietf-marf-spf-reporting-00.txt 
(I do have TempError in the draft now, but I'll drop it for -01).

Para 4/6.2 ...

spf-dns will need to be a multiple appearance type as via include mechanisms 
or redirect modifiers multiple records commonly needed to be retrieved to 
determine an SPF result.  It should also be a domain-spec (for the domain for 
which the record was retrieved) and a quoted-string for the actual record.

Scott K

---

From: Hilda Fontana <[email-masked]>
Date: Tue, 28 Jun 2011 15:57:37 -0700

thank you Scott I will update

CONFIDENTIALITY NOTICE

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 29 Jun 2011 16:25:31 +0200

On 29/Jun/11 00:10, Hilda Fontana wrote:
> This is the first draft of the split out document for the ARF
> reporting.  Please review and let me know how best to improve it.

I have a bunch of comments.  I just place them below and apologize for
a lengthy message.  Please trim and edit the subject appropriately if
replying inline about just a few topics.

* Section 1.  Introduction

I suggest to grab the final paragraph and the "RFCxxxx" list from
Murray's Introduction in dkim-reporting.

* Section 3.1.  Authentication-Results:

Why should one include results "for both DKIM and SPF even if those
tests were not actually performed"?  [AUTH-RESULTS] does not provide
for adding result information for a test that was not performed.  For
example, "dkim=none" means the message had no signature.  To indicate
that no authentication was performed one may just write "none", but
then that's not for either DKIM or SPF.

Why should one copy A-R fields from the reported message?  The
original fields are still available in the message/rfc822 part of the
report.  It may be interesting to know which one(s) triggered the
report generation.  The Auth-Failure field just tells its type.  The
original message may contain multiple A-R fields by multiple
authentication servers.  We can assume that the triggering A-R field
is the topmost one of the given type.  The Reporting-MTA won't
necessarily match the authserv-id of any A-R field, because [ARF]
defines Reporting-MTA as optional and does not provide it with such
semantics.  We may invent a new "Verifying-MTA", say, for matching
purposes.  But is this worth?

IMHO, the simplest specification is that the feedback-report part
contains just the triggering A-Rs, whether or not they are also
present in the message/rfc822 part of the report.

* Section 3.2.  New ARF header fields

The first paragraph says they are "extensions to Section 6.2 of
[ARF]", which I couldn't find.  I'd mention Section 3.1 of [ARF]
instead, and quote that such fields "MUST appear exactly once".

* Sections 3.2.1 and 3.3.  Failure types.

How about defining Auth-Failure as "method/token"?  The method would
have to be a registered authentication method[*], the token could be
either the result (e.g. "fail") or a keyword defined by the specific
ARF extension document (e.g. "revoked").
[*] http://www.iana.org/assignments/email-auth/email-auth.xml

People would be unable to report an "iprev" failure, if they wanted
to, because there is no ARF extension for that.  If one writes such an
extension, it will have to work without requiring this I-D to be
modified, won't it?  In this case, Section 3.3 should just specify the
field semantics, i.e. its last paragraph.  It would also be worth to
introduce a new section describing the minimal template that a
specific ARF extension should instantiate to register itself, if going
for this pattern.

Anyway, the I-D references Section 3.3 implicitly from Section 3.2.1
("The list of valid values is enumerated below") and Section 4 ("as
specified elsewhere in this memo").  An xref would be useful.

DNS errors on retrieving a RR have a different effect for DKIM than
for SPF.  The inability to retrieve a (valid) DKIM key deserves its
own failure type.

For a minor issue, the "Auth-Failure" field bears the same name as
this Feedback-Type field's value.  This is probably bound to generate
confusion when one mentions such phrase with the wrong capitalization.

* Section 3.2.2.  Required For DKIM Reports

People involved in reporting spf (or iprev) will not interested in
this section.  IMHO, it would be better to just mention that each
type-specific ARF extension may define further fields, and move these
definitions to dkim-reporting.

Anyway, the list misses the DKIM-Canonicalized-Body.  I wouldn't
suggest that such field be required, as it is unneeded if the failure
can be located anywhere else, e.g. reporting bad public key syntax.

* Section 7.2.  Forgeries.

We should state that reports should not be recursively generated
against authentication failures for auth-failure reports.  Possibly,
empty envelope sender addresses should inhibit report generation too.

* Section 7.5.  Reporting Multiple Incidents

I don't think this topic belongs to Security Considerations, although
part of it does.  IMHO, the main issue is to define the semantics of
the Requested Report Interval (ri).  Each type-specific ARF extension
can then reuse it, and limit itself to defining ri's emplacement.

I like very much the idea of exponentially growing intervals for
groups of nearly-identical failure reasons.  Perhaps, such interval
type could be indicated by adding a suffix, e.g. "ri=10e"?  (BTW,
"inverse-exponential" means logarithmic to calculus-oriented readers,
which is probably not what we want to mean.)

Apps might have problems complying with such specification.  For
example, setting up a semaphore for permanent storage of per-type
failure counts may imply a whole bunch of requirements that an
implementation is not prepared or willing to take.  What should it do
then, send all or none of them?  If we want to allow customizing
downgraded behavior we can use yet another suffix, e.g. "ri=10e+" to
send all reports in case the reporter app is unable to properly manage
exponential Report Intervals.  Alternatively, we can specify what
downgraded behavior is implied.

* Section B.1.

The Auth-Failure: field is missing in feedback-report.

A DKIM-Signature by example.com is missing in the header.  We don't
require reports to be DKIM-signed, but by signing the example we can
express our preference (somewhere between MAY and SHOULD, I'd guess.)

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 29 Jun 2011 19:23:47 -0700

On Jun 28, 2011, at 3:10 PM, Hilda Fontana wrote:

> This is the first draft of the split out document for the ARF reporting.  Please review and let me know how best to improve it.

If Delivery-Result: is required, then I expect we'll see a lot (perhaps a majority) of implementations being intentionally non-standard and omitting it anyway.  Mailbox providers tend to be /very/ touchy about who they'll share exact delivery results with, and for good reason: the bad guys have lots of incentives to try to trick their way into delivery feedback results that they can use to tune their spamming systems.

I'd urge making that an optional field, or possibly include a null/refused value.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Jun 2011 21:44:27 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Wednesday, June 29, 2011 7:24 PM
> To: Message Abuse Report Format working group
> Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.txt
> 
> If Delivery-Result: is required, then I expect we'll see a lot (perhaps
> a majority) of implementations being intentionally non-standard and
> omitting it anyway.  Mailbox providers tend to be /very/ touchy about
> who they'll share exact delivery results with, and for good reason: the
> bad guys have lots of incentives to try to trick their way into
> delivery feedback results that they can use to tune their spamming
> systems.
> 

Just to be clear, you mean that in the context of auth-failure reports specifically, and not ARF in general?

I'm thinking if you're willing to update your feedback generation system to support auth-failure reports, then you understand what's involved and would be willing to do this as well.  But I don't run an FBL myself (yet) so I admit this is speculation.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 30 Jun 2011 09:53:22 -0700

> Just to be clear, you mean that in the context of auth-failure reports specifically, and not ARF in general?

I was only thinking about the auth-results context for now, but I'd imagine I'll make a similar point for /any/ ARF extension that tries to convey the results of a post-receipt (after 250) spam filtering module.  This is from experience, not philosophy.

> I'm thinking if you're willing to update your feedback generation system to support auth-failure reports, then you understand what's involved and would be willing to do this as well.  But I don't r…

Getting into philosophy now, I think that conflating authentication results with inbox/spam folder placement is a layer violation.

---

From: Hilda Fontana <[email-masked]>
Date: Thu, 30 Jun 2011 10:32:33 -0700

experience shows that most ISPs will indicate delivered or rejected not
indicated what the actual outcome was i.e. inbox or spam - perhaps we could
change the wording to something along those lines

On Wed, Jun 29, 2011 at 7:23 PM, J.D. Falk <[email-masked]>wrote:

> If Delivery-Result: is required, then I expect we'll see a lot (perhaps a
> majority) of implementations being intentionally non-standard and omitting
> it anyway.  Mailbox providers tend to be /very/ touchy about who they'll
> share exact delivery results with, and for good reason: the bad guys have
> lots of incentives to try to trick their way into delivery feedback results
> that they can use to tune their spamming systems.
>

CONFIDENTIALITY NOTICE

---

From: Hilda Fontana <[email-masked]>
Date: Thu, 30 Jun 2011 10:35:50 -0700

> present in the message/rfc822 part of the report.

for automation it would be useful for the headers to be standard - so if
dkim was not checked perhaps dkim="" would be preferable to dkim=none - to
your point above but I think its worth including to try to standardize the
format

> express our preference (somewhere between MAY and SHOULD, I'd guess.)
ok

CONFIDENTIALITY NOTICE

---

From: "John Levine" <[email-masked]>
Date: 1 Jul 2011 02:48:13 -0000

>Please review and let me know how best to improve it.

Well, OK.

>copies of such printouts. Thank you for your cooperation.

Sorry, never mind.

R's,
John