Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

[Douglas Foster <[e-mail]>]

This is essentially a form of greylisting.  I was deliberately proposing to
not track repeats, to avoid the problems that greylisting encounters from
source domains with many servers.   Since greylisting is common, I did not
expect pushback on the propriety of the approach.  What codes are currently
used by systems that implement greylisting?

Changing the PCT disposition from Reject to Defer causes a dramatic change
in my perception of the algorithm.  I am as much enthused about this
approach as I was resistant to the old one.

I thought the DMARC implementation consulants and mailing list operators
would be equally intrigued, so I have been surprised by the silence this
week.

I can envision some domain owners going to PCT=99 and stoping there
permanently.  As an evaluator, I would rather have that than p=None

Doug

On Sat, Aug 7, 2021, 1:51 AM Murray S. Kucherawy <[e-mail]>
wrote:

> On Thu, Aug 5, 2021 at 4:22 AM Douglas Foster <
> [e-mail]> wrote:
>
>> PCT could work IF evaluators are willing and able to send a Temporary
>> Error result (probably 451), instead of a permanent error, when
>> - a DMARC verification fails,
>> - the message is not unconditionally blocked or accepted on other
>> criteria, and
>> - the sender's PCT is between 1 and 99.
>> The result should include an extended status code in the 4.7.2x range.
>>
>> This approach assumes that the temporary error status will cause the
>> sender to retry multiple times over an extended period.
>>
>
> It should, since that's what the standard says ought to happen.  But then,
> as was observed elsewhere in this thread, not all clients behave that way.
>
> Based on observed configurations, this probably works out to at least 10
>> attempts.  In most cases, the PCT formula will cause the message to be
>> accepted after a delay, which is a result equivalent to PCT=0.
>>
>
> We usually use 4yz SMTP reply codes to mean there's some transient
> condition preventing delivery; a later retry may yield a different result.
> Random chance seems an awkward thing to shoe-horn into the notion of
> "transient condition".
>
> I think this could also DMARC skew statistics, as now any given message
> could result in multiple distinct delivery attempts over a period usually
> measured in days.  Care would have to be taken to identify and aggregate
> the ones representing the same message.
>
> -MSK
>