On Thursday, November 10, 2022 8:32:16 AM EST Steve Atkins wrote: > > On 10 Nov 2022, at 13:17, Murray S. Kucherawy <superu...@gmail.com> wrote: > > > > On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins <la...@wordtothewise.com > > <mailto:la...@wordtothewise.com>> wrote: In many cases, the reason the > > mail isn’t going out through the signing domain is because the signing > > domain’s anti-spam heuristics are good enough that the sender couldn’t > > maintain an account there long enough to send out any volume of email. > > That’s why the domain has a good reputation - because they block spam off > > their network. This is a way to steal the good reputation from the good > > ESP. > > > > Interesting. Almost seems like "SPF against the signing domain" could be > > a win, except for all the usual forwarding concerns. > > > > 2) The messages often have two different To: lines > > > > This violates RFC 5322, so it would be easy to filter these out, except > > that we would need to know how common and tolerated this is today among > > legitimate messages. > The other (more common?) case is that the original recipient is in the > signed 822.To, while the new recipient is not in the To: or Cc: headers at > all. While that’s just the same as old-school alias forwarding, and you > might not be able to spot that on any given single email I’d bet that it’s > easy to spot and block at a mailbox provider of any size. > > A heuristic I’ve suggested previously is “If the recipient’s email address > is not in the To: or Cc: header then treat the mail as unsigned”.
Which is a fancy way of making DKIM only work for direct mail flows. I've been thinking some more about this and mentally I'm swinging back more towards the system is working as designed, don't mess with it. If an ESP is willing to take on a trial customer they know nothing about and let them send email leveraging the reputation of the ESP's domain, why is it wrong that it suffers when that does not end well. It is a fundamental precept of DKIM that when a domain signs an email, they are taking responsibility for it (See the RFC 6376 introduction and more specifically 2.5 and 2.6). It's further reinforced by a note in 5.1 that begins: > INFORMATIVE NOTE: A Signer can be implemented as part of any > portion of the mail system as deemed appropriate, including an > MUA, a SUBMISSION server, or an MTA. Wherever implemented, > Signers should beware of signing (and thereby asserting > responsibility for) messages that may be problematic. I've yet to see any proposed problem that can be resolved without disrupting legitimate mail flows or standing the 5321/5322 architectural division on its head. I know it when I see it isn't a sufficient definition. My more cynical side sees this issue as senders trying to offload more work on receivers even though it's work that the sender is explicitly responsible for. For those that have been around for awhile this reminds me of the now long dead controversy about closing open relays. It's not identical, but I think it rhymes. Back in the mists of the early Internet we didn't have submission services because any client could send email via (most) any MTA, so they weren't needed. As you can imagine, spamming was incredibly easy and the community gradually came around to the point that you can't just relay email for anyone, an MTA should serve authorized users (I oversimplify here). As this consensus was being developed, a substantial number of MTA operators objected. Eventually, being an open relay meant no one would take mail from you. This seems similar. I can imagine the market solving this. If there are two ESPs and one is careful about who is allowed to send mail signed by their domain and the other is not, I suspect that eventually superior reputation will result in superior deliverability, which should result in being able to charge more for a premium service. As a receiver, if I have access to a quantitative reputation scoring system for IP addresses and domains, I might counter this, in the meantime, by looking for mail from IP addresses with statistically significantly worse reputation than the reputation of the domain and treat those messages more suspiciously. I don't know that I would spend effort on special signature decoding mechanisms that are inherently risky for false positives. Although not in scope for this discussion, SPF can have similar issues when ESPs are not sufficiently careful about what email they let out from their servers with their domain in Mail From, so this isn't a DKIM unique issue. Ultimately, I don't think senders should DKIM sign mail they aren't willing to take responsibility for, since that's exactly what a DKIM signature is supposed to signify. Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
