Solved "User does not exist" error when sending email in cycle using the updated Mailing Lists feature

[d19dotca]

I have encountered a problem and it seems reproducible. Would appear to be a bug in the workflow, I think. I have been able to reproduce it on different domains too.

To reproduce the issue:

1. Use Cloudron 4.2.6
2. Create a Mailing List like so:

• info@example.com > sales@example.com
• sales@example.com > dustin@example.com

3. Send email to info@example.com

You should receive an error about "User does not exist" when the email is sent. It seems like there is a limitation or defect where if I have one mailing list forward to another mailing list which then forwards to a final target email address, it fails to see the second one as a user. In other words, info@example.com will not forward to sales@example.com because it's another mailing list.

This may be useful in some circumstances, but my concern is that in real-world use-cases such as one where we have two domains and so I have info@example.com forward to info@secondexample.com where info@secondexample.com forwards to the intended target, it will fail. And the overhead that creates is that I then have to go into every domain and look at every user and ensure the final target is used rather than being allowed to forward to other mail lists. In such a case, I would have been able to just update one target email address in one location rather than possibly 10+ across different domains.

Hopefully the above makes sense. I find it difficult to explain. I'll try to clarify if anything is needed or if the above is confusing. Ultimately, and maybe my expectation is not realistic, but I would have expected it to basically "follow the ball" where it will go through each hoop it needs to, rather than failing right away to any other mailing list.

I assume this may have been implemented as a precaution to avoid infinite loops, but maybe in this situation it'd be better to allow it to still forward to other mailing lists but limit it to 5 deep or something to avoid infinite loops.

[girish]

This is indeed the case that we do not try to "resolve" more than once to prevent loops. Maybe we can have a depth as you suggested. Let me give it a shot and get back.

[d19dotca]

@girish Sounds good, yes please. I can understand why it was limited but I think limiting to just 1 is a bit aggressive in real-world use-cases. Would love to see it at at least 3 deep for resolution of the user, but preferably a few more.

[girish]

@d19dotca This is fixed in 4.3 (will be released in the coming days)