Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Temporary email alias": display of "valid until" and "created on" times inconsistent #6136

Open
5 tasks done
ralfbergs opened this issue Nov 3, 2024 · 3 comments
Open
5 tasks done
Labels

Comments

@ralfbergs
Copy link

Contribution guidelines

I've found a bug and checked that ...

  • ... I understand that not following the below instructions will result in immediate closure and/or deletion of my issue.
  • ... I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
  • ... I have understood that answers are voluntary and community-driven, and not commercial support.
  • ... I have verified that my issue has not been already answered in the past. I also checked previous issues.

Description

I created a temporary email alias with the default expiry of 1 yr. I then changed it to expire after 1 hr. I noticed that the "valid until" and "created on" times were 2 hrs apart.

Preconditions:
- Server time is UTC
- Client OS: macOS 14.7.1, TZ set to Germany (currently UTC+1)
- Browser: Firefox 132.0
- (In case it matters) Webmail: time display set TZ "Europe/Berlin", times are correctly displayed in local (German) time

Logs:

Won't help.

Steps to reproduce:

1. Create random alias for 1 yr
2. Note that at this time already, the display of "valid until" and "created on" times differs not only by 1 yr, but by "1 yr 1 h."
3. Select alias with checkbox
4. Click "Actions" > "Expire in 1 hour"
5. Note that the two times displayed ("valid until" and "created on") now differ by 2 hours.

Which branch are you using?

master

Which architecture are you using?

x86

Operating System:

Debian 12.7

Server/VM specifications:

AWS m5.large: 8 GB RAM, 2 vcores

Is Apparmor, SELinux or similar active?

no

Virtualization technology:

AWS EC2

Docker version:

27.3.1

docker-compose version or docker compose version:

v2.29.7

mailcow version:

2024-08a

Reverse proxy:

none

Logs of git diff:

[Key pairs REDACTED]

diff --git a/data/conf/postfix/main.cf b/data/conf/postfix/main.cf
index 6a87f2ec..50da62de 100644
--- a/data/conf/postfix/main.cf
+++ b/data/conf/postfix/main.cf
@@ -173,3 +173,32 @@ parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks

 # DO NOT EDIT ANYTHING BELOW #
 # Overrides #
+
+postscreen_dnsbl_sites = wl.mailspike.net=127.0.0.[18;19;20]*-2
+  hostkarma.junkemailfilter.com=127.0.0.1*-2
+  list.dnswl.org=127.0.[0..255].0*-2
+  list.dnswl.org=127.0.[0..255].1*-4
+  list.dnswl.org=127.0.[0..255].2*-6
+  list.dnswl.org=127.0.[0..255].3*-8
+  ix.dnsbl.manitu.net*2
+  bl.spamcop.net*2
+  bl.suomispam.net*2
+  hostkarma.junkemailfilter.com=127.0.0.2*3
+  hostkarma.junkemailfilter.com=127.0.0.4*2
+  hostkarma.junkemailfilter.com=127.0.1.2*1
+  backscatter.spameatingmonkey.net*2
+  bl.ipv6.spameatingmonkey.net*2
+  bl.spameatingmonkey.net*2
+  b.barracudacentral.org=127.0.0.2*7
+  bl.mailspike.net=127.0.0.2*5
+  bl.mailspike.net=127.0.0.[10;11;12]*4
+  [REDACTED].zen.dq.spamhaus.net=127.0.0.[4..7]*6
+  [REDACTED].zen.dq.spamhaus.net=127.0.0.[10;11]*8
+  [REDACTED].zen.dq.spamhaus.net=127.0.0.3*4
+  [REDACTED].zen.dq.spamhaus.net=127.0.0.2*3
+postscreen_dnsbl_reply_map = texthash:/opt/postfix/conf/dnsbl_reply.map
+
+# User Overrides
+myhostname = [REDACTED]
+recipient_delimiter = +-

Logs of iptables -L -vn:

not applicable

Logs of ip6tables -L -vn:

not applicable

Logs of iptables -L -vn -t nat:

not applicable

Logs of ip6tables -L -vn -t nat:

not applicable

DNS check:

not applicable
@ralfbergs ralfbergs added the bug label Nov 3, 2024
@apio-sys
Copy link

apio-sys commented Nov 3, 2024

This works for me testing with your steps just now:
Screenshot from 2024-11-03 12-11-42
But I have the server TZ same as client TZ that's probably where the difference comes from. You create in UTC (since working on the mailcow UI in server TZ) but you see the results in your local TZ.

@ralfbergs
Copy link
Author

Thanks for checking it.

I have no clue about how this is implemented "under the hood," but in any case these two times must be handled inconsistently somehow (on the server, in the client code), otherwise this wouldn't have occurred to me.

Maybe in one instance, the proper handling of TZ information does not take place (i.e. TZ is not properly considered when outputting the time), or TZ info gets lost when storing the date field? I can just guess here...

Is there anything I can do from my end to further narrow it down? Or should I just leave it to the devs to figure it out?

@ralfbergs
Copy link
Author

Here's an example of a default alias of 1 yr:

1yr

And here's the same alias, updated to be valid for 1 hr only:

1hr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants