On 17/11/22 03:59, Hector Santos wrote:
On Nov 11, 2022, at 11:46 AM, Barry Leiba <[email protected]>
wrote:
Indeed...
The issue here is this:
1. I get a (free) account on free-email.com <http://free-email.com>.
Ok
2. I send myself email from my account to my account. Of course,
free-email signs it, because it's sent from me to me: why would it
not?
The wcSMTP router logic will not sign this path because it never
reaches the remote target outbound queue where it may be signed.
I noticed this too. I'd suggest that Barry's example could be
reinterpreted as "I send myself email from my account to an account that
I control somewhere else" (but that also can't be linked to me
personally). An additional piece of logic here is that "I" have crafted
a message that would not be recognised as spam on its own, only if
copies of it appeared in large numbers. Signing in this situation is
perfectly reasonable behaviour and not something that should cause
harmful consequences for the signer.
There is an important nit here that appears not to have been noted
explicitly in the discussion so far: *whether* a message is spam is — by
definition — a consequence of how many copies of it are sent. At the
time of signing in a situation like the above it literally isn't spam,
although there may be sufficient features in the message content or
sending context to identify it as abuse, or very likely abuse. This is
not to say that all messages are in this grey area, but rational abusers
will of course operate exclusively in the grey area, iterating with
minor variations as often as they need to until they get the response
that they're after (a single message signed and sent).
The consequence is essentially the sub-text for this discussion: a DKIM
signature from a trusted signer alone is not enough basis to determine
that a message should be delivered, precisely because BCC-like
functionality can be abused (and apparently is being abused at scale).
This does point in the direction of ARC-like approaches: if an MTA
wishes to send a message to a recipient not named in a To:/CC:/etc.
header that's covered by a DKIM signature, then it would seem desirable
for that MTA to generate and attach a signature attesting the intended
recipient. Whether this (lifting envelope information into a signature
added to the header) is architecturally permissible I do not yet know.
For failed SPF validation, I believe we need to honor the handling
expected by the domain owner, first and foremost. Meaning Exclusive,
Strong policies should always be honored. The weak and partial/soft
policies is what has added handling unknowns
Disagree. We use DKIM for email authentication precisely because there
are important mail flows that are not controlled by the
sender/domain-registrant. Receivers generally and reasonably put the
interests and preferences of their users ahead of the published
preferences of senders and domain-registrants. I'd suggest that this is
a reasonable choice and should be part of the reasoning in any adopted
solution.
(and unfortunately, we have not focused on leveraging the LOOKUP
opportunities to extend policies).
I don't understand what you're suggesting here.
- Roland
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
