Re: [dmarc-ietf] non-mailing list use case for differing header domains

On 8/21/20 4:05 PM, Brandon Long wrote: > > > On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton > wrote: > > On 8/17/20 3:52 PM, Jesse Thompson wrote: > > With a complex organization the only way to get people to change is to > publish a restrictive DMARC polic

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

I think the DMARC RFC does a good job explaining why DMARC is better than ADSP, even if the same mailing list issue is still there: https://tools.ietf.org/html/rfc7489#appendix-A.5 And if you read the archives on the move to historic for adsp, there were others then who objected to the reason put

Re: [dmarc-ietf] non-mailing list use case for differing header domains

On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton wrote: > On 8/17/20 3:52 PM, Jesse Thompson wrote: > > With a complex organization the only way to get people to change is to > publish a restrictive DMARC policy and then see who comes out of the > woodwork sheepishly admitting that they've been ignori

[dmarc-ietf] Revisiting DMARC bis Ticket 66 - What It Means To Implement DMARC

https://trac.ietf.org/trac/dmarc/ticket/66 When this issue was first raised on the list back in June, it seemed that consensus might've landed on the idea that this should be written up in a separate BCP, rather than be part of the DMARC bis effort itself. I'm concerned, however, that there might

Re: [dmarc-ietf] non-mailing list use case for differing header domains

On 8/17/20 3:52 PM, Jesse Thompson wrote: > With a complex organization the only way to get people to change is to > publish a restrictive DMARC policy and then see who comes out of the woodwork > sheepishly admitting that they've been ignoring us for years. > > Normal people sending email (esp

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/15/20 3:53 PM, John Levine wrote: > Not really. DKIM was deliberately designed not to be tied to any > visible part of the message. ADSP was a poorly designed hack that was > never implemented other than small experiments, and that I don't think > many people understood. I got a lot of grief f

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

Instead of immediately deciding which ideas can and cannot work, I suggest that we create an extension mechanism for DMARC and then let the market decide. Perhaps someone will find traction for an idea that is useful to a subset of users even if it is not useful for every sender-receiver pair.

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

On Fri 21/Aug/2020 01:55:52 +0200 Dotzero wrote: > On Thursday, August 20, 2020, Jesse Thompson wrote: >> On 8/20/20 4:00 PM, bl...@google.com wrote: >>> Neither atps or spf include are really designed for large scale usage >> >> That's my conclusion, as well. I don't want to authorize every pote