Re: [Ietf-dkim] Misuse of antiforgery protocols
On 12/14/22 7:21 PM, Evan Burke wrote: Generally: x= is automatic and will usually be faster, and requires no engineering effort to build out the key management service, and no ongoing operational/maintenance/infrastructure costs. I did say "possibly a LOT, more complex". Looks like a lot of complexity for little to no benefit over x=. My understanding of part of the thread is that attackers are re-playing messages during the validity time covered by x= and that there is desire for a solution to overcome that. I sort of loosely equate what I'm talking about to that of a CRL wherein it's possible to revoke / invalidate a TLS certificate before the "Not Valid After" date & time passes. So it sounds like from the two "operational (overhead)" comments that the idea might provide an answer to the question -- as I understand it -- though some people may choose that the overhead is not worth using this answer. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On Thu 15/Dec/2022 00:46:42 +0100 Jim Fenton wrote: On 13 Dec 2022, at 17:00, Michael Thomas wrote: Which brings up a question: even though they pass on DKIM they should fail on SPF, right? For transactional email that seems like a big old red flag, right? Some people use receive-side forwarders (e.g., college alumni addresses) to have a consistent email address if they change ISP. That will, completely legitimately, cause SPF failures on transactional email. ale@pcale:~$ dig +short member.fsf.org txt "v=spf1 ip4:0.0.0.0/1 ip4:128.0.0.0/1 ip6:0::/1 ip6:8000::/1 +all" Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
> On 15 Dec 2022, at 00:46, Grant Taylor > wrote: > > On 12/14/22 11:10 AM, Evan Burke wrote: >> It doesn't. Most of the accounts are caught before sending. All it takes is >> one to slip through the anti-spam detections and then go send millions of >> replay spam messages or more - even if that account is shut down quickly >> after sending. > > What would happen if the ESPs DKIM implementation got, possibly a LOT, more > complex in that key pairs used to sign outgoing email from clients with keys > specific to each client? > > That way if ~> when the ESP needed to cancel a client's service, the ESP > could also withdraw the client's public key in the ESP's zone(s) thereby > breaking the DKIM signature by rendering it unvalidatable. I'd think that > this would largely comedown to a TTL issue on the DKIM's public key record in > DNS and implementation complexity. > > What am I failing to take into account? Operational overhead. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
