Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07

[Alessandro Vesely <[e-mail]>]

On 01/Feb/12 19:41, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>>>> 8.5. *Automatic Generation*
>>>
>>> What this section is trying to say is that people should not implement
>>> systems that do this kind of reporting work by default.
>>
>> (I understand "reporting of message authentication failures in an
>> on-demand fashion" as I-set-record=you-send-report.)
> 
> I don't agree.  The I-D is meant to present the mechanisms for
> requesting and providing these reports.  That is, "If you're going
> to do this, here's how we think you should go about it."  There are
> some obvious concerns with doing so across-the-board without any
> checking or thought to it, though one certainly could do that.

What's that "could"?!  There's nothing I can conceivably do besides
setting the RR properly.  If that is not enough for getting reports
from whoever will happen to get a broken signature, then this I-D is
completely useless --I can well receive occasional failure notices
from friends based on authfailure-report only.

Differently from abuse reports, authentication failures may affect
personal messages and confidential content.  Concern over divulging
that is due.  If I were to report to unknown people, I would probably
want to redact most header fields and omit the body.

> It seems very appropriate to me to call that out in Security 
> Considerations.

Yes.

>> This I-D is not specifying blind-to- witting transitions, and I'm
>> not suggesting it should, but maybe it can still suggest some
>> details of such activity.
> 
> I think to do so we would wander into the realm of speculation, not
> specification.

Let me describe a possible case, just to make sure we're talking about
the same thing:

Alice writes to Bob, DKIM-Signature breaks, ISP-B (Bob's ISP) start
reporting to ISP-A.  ISP-A receive the first reports, check that they
are good and confirm, possibly on
http://postmaster.ISP-B.example/acknowledge?key=ISP-A_beenhere, that
they would like to continue receiving them.  That doesn't lower the
amount of redaction applied to reports.  Yet, ISP-A can collect
reports and form a statistic picture of how their configuration goes.
 Useful work already, isn't it?

After some months, ISP-A write to ISP-B to arrange for a debugging
session:

   Hi ISP-B,

    I have some statistical evidence that messages from our user Alice
   to your user Bob tend to break much more often than normal.  Would
   it be possible to check that more closely?  Alice says she can
   resend the messages listed below (see attachment).  Bob agrees, but
   please check his consent for your records.

   Regards
    ISP-A
   ---
   (attachment omitted)

ISP-B answer affirmatively and manually forward unredacted reports of
the relevant failures to ISP-A.  ISP-A find the bug and they lived
happily ever after.

> I don't think that's a good idea for something that's asking for
> Proposed Standard status as a protocol document.

The idea is just to note that there are data items about ISP-A, such
as acknowledgment, contacts, responsiveness, and involvement, that is
worth being stored on a per-domain database.  We don't need to say
that such data may turn out to be useful for looking into spam
(reporting) issues, as that is indeed speculation.

>>>> 8.6. *Reporting Multiple Incidents*
>>>>
>>>> To suspend report generation for some time after an RCPT rejection of
>>>> the reporting address
>>>
>>> It's just a suggestion for handling large volumes of reports.
>> 
>> Yes, such specification should belong to some other I-D (reporting-
>> discovery? :-)
> 
> If we're going to talk about handling of large report volumes,
> given our current document set, the AS is the right place to do it.
> If you think that's important, now's the time to make such a
> proposal, before WGLC closes.

Both dkim-reporting and spf-reporting have a section on "Envelope
Sender Selection".  Reporting-discovery would need one too.  The
question of flow control (see below) is a related problem, also common
to all those specs.  I agree it is good to factor them.

Are you saying the AS is the right place for both flow control and
loop avoidance?

What do everybody else think?

>> While [temporary failure] may be semantically correct, there is
>> the practical problem that 4xx reply codes are not reported
>> timely.  It is necessary to query the mail queue in order to know
>> whether there are outstanding temporary failures.  In case the
>> boundary box where the report generator lives does not send mail
>> out directly, it is not practical to determine that condition.
>> 
>> On the other hand, 5xx reply codes should cause the current
>> message to be discarded.  On resuming reporting, new reports are
>> transmitted, rather than the queued flood initiators.  However,
>> in order to ensure immediate notification of rejections in all
>> cases, one would have to use purposely configured variable
>> envelope senders.
>> 
>> What do you think?
> 
> I think if the advice that's been added about observing the
> behavior of the report recipient as input to a throttling mechanism
> is actually impractical, we should remove it rather than expanding
> on it and complicating the document further.  We risk confusing the
> reader.

Hm...  I don't think that a non-empty envelope sender may cause
reporting loops, as reporting does not actually use it.  Hence, we
could use it for flow control.

For some unsorted details, we may recommend 552 after RCPT for
momentarily stop reporting, but had better not rely on it.  Rather, I
propose we encourage getting acknowledgments and recording them along
with per-domain reporting history.  Report generators should use VERP,
and suspend reporting to rejecting domains for an amount of time
inversely proportional to the confidence, e.g.:

  0.5T      for an acknowledged domain,
  T         for a first-time first-failure,
  2T,
  4T,
  ... ,
  one year  for dorks.

where T is the TTL of the relevant _report's RR if retrieved with the
AA flag, or some other time constant either agreed with the domain or
set by default.