Mat H

Hello, We've identified an issue with emails sent by the Nexus Support system in the latest version which causes two Message-ID headers to be sent and the emails to be rejected. When adding a unique Message-ID header in the following locations, "Message-Id" was used as the header key rather than "Message-ID"; this causes SMTP::_send to fail its check for the header and add an additional one due to the difference in casing ("Message-Id" is used in Nexus, "Message-ID" is required by _send): /applications/nexus/sources/Support/Reply.php - line 467 /applications/nexus/extensions/IncomingEmail/Support.php - line 411 /applications/nexus/tasks/supportAutoresolve.php - line 73 The relevant check for the header in SMTP::_send is at /system/Email/Outgoing/Smtp.php - line 200. An example of a bad SMTP log resulting from this behavior is below: [redacted authentication] > MAIL FROM:<noreply@...> 250 Ok > RCPT TO:<...@gmail.com> 250 Ok > DATA 354 End data with <CR><LF>.<CR><LF> > MIME-Version: 1.0 To: ...@gmail.com From: ... <noreply@...> Subject: ... Date: Sat, 30 Nov 2024 11:03:37 +0000 Auto-Submitted: auto-generated Content-Type: multipart/alternative; boundary="--==_mimepart_24b8bb3600bde6b440df029b69cccd0d"; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-Id: <IPS-0-SR00000.AB1-noreply@...> Message-ID: eilo88vhvpk404sgc0gg0ko0@... ----==_mimepart_24b8bb3600bde6b440df029b69cccd0d Content-Type: text/plain; charset=UTF-8 [email contents] 554 Transaction failed: Duplicate header 'Message-ID'.

Hello, Some members of our website have been experiencing an issue with the Calendar where requests take 60+ seconds to process and eventually time out. We observed that this issue was occurring under the following conditions: A calendar event was created with TZ America/Chicago, repeats Every Week, and occurs on Saturday & Sunday at 8:00 PM. A member in the Australia/Brisbane (or other larger UTC offsets) visits any part of the Calendar in Monthly view or visits the aforementioned event page. We identified that this was occurring due to a bug in /applications/calendar/sources/Event/Event.php, line 462 in the most recent version, though it has been an issue for a while. When the day index is calculated for the difference in time zones, it does not correctly account for time zone differences that may push an event back from Saturday (local to the Event's TZ) to Sunday (local to the User's TZ), and this error ends up indexing the days array improperly and pushing a NULL into $_repeatDays which causes an infinite loop later on (the loop at line 497). To fix this issue, we've just modified the code to wrap $lookup back to 0 when the day is offset from Saturday to Sunday ([ $lookup % 7 ]); our users report that the issue is resolved and the Calendar appears accurate to their time zone.