> On Apr 1, 2023, at 11:33 AM, Dotzero <dotz...@gmail.com> wrote:
>
>
>
> On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba <barryle...@computer.org
> <mailto:barryle...@computer.org>> wrote:
>> > If we use SHOULD NOT, as you suggest, there's an implication that there
>> > might be a valid reason for
>> > non-transactional mail to use "p=reject". Are we okay with that?
>>
>> When do folks get to line up so they can plead the case for their reason?
>>
>> I, for one, am not. We often use "SHOULD NOT" incorrectly to mean
>> "MUST NOT, but we know it will be widely violated so we're saying
>> SHOULD NOT". We need to stop doing that.
>
> A "standard" which is widely violated is not a standard. To publish a
> standard one knows is and will be widely violated is a bit of a fool's
> errand, n'est-ce pas? We need to stop doing that.
Maybe because DMARC is not a standard. Never was one. It is violated because
it is protocol incomplete. It was not ready for prime time. It’s an
informational status document for reporting. No reporting. No adoption. I
would have a hard time supporting DMARCbis as a standard track item with it
huge email problems and lacking an ATPS concept. (See ADSP)
Any node in the community can completely ignore SPF, DKIM, etc and survive. If
DMARC is trying to change that, I do not believe this is good with an ATPS
concept.
What we need to drive home is the fact this is not a plug and play protocol.
You can rest assured to have problems when using a strong 1st party only policy
in public and now increasily, in private too when the ESP is not capable of
supporting an authorized MTA forwarder. It lacks the tools, It needs ATPS.
DMARC firms need to do better job of making sure their customer’s domain are
clean before using p=reject. The reporting will help determine if moving from
p=none to p=reject/quarantine will not produce false positives, but even if the
reporting is capable of exposing a false positive reject friendly resigner, it
is not capable of authorizing the friendly resigners. DMARC lacks ATPS support
for ESPs to leverage.
—
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
