On Tue, Apr 11, 2023 at 12:12 PM ais523 via agora-discussion <agora-discussion@agoranomic.org> wrote: > > On Tue, 2023-04-11 at 13:54 -0500, nix via agora-discussion wrote: > > Your client itself will normally display the timestamp attached by the > > sending machine. This is usually assumed to be honest, but could > > actually be forged (to amusing results, such as pushing a new email way > > back in your inbox because it reports and old date, I believe ais523 or > > someone else actually did this for an email in the archives). The > > archives also use this date I believe. > > I've been known to forge email timestamps in the past, mostly just > because it's another fun corner of the Agoran rules to mess around > with. > > It is much harder nowadays than it used to be: the email system has a > lot more anti-forgery protection in it than it used to (the idea being > to make it hard for spammers to disguise where their messages are > coming from, thus making the spam easier to block), so if you try to > forge email timestamps the way I traditionally used to forge them, the > computers along the way are actually somewhat likely to notice > nowadays. > > It is, however, still possible. I could probably manage it if I really > wanted to, but (assuming that I wanted the timestamp to be believable) > the easiest way to get an email with a given timestamp on it would be > to actually send it at that specific time. (With automation, it isn't > too hard to send an email at a specific time, if you know in advance > that you're going to have to.) > > The *really* fun variant, which AFAIK has never been tested at Agora, > is to exploit the fact that the start of an email arrives before the > end of the email does – if the email is being sent over a sufficiently > slow connection, the end of the email can theoretically contain text > that was chosen based on reacting to things that have happened since > the email started to be received. In this case, I think the email > servers along the way might nonetheless use the timestamp of when the > email started to be sent, although I'm far from certain about this. > (Some of the modern anti-forgery features stop this working, > incidentally, because the proof that the email's body has not been > modified during transit appears in the email headers, which appear > before the body, so you have to have the whole thing written in advance > in order to be able to come up with a header and body that match each > other.)
It's worth adding a slightly-deeper concept that comes from CFJs - in CFJs, the term "Technical Domain of Control" (sometimes abbreviated TDOC) has been invented/used. The concept is that the best approximation of date/time is the moment when the sender loses control of the message (that is, the message leaves the sender's TDOC) and can't stop it from being received by the list. For standard email use on a single message, this is best approximated by (is closest to) the time of hitting the send button. So that's the ideal timestamp to use. Unfortunately, it's also the timestamp that's most forgeable - though maybe as ais523 says it's a less important concern these days, due to anti-forgery measures. For a "slow" message, it could be asked whether the sender can stop it partway through or not (whether it's left eir TDOC)? (we've also got an unresolved question on whether a message can be split over multiple emails - an old CFJ said it can, but I'm very doubtful that the precedent would seem reasonable if pushed very hard with the current ruleset). -G.
