On March 12, 2024 11:42:11 PM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
>>mail for anything other than their own domains. ESP customers, don't use
>>ESPs that do this.
>
>It's not just
On 3/12/2024 6:42 PM, John Levine wrote:
It appears that Scott Kitterman said:
Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
mail for anything other than their own domains. ESP customers, don't use ESPs
that do this.
It's not just ESPs. There's a widely
It appears that Scott Kitterman said:
>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
>mail for anything other than their own domains. ESP customers, don't use ESPs
>that do this.
It's not just ESPs. There's a widely reported bug that lets anyone
whose mail is
On March 12, 2024 5:37:47 PM UTC, Richard Clayton
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>In message , Scott
>Kitterman writes
>
>>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
>>mail for anything other than their own domains. ESP
Neil, to your question about mitigating false SPF PASS:
There are three possible mitigations by senders:
- Drop the SPF policy so that messages evaluate to SPF None. A few
domains do this.
- Change the SPF Policy to return SPF Neutral for cloud services, as
currently proposed.
-
> On Mar 11, 2024, at 10:38 PM, Neil Anuskiewicz wrote:
>
>
> The solution to that vulnerability is in part use a subdomain and, when
> possible, narrow the scope of what you permit. Better yet, choose a vendor
> that’s known for tight security. A quick Look at the the security headlines
On Tue, Mar 12, 2024 at 6:23 AM Tobias Herkula wrote:
> The DMARC Record on the DKIM signing domain is not relevant for DMARC
> evaluation, so if the 5322.From header domain is “example.com” the
> “adkim:r” is relevant for evaluation regarding your example setup and would
> consider a DKIM
> On Mar 11, 2024, at 10:33 PM, Neil Anuskiewicz
> wrote:
>
> Wow, the stat on how many domain operators move to enforcing reject policy
> sans aggregate reports shocked me. Trust the force, Luke.
It should not be a surprise the client/server protocol concept of “email
reporting” was always
> On Mar 4, 2024, at 11:07 PM, Chuhan Wang wrote:
>
>
> Hi Douglas,
>
> Thank you for your insightful summary of our paper. I'd like to share some of
> my opinions.
>
> You mentioned clients lose control of their SPF integrity. It's one of the
> key problems exactly. Clients host their
Is there any reason to lead with don’t worry about the tag but there is one
critical use case. I think a more declarative statement in favor of the tag for
those who will be stressed and skimming. Sure they might add a psd where it’s
not needed but that’s better than not know the important
On Mar 12, 2024, at 9:05 AM, Dotzero wrote:Neil, SPF essentially deals with hosts and IP address ranges. Your suggested solution does not address the main problem(s) raised in the research.One approach that potentially addresses the SPF problem of shared hosting would be for ESPs to use IPv6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Scott
Kitterman writes
>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
>mail for anything other than their own domains. ESP customers, don't use ESPs
>that do this.
leaving aside how practical this
Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
mail for anything other than their own domains. ESP customers, don't use ESPs
that do this.
Scott K
On March 12, 2024 4:05:15 PM UTC, Dotzero wrote:
>Neil, SPF essentially deals with hosts and IP address ranges.
Neil, SPF essentially deals with hosts and IP address ranges. Your
suggested solution does not address the main problem(s) raised in the
research.
One approach that potentially addresses the SPF problem of shared hosting
would be for ESPs to use IPv6 address space for sending. Each customer can
The DMARC Record on the DKIM signing domain is not relevant for DMARC
evaluation, so if the 5322.From header domain is “example.com” the “adkim:r” is
relevant for evaluation regarding your example setup and would consider a DKIM
signature domain of “sub1.example.com” as aligned. It’s the same
I have been building a DMARC implementation, starting with a simple
function:
TreeWalk(domain) which returns:
- Policy found or not found indicator
- Policy Domain
- Organizational Domain
- Policy record
My thought was that the Tree Walk result was independent of the domain
On 12/03/2024 03:18, Neil Anuskiewicz wrote:
Please remove the pct tag from the spec.
It has been removed already, which is incompatible with current records.
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
17 matches
Mail list logo
