Re: [dmarc-ietf] ARC questions

[Dave Crocker <[e-mail]>]

On 11/23/2020 4:13 PM, Brandon Long wrote:
>
>
> On Mon, Nov 23, 2020 at 12:48 PM Dave Crocker <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 11/23/2020 12:15 PM, Brandon Long wrote:
>>     On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>     DKIM often ties a domain to reputation and other anti-spam
>>     features.  If you
>>     forward spam to another host and sign it while forwarding, then
>>     the other host
>>     will think you send spam.
>
>     Well, ummm... errrr... yes.  That's because, in such
>     circumstances, you do.
>
>     More significantly, the signature makes sure that such as an
>     assessment will only be made accurately, rather than penalizing
>     you for problematic mail that is attributed to you but that you
>     did not handle.
>
> If the result is marking all of the mail from that mailing list as 
> spam, then you've likely done your users a disservice.

Why would you put forward a hypothetical that might reasonably be 
characterized as unreasonable, especially given that you also make clear 
why it is unreasonable? (*)


> Being able to differentiate is useful.  Also, forwarders often don't 
> have all of
> the signals that the user's mailbox does.. not the least of which is 
> that different recipients have different judgements on what is spam, 
> and the "this is spam" signal rarely makes it back to the forwarder.

Except that mailing lists are also recipients, notably including likely 
history from authors, and possibly more history than a final recipient?

There are, of course, possible signals a final recipient might have 
about an author, that the mailing list won't have. Equally there might 
be others the list has that the final recipient doesn't, such as knowing 
about other mail from the author, to other lists the mailing list system 
operates...


>>     DMARC ties DKIM to the From header and at least is interpreted as
>>     being an
>>     anti-phishing feature.  DKIM signing mail that you forward could
>>     mean upgrading
>>     a phishing message to passing DMARC.
>
>     I don't understand.  The first sentence makes sense to me, but the
>     second doesn't.
>
>     "Upgrading...to passing DMARC only applies if a) the signature
>     matches the From: field domain, and b) that domain has an
>     associated DMARC record.  But if you don't watch DMARC to apply in
>     that case, what is the DMARC record there fore?
>
> I send a phishing message to a mailing list or alias at a domain with 
> a From header of that domain, and the list blindly
> re-signs all mail sent to the list, I've now "authenticated" the 
> spoofed message, and it will now "pass" DMARC.

There are so many different ways this represents really poor mailing 
list setup, operation and possibly design, I again wonder at your 
offering it as an example of any point relevant to this exchange.

It's not that what you suggest hasn't happened, it's that the fact that 
it represents multiple problems also suggests it can -- and probably 
should -- have multiple solutions.


> Perhaps it
> upgraded from a quarantine to none, since the mailing list doesn't 
> have the concept of a spam folder, or perhaps the sales@ team
> has decided they want all of the forwarded messages, even if probably 
> spam, so that they can go through them to make sure...
> but it lost the quarantine disposition on the forward when it gained 
> authentication.

More problematic hypotheticals, all of which arguably represent poor 
services, just as originators can be poorly run services.


>>     Perhaps this all means that DKIM has been used for more than it
>>     was intended for.
>
>     "More than" suggests that the use has legitimacy.  It doesn't.
>
> We don't always have control over how our work is used.

No, but we do have control over a) how we write about it, b) how we talk 
about it, and c) what we do about misuses of the work.

You appear to be taking the view that however others choose to interpret 
a specification is what the specification is for and how it operates.  
Except that that is only one -- and I'd argue highly problematic -- 
approach to misuses of a specification.


> If I proposed extending a standard in a new direction that would
> be perfectly fine with the original intent of the standard, and that 
> clashed with how the standard had come to be used in
> practice, my extension is DOA.

Possibly.  But not automatically.

For reference, note that 90+% of email is spam.  Does that mean that a 
proposal to counter that (inappropriate) use of email is DOA?  That 
seems to be the logic you've applied.


>     Forgive me but I think that:
>
>>         Authenticated Received Chain (ARC) creates a mechanism for individual
>>         Internet Mail Handlers to add their authentication assessment to a
>>         message's ordered set of handling results.
>
>     specifies a nature and responsibility pretty much identical to
>     what DKIM claims.  The enhancements are a) chaining, and b)
>     carriage of earlier assessments.  But in terms of
>     'responsibility', this reads the same as DKIM.
>
>
> I don't see how "claim some responsibility" is the same as "add their 
> authentication assessment".  I guess they are claiming
> responsibility for the assessment, but that's a very specific thing, 
> and not the "some [unknown] responsibility"

I cited assessment as a difference.  And yes, that's the only difference 
in responsibility.  Otherwise, it's just an authentication of having 
processed the message.


>>     and as different from DKIM so
>>     that it wasn't mistaken for the uses that people were already
>>     using DKIM for.
>     Oh?
>
>
> This was definitely a topic of discussion during the initial meetings 
> where we went from XOAR to ARC.

Sorry, I don't recall that.


d/


(*) https://en.wikipedia.org/wiki/Straw_man

-- 
Dave Crocker
[e-mail]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[e-mail]