On Wed, Sep 27, 2023, at 9:06 AM, Alessandro Vesely wrote:
> On 9/27/23 13:36, Brotman, Alex wrote:
> > I've attached a draft that uses attributes of a passing DKIM
> > signature to create a DNS label that can be used to discover an FBL
> > address. This feedback address can be used by message receivers to
> > provide a copy of FN (and potentially FP) (Spam/Not-Spam) reports to
> > the DKIM signers. This allows for entities to perhaps sign with more
> > than one signature, and provide feedback to each signer if desired
> > (or each can list multiple rcpts if desired). With traditional FBLs,
> > the lookup is likely based off the final sender IP address, which
> > could be the original sender, or an intermediary. This DKIM-based
> > method could aid both MBPs and ESPs in fighting outbound abuse from
> > their platforms. There are also methods in the document to attempt
> > to do more to make reports smaller, aiding storage and PII concerns.
> > Thanks for your time and feedback.
>
> I'm not clear why would DKIM selectors (s=) be involved in the DNS name
> generation. There are people who change selector for each message. In
> general, selectors play no role in identification and are solely used
> for key rotation.
I'm with Ale's thought process on using d= instead of s=.
Briefly, I thought that putting the DNS label under the selector would be great
for situations when the selector is delegated via CNAMEs (and hence any
subdomains would also be delegated), but I was conflating CNAME delegation with
NS. The domain owner would have to publish the label in DNS in addition to the
CNAME, and we know how difficult it is for most domain owners to modify their
DNS.
As discussed in the other thread, it is common for messages to carry signatures
for multiple domains (not all are rfc5322.From aligned), indicating a shared
responsibility. The responsible party(ies) capable of receiving FBLs would
publish the DKIM-FBL label in DNS under their signatory domain and not depend
on a different domain owner (bad senders would not want feedback to go to the
ESP/intermediary)
> I guess your spec derives from seeing per-campaign
> selectors, but I doubt it is a common habit. I'd suggest using
> subdomains for such purpose.
I think adding a third signature in a subdomain, with a name that has some
meaning (campaign, category, etc) would be an alternative to how the
non-standard Feedback-Id header is in use today.
> For discussion, it'd be interesting to analyze similarity and
> differences with List-Unsubscribe:, for FNs.
It seems logical that List-Unsubscribe could have supplanted FBLs in some ways.
Is there hope for that? I don't think it's common for MBPs to post an
unsubscribe when users report spam. So, I think the only way this discussion
idea has merit is if everyone starts treating spam complaints and
unsubscriptions the same way.
If the sender doesn't add a List-Unsubscribe header, does that mean the
ESP/intermediary should add one in order to get this "FBL equivalent" event
stream for the messages it is partially responsible?
Can there be two of these headers for situations when the unsubscribe, spam
complaint, bounce suppression, compromised credential detection, DKIM replay
detection, etc, processes are a shared responsibility between the sender and
the ESP/intermediary?
I assume that would introduce risk of DKIM signature breakage. This is one of
the reasons why I like this DKIM-FBL approach of using DNS for discovery rather
than the other idea to use headers to specify the complaint address. I think
any situation involving intermediaries or delegated sending of existing headers
should not depend on adding headers that may or may not already exist.
> How would a MBP decide
> whether to make use of one, the other, or both methods to signal its
> user's reaction?
I think the logic/situation would be:
1. The user doesn't like this message
2. The message may or may not have a List-Unsubscribe header - which may or may
not have a functioning unsubscribe process. The MBP may or may not treat spam
complaints as equivalent to unsubscribe requests, and vice versa.
3. The message is DKIM signed by two different domains, which indicates there
are multiple authenticated parties responsible for the message being sent. The
delineation line for the responsibilities and capabilities of each party will
be highly inconsistent and unknown to the MBP.
4. If one or both of these parties publish the label in DNS under their
respective d= domains, this indicates that they are capable of receiving the
feedback, and the MBP can/should send feedback to each responsible party to
indicate that the user didn't like the message
5. Each report receiver incorporates the feedback into appropriate action
pertaining to their area of responsibility.
Jesse
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
