> On Nov 11, 2022, at 11:46 AM, Barry Leiba <barryle...@computer.org> wrote:
>
> Indeed...
> The issue here is this:
>
> 1. I get a (free) account on 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.
The router will export a message that targets a locally-hosted domain but it
goes into the Inbound Import Queue rather than the Remote target outbound
queue. I have debated the signing the Export->Local-Queue->Import mail. It is
a matter of moving the location of wcDKIM signer which is now at the router
outbound logic.
> 3. I take that signed message and cart it over somewhere else, sending
> it out to 10,000,000 recipients through somewhere else's
> infrastructure. It's legitimately signed by free-email.com.
Ok
> 4. Of course, it fails SPF validation. But DKIM verifies and is
> aligned to spam...@free-email.com, because there you go.
>
> That's the attack. It's happening all the time. If between 1 and 2
> we could use x= to cause the signature to time out, we'd be OK.n
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 (and unfortunately, we have not focused on leveraging the
LOOKUP opportunities to extend policies).
> The trouble is that we have to make x= broad enough to deal with
> legitimate delays. And during that legitimate time, it's trivial for
> a spammer to send out millions of spam messages. Crap. So x= doesn't
> help.
I had a 2006 draft to deal with expiration for time-shifted, time delayed
verification.
Partial DKIM Verifier Support using a DKIM-Received Trace Header
https://datatracker.ietf.org/doc/html/draft-santos-dkim-rcvd-00
I have to review it to see if it can apply here in some manner 16 yrs later.
>
> We have to look at other options. We thought of this when we designed
> DKIM, but couldn't come up with anything that would work.
> We have new
> experience since then, and we want to look at alternatives, and decide
> whether priorities have changed, use cases, have changed, and so on.
>
> It's entirely possible that we still can't fix it without breaking use
> cases that we're not willing to break. But we have to try.
I have always been a strong advocate for extended policies for what I believe
is the new “normal’ for SMTP receiver lookups. For the most part, related to
SPF/DKIM/DMARC, we have today lookups:
5321: SPF
5322: DKIM, DMARC
We can leverage the archived PRA/SUBMITTER protocol.
SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail
Message
https://www.rfc-editor.org/rfc/rfc4405
Purported Responsible Address in E-Mail Messages
https://www.rfc-editor.org/rfc/rfc4407
which passes then 5322 PRA to 5321 via the SUBMITTER ESMTP extension:
MAIL FROM:<return-path> SUBMITTER=PRA
The PRA is typically the 5322.FROM
This gives ESMTP an optimizer and heads up for the transaction to expected
DMARC domain handling policy prior to transferring the DATA payload.
ESMTP receivers who enables RFC4405 will immediately see it being used by
compliant ESMTP senders.
We have used it for SPF lookups over the years.
—
HLS
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
