abompard
commented
3 months ago This time the situation is actually quite different: the SMTP server in the Fedora Infra has had an expired TLS certificate for a few days, delaying the sending of the email notifications. They stayed in the queue until a connection could be established, which lasted a few days, and it's only when being sent out that the Date header is added. That's where we can do something better: a Date header should be added when the notification is generated, not when it's sent. I think this should be done in destination.py by adding the corresponding header.
Rombobeorn
Like its predecessor, the new notification system can send emails several days after the event happened. Those emails seem to be dated when the notification was converted to email form, and contain no information about when the event happened. The misleading timestamp makes it difficult to figure out whether something actually happened, or whether the notification pertains to an old event that I already know about. (Notifications about Git pushes contain a timestamp in the message body, but I think that's Git's "commit date" or "author date", not the time when the commit was pushed.)
The Date header field in the email should be set to the time when the event happened, not the time when the notification was converted from Fedora messaging form to email form.
According to RFC 5321 the gateway that converts the notification to email form must add a Received field. That's the field that shall contain the time when the conversion happened: https://datatracker.ietf.org/doc/html/rfc5321#section-3.7.2 https://datatracker.ietf.org/doc/html/rfc5321#section-4.4