> 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

Reply via email to