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

[Alessandro Vesely <[e-mail]>]

On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote:
> 
>>>>> If I put my gmail address into the from field, there is no 
>>>>> pretending, no matter what platform I am using.
>>>>
>>>>
>>>> That conflicts with the coarse-grained authentication strategy, 
>>>> established at the FTC Email Authentication Summit in November
>>>> 2004, as Doug^W Michael recalled >>>
>>> 1. I was making a semantic point, not a technical or technical 
>>> policy one.
>>
>> They have to match at some point.
> 
> it would be nice, wouldn't it?
> 
> but that's separate from the factual statement I made.


Separate but related.


>>> 2. There was nothing 'established' at that event.  There were 
>>> interesting discussions, but that's all.
>>
>>
>> I wasn't there.  Can't it be considered the historic event that 
>> marked domain-level authentication as the promising strategy to 
>> counter email abuse?
> 
> Reference to that event as if it 'established' anything is misguided, 
> at best.  The meetings were helpful, but not definitive.  And the 
> efforts at domain level authentication were wholly independent of 
> these events.


Would it be still correct to mention that summit as a conspicuous 
event that testifies the emergence of domain-level authentication 
around the early 2000s?


> As already noted on this list, the events served as a plea from the 
> government and, therefore, a signal that the government was concerned.


A noteworthy historical detail.


>>>> Your gmail address needs to be authenticated by gmail. 
>>>
>>> Good grief, no.  There is no system rule to that effect.  DMARC 
>>> created that, but no policy before it was in place, never mind 
>>> accepted.
>>
>>
>> DMARC took that strategy to the extremes.  A number of users and 
>> operators seem to have accepted it.  Why cannot we accept it too?
> 
> That DMARC does something and that some people use it is quite 
> different from claiming that there was some grand change in the 
> semantics and operational policy of email.  Why can't THAT be accepted?


There's been a combination of events, from IETF's reluctant 
laissez-faire to Yahoo/AOL adoption, which brought up the illusion 
that email authentication can provide a global means to counter 
spoofing.  To believe that such illusion will come true makes for a 
strong motivation.

Couldn't we meet somewhere halfway?  I can see that you, John, Herr 
Hammer, and other relevant participants don't accept that domain-level 
authentication is semantically mandatory.  What d'you reckon about the 
possibility that such grand semantic change can be made official 
within the next 10~20 years?  I think that by just spelling the 
technical means /as if/ such change is going to happen, we can design 
a consistent authentication protocol.


>>>> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and 
>>>> whitelisted as yet another domain (songbird.com) can hardly be 
>>>> verified.  There is no "pretending", since it's you, but it is not 
>>>> formally distinguishable from spoof, is it?
>>>
>>> Whether valid and invalid uses can be distinguished does not alter 
>>> the fact that valid uses are valid.
>>
>> The problem is to find the technical means that allow receivers and 
>> recipients to verify such validity.
> 
> Of course.  But when it's at the expense of valid use that has worked 
> for 45 years, then those means are problematic.  Highly.


It seems to me most expenses have been paid already, for example this 
mailing list is applying From: rewriting.  We don't need to propose 
further restrictions.  To the opposite, there are means on the 
table[*] that can enable us to sketch a time horizon where From: 
rewriting can cease.

16 years have passed since the FTC event, which is 1/3 of those 45. 
What I see looks much like a very mild shift.  Lazy operators have 
plenty of time before the semantic change is established, at some 
point in the medium-term future, if ever.


Best
Ale
-- 

[*] For MLMs to resume traditional address usage, the most promising 
I-D's is dkim-transform, IMHO.