New external users sometimes don't receive confirmation mails
-
Hey,
I've been running a small-ish Mastodon server on Cloudron since November. So far it's been a good experience, with one exception: External users are sometimes unable to sign up, both through the application interface on Mastodon and through invite links, because they simply do not receive a confirmation email to activate their account. This is not specific to any provider and I haven't been able to reproduce it. But it happens about half the time with new accounts. They still show up in the instance's moderation interface but are greyed out and their login status is "Confirming".
Has anyone run into a similar issue? Is there a solution to this?
-
Can you check the email event log and mail queue, if the app has sent the email but there was a delivery issue? https://docs.cloudron.io/email/#event-log
-
@nebulon Email event log says it's been sent successfully, mail queue is empty. I sent myself a test email with no issue as well. Again, this happens like 50% of the time, is not provider-specific and is not reproducible by me. Just a genuine headscratcher.
Log dump below
Jan 23 15:26:36 [NOTICE] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2] [core] connect ip=0000:0000:0000::8 port=50386 local_ip=0000:0000:0000::8 local_port=2525 Jan 23 15:26:36 [ERROR] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2] [limit] no karma results, disabling history due to misconfiguration Jan 23 15:26:36 [INFO] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2] [helo.checks] skip:proto_mismatch(private) Jan 23 15:26:36 [INFO] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2] [cloudron] Authenticated as mastodon.app@fruef.social Jan 23 15:26:36 [INFO] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2] [core] hook=unrecognized_command plugin=cloudron function=hook_unrecognized_command params=AUTH retval=OK msg="" Jan 23 15:26:37 [NOTICE] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1] [core] sender <mastodon.app@fruef.social> code=CONT msg="" Jan 23 15:26:37 [ERROR] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1] [limit] no karma results, disabling history due to misconfiguration Jan 23 15:26:37 [INFO] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1] [delay_deny] bypassing all pre-DATA deny: AUTH/RELAY Jan 23 15:26:37 [NOTICE] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1] [core] recipient <hello@example.com> code=OK msg="" sender=mastodon.app@fruef.social Jan 23 15:26:37 [INFO] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1] [cloudron] final rcpt list is ["<hello@example.com>"] Jan 23 15:26:37 [NOTICE] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1] [core] message mid=<63ce991b1dd28_f8b71b4ce805904e@fruef.social> size=24906 rcpts=1/0/0 delay=0.035 code=CONT msg="" Jan 23 15:26:37 [INFO] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1] [dkim_sign] signed for fruef.social Jan 23 15:26:37 [NOTICE] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1] [core] queue code=CONT msg="Message Queued (67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1)" Jan 23 15:26:37 [INFO] [-] [core] [outbound] Sending email as a transaction Jan 23 15:26:37 [INFO] [-] [core] [outbound] Processing delivery for domain: example.com Jan 23 15:26:37 [NOTICE] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1] [core] queue code=OK msg="Message Queued (67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1)" Jan 23 15:26:37 [INFO] [-] [core] loading tls.ini Jan 23 15:26:37 [NOTICE] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1] [core] disconnect ip=0000:0000:0000::8 rdns=55400778-5803-4b5c-baca-4377b100d2ee.cloudron helo=fruef.social relay=Y early=N esmtp=Y tls=N pipe=N errors=0 txns=1 rcpts=1/0/0 msgs=1/0/0 bytes=24906 lr="" time=1.012 Jan 23 15:26:37 [INFO] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1.1] [outbound] Looking up A records for: gmail-smtp-in.l.google.com Jan 23 15:26:37 [INFO] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1.1] [outbound] Attempting to deliver to my.fruef.social: 000.000.00.00:00 (0) (0) Jan 23 15:26:37 [INFO] [-] [core] [outbound] acquired socket E5530D50-B96A-4CB8-8936-FDF9B1D00742 for outbound::000.000.00.00:00:undefined:300 Jan 23 15:26:37 [INFO] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1.1] [outbound] secured verified=true cipher=TLS_AES_256_GCM_SHA384 version=TLSv1.3 cn=mx.google.com organization="" issuer="Google Trust Services LLC" expires="Mar 27 08:18:41 2023 GMT" fingerprint=00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Jan 23 15:26:38 [NOTICE] [67C83C19-4C9F-47A8-BDC2-5CD11608A6F2.1.1] [outbound] delivered file=1674483997227_1674483997227_0_244_XqxCax_1_b952383e70eb domain=gmail.com host=gmail-smtp-in.l.google.com ip=142.250.27.27 port=25 mode=SMTP tls=Y auth=N response="OK 1674483998 wy10-20020a170906fe0a00b0084d37a7d9casi28443416ejb.187 - gsmtp" delay=1.429 fails=0 rcpts=1/0/0 -
This then appears to be an issue on the receiving email server. Most probably issue is, that the receiving server marks the emails as spam. For new servers it sometimes takes some longer time for the IP address reputation to go up.
-
@dxciBel said in New external users sometimes don't receive confirmation mails:
Has anyone run into a similar issue?
Are you using LDAP?
Is there a solution to this?
Not really if using LDAP, doesn't play well with external users. I hit this previously, search previous posts. I think @nebulon created an upstream issue about it
-
@dxciBel It looks like you have an "example.com" somewhere set up for email sending.
-
@fredsarm I took out the actual email adress from the log, as well as IPs. But good catch, that.
-
An idea would be to test if you can normal emails from Cloudron using the "Test email" to the same email ids and ask the receiver if they receive the test emails. This will isolate if it's a general mail delivery issue .
-
@girish I'll try that and report back!
-
@jdaviescoates said in New external users sometimes don't receive confirmation mails:
Are you using LDAP?
Not that I know of. User management was left to the app during install.
-
@dxciBel said in New external users sometimes don't receive confirmation mails:
Not that I know of. User management was left to the app during install.
Phew. I think you should be OK then! Ignore me.
