I've been digging through the DMARC pre-IETF drafts and IETF drafts and came to
the following conclusion:
The following report elements were added to (pre IETF) draft-dmarc-base-00-03
(January 2013) [1]:
* IdentifierType 'envelope_from'
* SPFAuthResultType 'scope'
* DKIMAuthResultType 'selector'
On Sat, Aug 3, 2019 at 12:02 AM Scott Kitterman
wrote:
> Policy is an indication of sender preference, not a directive the receiver
> must follow. I think the definition is fine. If the sender prefers
> failing messages be quarantined, then they should use that policy. They
> won't get what th
On Sat, Aug 3, 2019 at 8:28 AM Alessandro Vesely wrote:
> IOW, dnswl=pass means the sender was whitelisted.
>
If that's the case, why do downstream agents need "policy.ip" at all?
-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman
On Sat, Aug 3, 2019 at 8:40 AM Alessandro Vesely wrote:
> That's much better. If the definition of ptype smtp were "a parameter of
> the
> SMTP session used to relay the message" it would be perfect. I'd propose
> that
> policy.iprev be deprecated and smtp.remote-ip used instead.
>
Given that
I agree that messages with both DKIM and SPF pass results can be useful when it
comes to validating that everything is (still) in working order. But I come
across domains with very high email volumes. So daily reports contain thousands
of records that are consuming bandwidth, storage and process
On Wed, Aug 7, 2019 at 6:46 AM Freddie Leeman wrote:
> I've been digging through the DMARC pre-IETF drafts and IETF drafts and
> came to the following conclusion:
>
Seems to me the working group has a choice to make here, somewhere between
"reinforce the XML specification as published" and "take
On Fri, Aug 2, 2019 at 3:31 PM Scott Kitterman wrote:
> Is silence concurrence? Comments inline. Please let me know how to
> proceed
> on updating the draft. I'd appreciate anyone else's feedback too.
>
Addressing only this point, yes, I concur with all of Murray's comments and
requests.
___
