Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster <[e-mail]>]

I am beginning work on a Best Practices document which will attempt to
explain what evaluators should understand about p=reject.   Topics to
include:

   - PASS is more important than FAIL
   - SPF and DMARC are not the end of authentication options.   Any message
   can be authenticated for the purpose of distinguishing acceptable mail
   streams from their impersonators.
   - Exceptions are to be expected.
   - Tuning of Sender Authentication should be a normal process of filter
   tuning, occurring in parallel with content filter adjustment, whitelisting,
   and blacklisting.

Since nothing like this exists, it may change the approach used by some
evaluators, but nothing will change all of them.

MLM senders need their minimally-authenticated messages to be accepted by
evaluators.  This requires a recognized identity with a high reputation
that is considered relevant to the decision.    John suggested that his
doman's signature should be enough to remove distrust.   If his domain was "
pphosted.com" or "mimecast.com", his signature might be sufficient.
 Evaluators know that those signatures mean the message has been initiated
by a big-money organization, and then been filtered to prevent accidental
release of malicious messages.

How does a MLM start building that kind of reputation?

   - Ensure posts are personal messages where MailFrom and From represent
   the same account, or at minimum the same domain.
   - Ensure messages are not impersonated by validating the MailFrom domain
   with SPF, DKIM (in the absence of SPF policy), or a local policy that
   corrects for SPF policy errors.
   - Ensure messages are not malicious by performing best-effort malware
   filtering.
   - Further protect against malware and abuse by restricting high-risk
   attachment types and overly large attachments.
   - Most importantly, publish all of these policies online where a
   subscriber and his mail system administrator will find it.

But yes, it is within the power of MLMs to reject subscriptions from
p=reject domains, especially since alternatives like Gmail are readily
available for free.  But this could have happened already without IETF
advice on the matter.   So how serious is the problem, and how does our
document add value to the negotiation between domains and MLMs?

Doug Foster



On Wed, Apr 12, 2023 at 11:35 PM Murray S. Kucherawy <[e-mail]>
wrote:

> On Wed, Apr 12, 2023 at 11:41 AM Todd Herr <todd.herr=
> [e-mail]> wrote:
>
>> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy <[e-mail]>
>> wrote:
>>
>>> I've been thinking about the point a few people have made now that DMARC
>>> has two actors that cause the problem: Those who "blindly" apply
>>> "p=reject", and those who advertise "p=reject".  You do, indeed, need two
>>> to tango; enforcement doesn't happen without an advertising sender and a
>>> participating receiver.  Maybe any "MUST NOT" advice we provide needs to
>>> cover both ends.  We need to be careful about admonishing participating
>>> receivers though.  What would we say to them about how to be selective in
>>> application?
>>>
>>
>> I'd argue that we have language already that advises receivers to be
>> selective in application. The second paragraph of section 5.8, Policy
>> Enforcement Considerations, currently reads as follows in DMARCbis:
>>
>> Mail Receivers MAY choose to accept email that fails the DMARC mechanism
>> check even if the published Domain Owner Assessment Policy is "reject". In
>> particular, because of the considerations discussed in [RFC7960
>> <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#RFC7960>],
>> it is important that Mail Receivers SHOULD NOT reject messages solely
>> because of a published policy of "reject", but that they apply other
>> knowledge and analysis to avoid situations such as rejection of legitimate
>> messages sent in ways that DMARC cannot describe, harm to the operation of
>> mailing lists, and similar.
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#name-policy-enforcement-consider
>>
>> Might that language be made stronger? Sure. Might it or other text
>> include mention of ARC as a possible solution? Maybe.
>>
>
> Right, thanks for the reminder.
>
> I think part of the problem might be that blanket observance of "reject"
> is already commonplace.  There's also very little in the way of algorithms
> or text guidance to indicate to receivers how they're supposed to know when
> it's safe to actually reject.
>
>
>>
>> I've also been thinking about ways to push the burden back on the
>>> advertisers.  Imagine we have some kind of signaling mechanism that MLMs
>>> can take advantage of indicating to them that the author is using a strong
>>> policy, and so it would be possibly a bad idea for the MLM to accept,
>>> mutate, and re-send this message.  This could be a header field or an SMTP
>>> extension (though the latter is complex to get right in a store-and-forward
>>> system).  The MLM can then decide if it is willing to pass the message
>>> unmodified to the list, or reject it with an error like "The policies of
>>> this list require modification of your message, which violates your
>>> domain's apparent policy.  Your submission therefore cannot be accepted.
>>> Please contact your support organization for further assistance."  There's
>>> never an opportunity for the collateral bounce to occur if the message is
>>> never distributed, and the author domain has to either soften its policy or
>>> separate its regular users from its transactional stuff somehow.
>>>
>>> This avoids the "collateral" and "persistent" damage issues I raised in
>>> a separate post.  It still requires the MLMs to do something new, but
>>> avoids the need to implement any of a variety of unsavory mutations.  MLMs
>>> could also determine this by querying the current DMARC policy of the
>>> author's domain, to be sure, so it's a choice between MLMs looking for a
>>> header field (which they already know how to do) or becoming DNS-aware
>>> (relatively simple, but pulls in some complexities and dependencies they
>>> may not want).
>>>
>>
>> My preference here would be to add text for Domain Owners to make them
>> understand the ways that p=reject might cause some mail using their domain
>> to not make it to its destination, with "mailing lists might reject your
>> mail" being one such example.
>>
>
> And a good example, given it's the most obvious one.  But is it enough to
> say that and nothing else?  What about MLMs actually doing something like
> this?
>
> -MSK
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>