Re: [dmarc-ietf] Non-technician's idea for DMARC improvement

2024-01-27 Thread Richard Clayton
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Ted Wham writes >any other source of email that fails authentication is definitionally >unauthorized. So why not alert the senders of these bad messages that they >might >have an open relay that has been hijacked for spam purposes by

Re: [dmarc-ietf] Non-technician's idea for DMARC improvement

2024-01-27 Thread John Levine
It appears that Ted Wham said: >-=-=-=-=-=- > >DMARC allows a policy ("p") value of none, quarantine, or reject. According to >DMARC.org, as of Q2 >2022 just under 20% of all DMARC implementations chose the reject policy >(source: >https://dmarc.org/stats/dmarc/). However, for that subset of al

[dmarc-ietf] Non-technician's idea for DMARC improvement

2024-01-27 Thread Ted Wham
DMARC allows a policy ("p") value of none, quarantine, or reject. According to DMARC.org, as of Q2 2022 just under 20% of all DMARC implementations chose the reject policy (source: https://dmarc.org/stats/dmarc/). However, for that subset of all DMARC adopters, obviously those businesses are cer

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

2024-01-27 Thread Scott Kitterman
On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote: > On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote: > >> On Jan 19, 2024, at 10:19 AM, Todd Herr > >> wrote: > >> > >> Perhaps the way forward for DMARC is to look for a Sender header when > >> there is more than one RFC53

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

2024-01-27 Thread Douglas Foster
Assume this RFC5322 header: From: user@attackdomain, presid...@whitehouse.gov For messages like this: - Verifying one identity (e.g. "user@attackdomain") does nothing to say that the unverified identity is used with authorization. - Technical issues mean that it will be rare, nearl

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

2024-01-27 Thread Alessandro Vesely
On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote: On Jan 19, 2024, at 10:19 AM, Todd Herr wrote: Perhaps the way forward for DMARC is to look for a Sender header when there is more than one RFC5322.From domain and use that for DMARC processing, with the stipulation that messages that don'