[dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

[Hector Santos <[e-mail]>]

Hi,

I had the privilege of attending my inaugural IETF 117 conference in 
San Francisco recently. The experience was enlightening, offering an 
opportunity to engage with many of the IETF "Mail/DNS Men." Notably, 
the guidance from Barry, Murray and Pete and others, was invaluable. 
Their insights deepened my understanding of IETF operations and 
working groups.

I was also pleased with the effectiveness of MeetEcho for remote 
communication. On occasions when I couldn't attend certain meetings in 
person, this tool was a godsend. I strongly encourage anyone with a 
keen interest in IETF protocols to participate in the IETF meetings 
whenever possible. My visit to San Francisco coincided perfectly with 
the conference, as I was already in the city visiting my daughter.

I found our discussions during the DMARC meeting to be highly 
productive. Here are my comments on the key topics that Barry 
highlighted, along with a summary of my input:

o Concerning p=reject:

   - Our focus on p=reject should be expanded to include p=quarantine 
as they're both challenging. We should perhaps categorize these under 
'Restrictive Policies'.

   - I'm unsure about the best way to phrase p=reject. While I have 
reservations about the "Standard Track" status in the draft document, 
I understand that this operational usage can work satisfactorily if 
people adhere to the advice—primarily, not using p=reject.

   - Following my discussion with Wei, I intend to consider 
integrating ARC into my mailer. This could potentially aid with 
indirect mail flows with SPF and provide more data from smaller 
operations forwarding mail to larger ARC processors, such as gmail.com.

o Concerning SPF:

   - I concur that the SPF language should be more flexible in the 
DMARC authorization logic.

   - I agree with the introduction of an "auth=" tag, as proposed by 
Alessandro and refined by Levine.

   - I highlighted that "SPF Comes First" before DMARC or DKIM is 
known. It is entirely possible that an SPF restrictive policy (-ALL, 
Hard Fail) can preempt the payload transfer, causing a rejection 
before the DATA is reached. DMARCbis does acknowledge this 
possibility, mentioning that receivers might process SPF rejects 
before DMARC is known.

   - I mentioned using the deprecated SUBMITTER/PRA (RFC4405/RFC4407) 
protocols as an implementation detail to access the author's DMARC 
policy at the SMTP "MAIL FROM" stage. Wei expressed interest in this 
idea. This could also enhance the "auth=" idea to help manage local 
policy SPF -ALL handling. Should SMTP immediately reject? The PRA at 
SMTP could aid this decision for SPF -ALL policies. Based on many 
years of implementation, it's evident that many mailers are either 
identical or are using the same software that supports SUBMITTER/PRA, 
possibly due to ongoing support for the deprecated SenderID (RFC4406) 
protocol.   Here is a small snippet of this morning transaction using 
submitter:

C: MAIL FROM:<> BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL FROM:<> BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<37046-60459-85371-8882-hector=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<22250-29238-140070-4080-sales=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<22250-29237-207069-4080-sales=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<22250-29237-206580-4080-sales=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<22250-29238-140070-4080-sales=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<22250-29237-207069-4080-sales=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<67240-116180-380845-15028-sales=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL FROM:<> BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL FROM:<> BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<22252-29237-206580-4081-sales=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<22252-29238-140070-4081-sales=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL FROM:<> BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<22252-29237-206580-4081-sales=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<37046-60459-83113-8882-hsantos=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<37045-53741-2800426-8882-hillary4prez=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL FROM:<> BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<37049-53741-2800426-8883-hillary4prez=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL FROM:<> BODY=8BITMIME SUBMITTER=[e-mail]
C: MAIL 
FROM:<37049-53741-2800426-8883-hillary4prez=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]


I'm pretty sure most these are spam.

Thanks

--
HLS