[Subject edited]
On 07/Jul/11 18:44, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: ietf.org On Behalf Of Alessandro Vesely
>>
>> I'd recommend that the discussion of the meaning of r, rf, and ri
>> be factored in the authfailure-report anyway, as it's not yet
>> final and updating it separately in four occurrences would be a
>> nuisance.
>
> It seems to me there could be an authentication method declared
> later that doesn't want to support a reporting format other than
> "arf", or for which a reporting interval doesn't make any sense, so
> I don't think it's useful to make them universally-defined
> properties.
>From a very general point of view, yes, even if I'm unable to imagine
why it would. Those definitions are only relevant to the somewhat
restricted "universe" of email authentication failures, which is
exactly what the draft addresses. Thus, it will make sense to update
it whenever unforeseen requirements arise.
> I don't see the text you're referencing here about exponential
> growth in authfailure-report. Can you point me to it?
Section 7.5:
One might even do something
inverse-exponentially, sending reports for each of the first ten
incidents, then every tenth incident up to 100, then every 100th
incident up to 1000, etc. until some period of relative quiet after
which the limitation resets.
Interesting, isn't it?
> I suppose it would be nice if all of the "ri" definitions had
> identical behavior (and I think they currently do), but I don't see
> a reason to require it.
I makes it easier to write and to read them. To wit, expressing
identical behavior with different wording would be even worse.
On 07/Jul/11 18:57, Scott Kitterman wrote:
> On Thursday, July 07, 2011 12:44:42 PM Murray S. Kucherawy wrote:
> ...
>> Since participation in these extensions is not mandatory, I imagine one
>> electing to honor what "ri" says can't be stateless, by definition.
> ...
> True. I guess the question that ought to be defined is if it's appropriate
> to
> participate in only a subset of the extension? I think it would be
> reasonable
> to say that if you are going to send auth failure FBRs, then you MUST honor
> "ri" if specified. That leaves you two choices:
>
> 1. Don't be stateless.
> 2. Don't submit FBRs for any domain that specifices "ri".
>
> I think participating in the extension, but ignoring the volume knob is not
> OK.
I agree with Scott. However, in some cases ri might be just a
preference (in a previous message I proposed "ri=10e+".) Otherwise, a
stateless reporter could generate a random number and calculate a
given probability. The incident count won't be exact in such cases.
An interval is not exactly the same as a volume knob, as different
domains do different volumes. If one is less interested in an exact
count, it would make more sense to get the first report and then
nothing for the next 99, than completely missing failures that account
for less than 100 occurrences per domain. The exponential approach
solves this issue nicely.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
