Re: [dmarc-ietf] Another point for SPF advice
I believe it is correct, SHOULD strive to trusted known sources. The final
mechanism SHOULD be one of (hard) failure. This is what we (ideally) strive
for. I believe anything weaker is a waste of computational resources, causes
confusion using neutral or even soft fails especially with repeated
transactions.
All the best,
Hector Santos
> On Mar 5, 2024, at 9:29 AM, Alessandro Vesely wrote:
>
> Hi,
>
> in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last
> sentence says:
>
> The SPF record SHOULD be constructed
> at a minimum to ensure an SPF pass verdict for all known sources of
> mail for the RFC5321.MailFrom domain.
>
> As we learnt, an SPF pass verdict has to be granted to /trusted/ sources
> only. An additional phrase about using the neutral qualifier ("?") for
> public sources might also be added.
>
>
> Best
> Ale
> --
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 9.5 DMARC Report Format Registry
Generally they will leave it and mark Obsolete. This should be called out in the RFC. (I have not looked right now). tim On Fri, Mar 8, 2024 at 11:42 AM Murray S. Kucherawy wrote: > On Fri, Mar 8, 2024 at 6:49 AM Alessandro Vesely wrote: > >> since we removed the rf= tag (format of failure reports), do we still >> need to tackle the IANA registry? Since we only use one format, it >> makes little sense. However, the registry actually exists. Is it >> possible to delete or obsolete it, or does it have to stay there as a >> relict for ever? >> > > I'm guessing it's possible for us to direct IANA to destroy a registry, or > (more likely) leave a tombstone page in its place. I'll ask. > > -MSK > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 9.5 DMARC Report Format Registry
On Fri, Mar 8, 2024 at 6:49 AM Alessandro Vesely wrote: > since we removed the rf= tag (format of failure reports), do we still > need to tackle the IANA registry? Since we only use one format, it > makes little sense. However, the registry actually exists. Is it > possible to delete or obsolete it, or does it have to stay there as a > relict for ever? > I'm guessing it's possible for us to direct IANA to destroy a registry, or (more likely) leave a tombstone page in its place. I'll ask. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] SHOULD (was Re: Another point for SPF advice)
Heads up that I'm going to be looking carefully at use of "SHOULD" throughout the document when it comes to AD Evaluation. An example that gave me pause: On Tue, Mar 5, 2024 at 6:30 AM Alessandro Vesely wrote: > in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last > sentence says: > > The SPF record SHOULD be constructed > at a minimum to ensure an SPF pass verdict for all known sources of > mail for the RFC5321.MailFrom domain. > Why is this a SHOULD? In fact the whole section is made up of three SHOULDs, so I could do none of them for my own reasons and still claim to be "doing DMARC". Are we OK with that? (Maybe we are, but I want to be sure.) -MSK, AD hat on but askew ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Section 9.5 DMARC Report Format Registry
Hi, since we removed the rf= tag (format of failure reports), do we still need to tackle the IANA registry? Since we only use one format, it makes little sense. However, the registry actually exists. Is it possible to delete or obsolete it, or does it have to stay there as a relict for ever? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6
On Fri, Mar 8, 2024 at 4:52 AM Alessandro Vesely wrote: > On 06/03/2024 15:42, Todd Herr wrote: > > On Tue, Mar 5, 2024 at 10:45 PM Barry Leiba > wrote: > > > >> SHOULD NOT was the consensus call, and the correction Todd > >> proposes is just making that sentence consistent with that. > > > Yet, Section 7.6 still has: > > In particular, this document makes explicit that domains for general- > purpose email MUST NOT deploy a DMARC policy of p=reject. > > > Yes, due to an oversight on my part, one that I identified during my Last Call read of DMARCbis, and subsequently opened this thread to transparently confirm that I had indeed overlooked that phrase in 7.6 during previous releases and that I believed that it was an oversight and should be corrected. The chairs have confirmed that it was an oversight on my part, and the language will be changed to SHOULD NOT in rev -31, as per the discussion in this thread and the previous consensus. -- *Todd Herr * | Technical Director, Standards & Ecosystem *e:* todd.h...@valimail.com *p:* 703-220-4153 *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another point for SPF advice
On 05/03/2024 17:07, Scott Kitterman wrote:
On March 5, 2024 3:46:39 PM UTC, Alessandro Vesely wrote:
Todd Herr writes:
On Tue, Mar 5, 2024 at 9:30 AM Alessandro Vesely wrote:
in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last
sentence says:
The SPF record SHOULD be constructed
at a minimum to ensure an SPF pass verdict for all known sources of
mail for the RFC5321.MailFrom domain.
As we learnt, an SPF pass verdict has to be granted to /trusted/ sources
only. An additional phrase about using the neutral qualifier ("?") for
public sources might also be added.
To further this discussion, please define "public sources", compare and
contrast that definition to the definition of "private sources", and then
describe which sources are "trusted" and by whom.
*public sources* is a set of IP addresses used by an operator who sends mail on
behalf of its customers, not by assigning different addresses to different
customers, but according to whatever other criteria which mixes them up.
*private sources* are IP addresses in exclusive use by a domain.
A public source can be *trusted* by its customers if it reliably filters
outgoing mail by ensuring that messages sent by a given customer contain From:
domains owned by that customer.
That's obviously too long to go on the I-D. The point has to be expressed in
one or two sentences. Certainly, we cannot recommend an insecure practice.
Maybe something like trusted to prevent cross user forgery with a link to RFC
7208 11.4 (which explains what that means).
I like that wording. However, when we talk of an ISP's user, it is
actually a domain. So perhaps:
The SPF record SHOULD be constructed
at a minimum to ensure an SPF pass verdict for all known sources of
mail for the RFC5321.MailFrom domain that are trusted to prevent
cross-domain forgeries.
Possibly, a wider paragraph, with an example of using qualifiers with
the include mechanism can be given in Section 8.1.
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6
On 06/03/2024 15:42, Todd Herr wrote: On Tue, Mar 5, 2024 at 10:45 PM Barry Leiba wrote: SHOULD NOT was the consensus call, and the correction Todd proposes is just making that sentence consistent with that. Yet, Section 7.6 still has: In particular, this document makes explicit that domains for general- purpose email MUST NOT deploy a DMARC policy of p=reject. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
