On Sun, Sep 10, 2023 at 8:46 PM Jim Fenton <fen...@bluepopcorn.net> wrote:
> On 7 Sep 2023, at 9:28, Wei Chuang wrote: > > Many enterprises already have "p=reject" policies. Presumably those > domains were subject to some sort of spoofing which is why they went to > such a strict policy. > > This is not necessarily the case. For example, DHS has directed > <https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security> > all Executive Branch federal agencies to publish a policy of reject, > regardless of whether they were subject to spoofing (and with no mention of > the problems with doing so. Others have published “Email Security Best > Practices” advocating the use of p=reject. For example, one well-known > email vendor has a tool that generates a warning if p=quarantine or > p=reject isn’t configured, and says on their website, “We recommend reject, > for reasons we’ll touch on later.” > The Federal government is not a very good example to make your point. In the 2010-2011 time frame there were a number of high profile cases where government email WAS spoofed with various negative outcomes. Two examples come to mind. The first was an email purporting to be from Senate staff (Sergeant at Arms) to various news agencies/publications that several high profile Senators were killed. There were news reports of this as a result that briefly moved financial markets. The other involved fake online Christmas cards (email notifications) to various government contractors and purporting to be from the White House (POTUS) even though at the time the White House was still only sending printed Christmas cards. This resulted in compromises at more than one defense contractor. As a result of these sorts of incidents, Pat Peterson (Agari) and I were asked by EOP (Executive Office of the President) to put together and give training on email authentication that was turned into a virtual training environment for government employees (excluding contractors). Since that time there have been various efforts by the Federal government to implement stronger email authentication practices, both at agencies and government contractors. This ultimately led to the DHS directive. Yes it's a blunt instrument but it is the culmination of a process triggered by cases of malicious "spoofing". > I agree that the SHOULD language is not very useful because it’s likely to > be interpreted as only advice. Instead, I think we need a stronger > statement about the consequences of this policy. For example, “Domains > publishing p=reject MUST NOT expect mail to mailing lists and similar > forwarders to be delivered reliably.” > The "MUST NOT you suggest is normative language that many will ignore with no particular incremental negative impact to them beyond the current situation. I'm not thrilled with the proposed SHOULD NOT language but it makes much more sense to me than your proposal. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
