On Friday, November 11, 2022 4:23:44 AM EST Laura Atkins wrote: > Snipping a bunch. > > > On 11 Nov 2022, at 05:04, Scott Kitterman <skl...@kitterman.com> wrote: > >>> 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 don’t understand this.
Typically for email forwarding the forwarder doesn't change the To:/Cc: in the message body. They relay the message to the appropriate Rcpt To:. As a result, for these indirect mail flows To:/Cc: will never match Rcpt To: at delivery. > > 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’s One Message - sent to an address that has given permission to receive > that message. What I hear you saying is tha ESPs that allow single messages > sent to opt-in addresses deserve to have their domain reputation abused. Is > this a correct summary of your argument? > > If it is, I guess we are at a standoff because I don’t think ESPs who are > mostly doing the right thing (ie, letting folks send opt-in messages) > deserve to have their reputation trashed by senders who are actually > unwelcome (and know they’re unwelcome) on the ESPs platform. Your phrasing is harsher than I would put it, but not really wrong. The problem is that there's no way to distinguish this case from many legitimate cases. ESPs are probably going to need to step up their efforts to know their customers or push them to use their own domains (which aren't that hard to get). > > 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. > > Isn’t that what the whole working group is exploring? Can we address this in > any meaningful manner? You seem to want to have the discussion before we > charter it, rather thn Yes. I think before we charter work to solve a problem, we should understand the problem well enough to determine that there is a technically tractable problem to solve. I'm increasingly convinced there is not. > > 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. > The senders are doing their work. They are not permitting the mail to go > through their systems. They’re only sending opt-in mail through their > systems. T The definition of "doing their work" may need to be expanded. > > 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 was around for the open relay discussions and I don’t see the parallels. > > > 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. > > What abuse problem has “the market” ever solved? Abuse (and other community > problems) are solved by people taking action. Not by some magic wand of > capitalism choosing ’the right’ answer. Open relays would be one example. Try and run an open relay today and how long are you going to be able to deliver mail through it? > > 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. > > But are you representative? Almost certainly not. > > 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. > > This is what makes me think you’re not understanding the actual issue here. > It is a DKIM unique issue. The ESPs can see, control and manage the mail > using their servers. They will block, shut off and otherwise disrupt the > flow of spam coming out of their system. In the case we’re discussing here, > the message isn’t going out through their system, so they have no control. I understand the distinction. It may be that the ESPs you're familiar with do this well. Not all of them do. > > 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. > > They took responsibility for the single opt-in message that was sent through > their system. I’m not sure they have any responsibility for the million > copies of the message the recipient sends through a different > infrastructure. Unless you’re saying that DKIM signatures should only be > assigned to mail that has been manually reviewed by the infrastructure > host? Find me a technical distinction that differentiates the replayed message from normal usage and I'm all ears. I don't think there is one. Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
