[GH-ISSUE #317] POP3 server: have option to not delete emails right away #208

New issue

Closed

opened 2026-03-15 13:13:44 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 13:13:44 +03:00

Owner

Originally created by @antonionardella on GitHub (Jun 20, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/317

Hello again @axllent

for some debugging I needed to keep the emails in the POP3 server even if the client tells to delete them.

Let me know if it is of interest for you

I added the functionality here:
https://github.com/axllent/mailpit/compare/develop...antonionardella:mailpit:no-delete

And also updated the documentation here:
https://github.com/axllent/mailpit-website/compare/develop...antonionardella:mailpit-website:patch-1

If it is making more of a mess than anything, feel totally free to ignore this issue.

Best,
Antonio

Originally created by @antonionardella on GitHub (Jun 20, 2024). Original GitHub issue: https://github.com/axllent/mailpit/issues/317 Hello again @axllent for some debugging I needed to keep the emails in the POP3 server even if the client tells to delete them. Let me know if it is of interest for you I added the functionality here: https://github.com/axllent/mailpit/compare/develop...antonionardella:mailpit:no-delete And also updated the documentation here: https://github.com/axllent/mailpit-website/compare/develop...antonionardella:mailpit-website:patch-1 If it is making more of a mess than anything, feel totally free to ignore this issue. Best, Antonio

kerem closed this issue

2026-03-15 13:13:49 +03:00

kerem commented

2026-03-15 13:13:55 +03:00

Author

Owner

@axllent commented on GitHub (Jun 20, 2024):

HI again @antonionardella. I'm afraid this option would break RFC compliance for the POP3 server. The POP3 client would tell the server to delete the messages, and the server would just ignore it. This means that next time the client connects it believes the messages are new and downloads them again and again etc.

The POP3 client protocol already has an option not to delete (simply by not telling the server to delete) - which is typically the option to "leave messages on server" (or "leave messages on server for X days") found in most mail clients. What am I missing here?

@axllent commented on GitHub (Jun 20, 2024): HI again @antonionardella. I'm afraid this option would break RFC compliance for the POP3 server. The POP3 client would tell the server to delete the messages, and the server would just ignore it. This means that next time the client connects it believes the messages are new and downloads them again and again etc. The POP3 client protocol already has an option **not** to delete (simply by not telling the server to delete) - which is typically the option to "leave messages on server" (or "leave messages on server for X days") found in most mail clients. What am I missing here?

kerem commented

2026-03-15 13:14:00 +03:00

Author

Owner

@antonionardella commented on GitHub (Jun 20, 2024):

No worries, I thought about that
The issue is that zammad is deleting messages every 30 seconds, which removed the ability to debug and read texts (if one is not quick enough 🤣)

As of Zammad it depends on the server configuration https://community.zammad.org/t/emails-are-deleted-from-my-inbox-when-using-it-as-channel/4419/2?u=skip

Therefore I added a debug flag on my fork to keep messages anyway, at least for debugging reasons.

No worries at all. Let me close this issue then.

Thank you for your time and availability!

@antonionardella commented on GitHub (Jun 20, 2024): No worries, I thought about that The issue is that zammad is deleting messages every 30 seconds, which removed the ability to debug and read texts (if one is not quick enough 🤣) As of Zammad it depends on the server configuration https://community.zammad.org/t/emails-are-deleted-from-my-inbox-when-using-it-as-channel/4419/2?u=skip ![image](https://github.com/axllent/mailpit/assets/7383572/f3e3f317-0f13-446c-aa5f-f3adab4e3611) Therefore I added a _debug_ flag on my fork to keep messages anyway, at least for debugging reasons. No worries at all. Let me close this issue then. Thank you for your time and availability!

kerem commented

2026-03-15 13:14:05 +03:00

Author

Owner

@axllent commented on GitHub (Jun 20, 2024):

No problem. I really hate saying "no", especially when a user provides a PR, but I have to be careful not to add custom non-compliant features because it adds more options, and more code to maintain (and possibly confuse other users with) :)

@axllent commented on GitHub (Jun 20, 2024): No problem. I really hate saying "no", especially when a user provides a PR, but I have to be careful not to add custom non-compliant features because it adds more options, and more code to maintain (and possibly confuse other users with) :)