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

[Dave Crocker <[e-mail]>]

>>>> 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.


>> 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.

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


>> 3. I'm not finding the reference in any of Doug^X Michael's notes
>> that your are relying on.  Please be specific about it.
> 
> 
> https://mailarchive.ietf.org/arch/msg/dmarc/-pX7yWlSk39ShOjAzWMxhxlKh1E

Finally found that you meant Herr Hammer.


>>> 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?


> 
>>> 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.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net