Ability to see the messages sent

[dcodesdev]

Description

Currently, the campaigns only show how many emails have been sent (e.g. 140/1000) but there is no way to know, who received it and who didn't?

It would be nice to have another tab just like we have to subscribers, campaigns, etc. But this one for messages and have all the details specific to that email (sent at, to whom, etc.)

This feature can be disabled by default so that users don't get surprised with their database being full all of a sudden.

[MaximilianKohler]

Yes, I think this would be nice and relatively easy, since listmonk sends out the email in reverse order of the list (IE: go to the last page of the subscriber list for the campaign, and it sends to the last subscriber first).

I don't see why it would need to add any extra data to the database.

[knadh]

Yes, I think this would be nice and relatively easy, since listmonk sends out the email in reverse order of the list

This wouldn't capture e-mails that failed in the middle though.

[MaximilianKohler]

This wouldn't capture e-mails that failed in the middle though.

Wouldn't it be fairly simple to mark or subtract the failed ones? They're already logged so it seems like it would be simple.

[AlejandroRodino]

@dcodesdev did you find a solution for this?

[dcodesdev]

@AlejandroRodino I use postal as my SMTP server, I can see the messages there, but on ListMonk I can not see them as there's no workaround. This is a feature that can be implemented by the ListMonk team, and I think it is necessary for it to have a separate database table for the messages that save all the data related to that message, including the recipient, the final rendered message HTML, timestamps, bounced, etc.

[MaximilianKohler]

I think it is necessary for it to have a separate database table for the messages that save all the data related to that message, including the recipient, the final rendered message HTML, timestamps, bounced, etc.

I think it hasn't been done because it would greatly increase the size of the database and they're trying to keep it lightweight. But an option to enable/disable would give people the choice themselves. It could include a warning that enabling it greatly increases the database size.

[dcodesdev]

@MaximilianKohler Yes that would be great