Re: [dmarc-ietf] Two basic Issues to address to help complete DMARCbis

[Hector Santos <[e-mail]>]

On 4/24/2023 7:22 AM, Alessandro Vesely wrote:
> On Sun 23/Apr/2023 19:20:06 +0200 Hector Santos wrote:
>> On 4/23/2023 6:10 AM, Alessandro Vesely wrote:
>>>
>>> Meanwhile, digressions about ATPS and similar schemes can help 
>>> casting some light on future evolution.  From: rewriting cannot be 
>>> the final solution; it is a temporary hack. Digressions don't slow 
>>> down the publication, as discussions about actual text quickly 
>>> prevail.  They are just a mean to help convergence toward a common 
>>> vision of the future.
>>
>> With each year, that "temporary hack" becomes the new normal and it 
>> will be harder to clean up. It is not the right way and I don't  
>> its too late to reverse.  However, it has been 17 years and 
>> DMARCbis is not finished without some clean up in this area.
>>
>> First, Section 4.4.3 should have text on using extended tag methods 
>> to provide 3rd party authorization methods.  Just add the RFC 6541 
>> abstract or version of it:
>
>
> Proposing to add text to DMARCbis about 3rd party auth is not a 
> digression.  We cannot solve the problem before publishing 
> DMARCbis.  The text to add to DMARCbis can mention that From: 
> rewriting will fade out, but cannot say how. (This is not a rule, 
> just a scheduling requirement.)

This suggestion is helpful, thanks.

I believe the time is now during this drafting.  I rather not punt. I 
don't wish to wait another 5-10 years to address this again.

DMARCbis should be the string board to finally solidity the potential 
DMARC add-on market to deal with the long time loopholes. The 
conceptual solutions are well known and there are both DNS and non-DNS 
proposals to explore.  It can reference the efforts and explain why 
ESPs may not be able to use it for outbound mail, but may be able to 
support it for verification of inbound mail.  It clearly scales for 
verification.  Why not help with inbound security even if they can't 
use it from themselves?   We are helping yahoo.com and others p=reject 
domains and I hope they are helping senders with their receivers.  
Even if the ESP has no policy or p=none, it can still do an 
verification ATPS check when the author and signer domains do not 
match.  How hard is that?

Any proposed text should cover these main points.

--
HLS