Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
In message <65860e95.20895.448c...@postmaster.inter-corporate.com>, Randolf Richardson, Postmaster via mailop writes > Would you mind sending me a linjk to your thesis? That's an >interesting topic, and based on what you've written I get the >impression that you have a lot more experience than I do. I'm just old :) https://letmegooglethat.com/?q=richard+clayton+phd+thesis+traceability -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
> In message <6585e535.11582.3a72...@postmaster.inter-corporate.com>, > Randolf Richardson, Postmaster via mailop writes > > >> The most commonly seen method of tracking is probably inclusion of > >> specifically crafted links in the message, that refer to a tracking server > >> run by the sender, so the sender knows if the recipient clicked on a link > >> in > >> the message. > > > > You're entirely correct -- thanks for adding this as I wasn't even > >thinking of it. > > ask most any ESP .. this works poorly these days, robots click on the > links to make sure they are safe and mailbox provides pre-fetch images > for reasons of performance, safety and (tada !) to make tracking harder We are an ESP, and this is something we're considering in the future, along with a variety of other techniques. We haven't spoken with other ESPs about this sort of thing. > >> >Some of our clients are investigators, lawyers, etc., who > >> > occasionally need high quality (read "reliable") evidence for the > >> > cases they're working on. DKIM, when available, makes it easier to > >> > authenticate eMail evidence in a way that can satisfy these needs. > > people who speculate about lawyers need are generally not lawyers. I've The movie-making industry is probably the worst offender of getting factual things like this wrong. :D > been an expert witness on email related cases often enough to know that > they are often perfectly satisfied to have a description of a well- > formed set of Received header fields... I agree as I've done this too. In my experience, most of requests were early enough that the evidence was helpful in changing the case direction toward a settlement rather than taking the matter to court. > ... usual quote : if you think cryptography solves your problem then you > don't understand cryptography and you don't understand your problem Right. > Investigators are even less interested in proof, they're reading all the > headers, checking DNS records and jumping to (usually plausible) > conclusions ! It depends on the investigators/lawyers. Many do want the quick and easy approach, but I have encountered some who do want more detail to make a better case. > > Some of the investigators I've dealt with neededd to deal with this > >specific scnario where someone denied sending an eMail. Although > >DKIM can help, if the server logs haven't cycled out yet then an > >affirmed affidavit that the mail server log entries are authentic has > >almost always been sufficient for motivating the denying party to > >suddenly remember that they did send the message. > > exactly ... (remember civil cases work on the balance of > probabilities).. and also remember that there is account takeover, > people in your household who know your passwords better than you do and > that's before you get into all the BGP, NTP etc exotica (if that > interests you then I once wrote a PhD thesis on all the assumptions we > make about "traceability" and the circumstances in which they go wrong) As I recall, those were probably all civil cases/investigations. Would you mind sending me a linjk to your thesis? That's an interesting topic, and based on what you've written I get the impression that you have a lot more experience than I do. > -- > richard Richard Clayton > > Those who would give up essential Liberty, to purchase a little temporary > Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
In message <6585e535.11582.3a72...@postmaster.inter-corporate.com>, Randolf Richardson, Postmaster via mailop writes >> The most commonly seen method of tracking is probably inclusion of >> specifically crafted links in the message, that refer to a tracking server >> run by the sender, so the sender knows if the recipient clicked on a link in >> the message. > > You're entirely correct -- thanks for adding this as I wasn't even >thinking of it. ask most any ESP .. this works poorly these days, robots click on the links to make sure they are safe and mailbox provides pre-fetch images for reasons of performance, safety and (tada !) to make tracking harder >> >Some of our clients are investigators, lawyers, etc., who >> > occasionally need high quality (read "reliable") evidence for the >> > cases they're working on. DKIM, when available, makes it easier to >> > authenticate eMail evidence in a way that can satisfy these needs. people who speculate about lawyers need are generally not lawyers. I've been an expert witness on email related cases often enough to know that they are often perfectly satisfied to have a description of a well- formed set of Received header fields... ... usual quote : if you think cryptography solves your problem then you don't understand cryptography and you don't understand your problem Investigators are even less interested in proof, they're reading all the headers, checking DNS records and jumping to (usually plausible) conclusions ! > Some of the investigators I've dealt with neededd to deal with this >specific scnario where someone denied sending an eMail. Although >DKIM can help, if the server logs haven't cycled out yet then an >affirmed affidavit that the mail server log entries are authentic has >almost always been sufficient for motivating the denying party to >suddenly remember that they did send the message. exactly ... (remember civil cases work on the balance of probabilities).. and also remember that there is account takeover, people in your household who know your passwords better than you do and that's before you get into all the BGP, NTP etc exotica (if that interests you then I once wrote a PhD thesis on all the assumptions we make about "traceability" and the circumstances in which they go wrong) -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
> Dnia 22.12.2023 o godz. 10:54:54 Randolf Richardson, Postmaster via mailop > pisze: > > > Tracking/spying elements in email messsages are usually intended to spy on > > > the *recipient* - did the recipient read the email at all, did he clicked > > > on a link in the email etc. > > > > ...mail server logs would be one obvious angle, but even that would > > require additional effort to extract the target user's eMail activity > > since mail server logs cycle through pretty quickly (at least on a > > lot of busy Linux systems, anyway). Log retention is generally used > > for troubleshooting, so a long-term retention usually isn't needed. > > > > Another method is for a malicious sender to deceptively include > > tracking software in an attachment. Most security software stops > > this, which includes security daemons on mail servers that can also > > be combined with blacklists of IP addresses and/or domain names that > > distribute malicious eMails or are otherwise-infected systems that > > can be used to commit such types of SMTP abuse. > > The most commonly seen method of tracking is probably inclusion of > specifically crafted links in the message, that refer to a tracking server > run by the sender, so the sender knows if the recipient clicked on a link in > the message. You're entirely correct -- thanks for adding this as I wasn't even thinking of it. > Also the HTML-formatted message may include images loaded from sender's > server, which can also be used to track whether the recipient has opened the > message at all. Yes, that's another risk, and it's probably a lot more effective than attaching a SpyWare payload in a file attachment since most users have anti-virus software these days. > But all this has absolutely nothing to do with message being DKIM-signed. Yes. > > > What does one have to do with the other and to the discussion about > > > publishing keys (the latter - to my understanding - serves only possible > > > legal purposes in case the sender needs to deny the fact that he sent the > > > message, which for me is a completely made-up scenario, an absolute > > > fiction). > > > > Some of our clients are investigators, lawyers, etc., who > > occasionally need high quality (read "reliable") evidence for the > > cases they're working on. DKIM, when available, makes it easier to > > authenticate eMail evidence in a way that can satisfy these needs. > > > > While this doesn't happen very often, I'd say that, since its > > inception, DKIM-based authenticity has moved from being a completely > > made-up scenario to having some actual utility. > > I was not talking about *confirming* the authenticity of a message by means > of a DKIM signature, but the opposite - what was being discussed here, ie. > the possibility for the sender to *deny* that he has sent the message > (despite it being DKIM signed), because of previous publication of the DKIM > private key. That seems a fictional scenario for me. Thanks for clarifying. Some of the investigators I've dealt with neededd to deal with this specific scnario where someone denied sending an eMail. Although DKIM can help, if the server logs haven't cycled out yet then an affirmed affidavit that the mail server log entries are authentic has almost always been sufficient for motivating the denying party to suddenly remember that they did send the message. DKIM can be helpful as additional supporting evidence in these cases, or even be used as a substitute where mail server logs aren't available. But the problem with this is that DKIM doesn't protect individual senders, and it also doesn't protect against someone else using another person's eMail credentials (or controlling a computer they're logged in to, etc.). > -- > Regards, >Jaroslaw Rafa >r...@rafa.eu.org > -- > "In a million years, when kids go to school, they're gonna know: once there > was a Hushpuppy, and she lived with her daddy in the Bathtub." > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
Dnia 22.12.2023 o godz. 10:54:54 Randolf Richardson, Postmaster via mailop pisze: > > Tracking/spying elements in email messsages are usually intended to spy on > > the *recipient* - did the recipient read the email at all, did he clicked > > on a link in the email etc. > > ...mail server logs would be one obvious angle, but even that would > require additional effort to extract the target user's eMail activity > since mail server logs cycle through pretty quickly (at least on a > lot of busy Linux systems, anyway). Log retention is generally used > for troubleshooting, so a long-term retention usually isn't needed. > > Another method is for a malicious sender to deceptively include > tracking software in an attachment. Most security software stops > this, which includes security daemons on mail servers that can also > be combined with blacklists of IP addresses and/or domain names that > distribute malicious eMails or are otherwise-infected systems that > can be used to commit such types of SMTP abuse. The most commonly seen method of tracking is probably inclusion of specifically crafted links in the message, that refer to a tracking server run by the sender, so the sender knows if the recipient clicked on a link in the message. Also the HTML-formatted message may include images loaded from sender's server, which can also be used to track whether the recipient has opened the message at all. But all this has absolutely nothing to do with message being DKIM-signed. > > What does one have to do with the other and to the discussion about > > publishing keys (the latter - to my understanding - serves only possible > > legal purposes in case the sender needs to deny the fact that he sent the > > message, which for me is a completely made-up scenario, an absolute > > fiction). > > Some of our clients are investigators, lawyers, etc., who > occasionally need high quality (read "reliable") evidence for the > cases they're working on. DKIM, when available, makes it easier to > authenticate eMail evidence in a way that can satisfy these needs. > > While this doesn't happen very often, I'd say that, since its > inception, DKIM-based authenticity has moved from being a completely > made-up scenario to having some actual utility. I was not talking about *confirming* the authenticity of a message by means of a DKIM signature, but the opposite - what was being discussed here, ie. the possibility for the sender to *deny* that he has sent the message (despite it being DKIM signed), because of previous publication of the DKIM private key. That seems a fictional scenario for me. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
> Dnia 22.12.2023 o godz. 16:22:45 Slavko via mailop pisze: > > But my point was (mostly) not about courties cases, i mean usual users > > tracking/spying (contacts, shoppings, opinions, etc), where signature is > > checked once (at receive time), but used/stored forever. And that cannot > > be solved by rotation nor by publishing nor by any cryptographic method > > (which i am aware of). > > I'm sorry, but I don't understand how in your view the fact that message is > DKIM signed is related to tracking/spying etc. I agree: it's not for tracking/spying since it's for authenticating the sender's identity (as an authorized user)... > Tracking/spying elements in email messsages are usually intended to spy on > the *recipient* - did the recipient read the email at all, did he clicked > on a link in the email etc. ...mail server logs would be one obvious angle, but even that would require additional effort to extract the target user's eMail activity since mail server logs cycle through pretty quickly (at least on a lot of busy Linux systems, anyway). Log retention is generally used for troubleshooting, so a long-term retention usually isn't needed. Another method is for a malicious sender to deceptively include tracking software in an attachment. Most security software stops this, which includes security daemons on mail servers that can also be combined with blacklists of IP addresses and/or domain names that distribute malicious eMails or are otherwise-infected systems that can be used to commit such types of SMTP abuse. > On the other hand, DKIM signature identifies the *sender* of the message. That's the reason we use DKIM, and we reject DKIM-detectable forgeries to make eMail safer for our users, which is also helpful to other mail server operators who put the effort into setting up SPF, DMARC, and DKIM to protect the domains they're responsible for. > What does one have to do with the other and to the discussion about > publishing keys (the latter - to my understanding - serves only possible > legal purposes in case the sender needs to deny the fact that he sent the > message, which for me is a completely made-up scenario, an absolute > fiction). Some of our clients are investigators, lawyers, etc., who occasionally need high quality (read "reliable") evidence for the cases they're working on. DKIM, when available, makes it easier to authenticate eMail evidence in a way that can satisfy these needs. While this doesn't happen very often, I'd say that, since its inception, DKIM-based authenticity has moved from being a completely made-up scenario to having some actual utility. The most compelling case for me though is that users typically don't want to contend with forgeries of known vendors and other parties they routinely interact with, so rejecting all detectable forgeries with the help of SPF and DKIM is a solution that works well. > I cannot understand what topic you're actually discussing in this thread. It was probably just a misunderstanding of the uses of DKIM. > -- > Regards, >Jaroslaw Rafa >r...@rafa.eu.org > -- > "In a million years, when kids go to school, they're gonna know: once there > was a Hushpuppy, and she lived with her daddy in the Bathtub." > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
