Skip to content

Threaded email notifications by adding missing mail headers #2645

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

Closed
mxmehl opened this issue Oct 3, 2017 · 5 comments
Closed

Threaded email notifications by adding missing mail headers #2645

mxmehl opened this issue Oct 3, 2017 · 5 comments
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/enhancement An improvement of existing functionality
Milestone

Comments

@mxmehl
Copy link

mxmehl commented Oct 3, 2017

Description

Currently, the email notifications lack some headers which would make them easier to read and follow in mail clients. Even in a modern MUA the notification mails aren't shown in a thread like with Github mails.

This is because following headers are missing (from a mail of a Github pull request):

  • Message-ID: <astroidmail/astroid/pull/412/push/2025975904@github.com>
  • In-Reply-To: <astroidmail/astroid/pull/412@github.com>
  • References: <astroidmail/astroid/pull/412@github.com>

While the message-id isn't required to allow the threaded view it's part of a valid email layout.

@mxmehl mxmehl changed the title Threaded email notifications due to missing mail headers Threaded email notifications by adding missing mail headers Oct 3, 2017
@mxmehl
Copy link
Author

mxmehl commented Oct 3, 2017

Other interesting issues along the lines of improved email notifications:

#745, #2386, #2141, #1885, #1883, #1464, #145

@lafriks lafriks added the type/enhancement An improvement of existing functionality label Oct 3, 2017
@lafriks lafriks added this to the 1.x.x milestone Oct 3, 2017
@stale
Copy link

stale bot commented Feb 12, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale stale bot added the issue/stale label Feb 12, 2019
@techknowlogick techknowlogick added issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented and removed issue/stale labels Feb 12, 2019
@ptman
Copy link
Contributor

ptman commented Feb 12, 2019

can message IDs be anything or do they need to confirm to a specific format?

@mxmehl
Copy link
Author

mxmehl commented Mar 20, 2019

can message IDs be anything or do they need to confirm to a specific format?

Basically this is quite free to define accoridng to RFC 2392 as long as every ID is globally unique. But in order to enable the tree structure, it should follow a certain form.

Github seems to do it as follows:

  • First message: Message-ID: <$UserOrOrg/$reponame/$type/$number@$domain>, so e.g. astroidmail/astroid/pull/570@github.com
  • Following replies:
    • Message-ID: <astroidmail/astroid/pull/570/issue_event/2191656010@github.com>, where the number is the comment ID
    • In-Reply-To: <astroidmail/astroid/pull/570@github.com>, so the Message-ID of the first post
    • References: <astroidmail/astroid/pull/570@github.com>, so the Message-ID of the first post

As you can see, no need to create new random strings, as the Gitea domain, the user/repo name, the pull/issue number, and the comment ID will make every Message-ID unique.

The missing Message-ID also causes Gitea's mails to be caught by more and more spam filters.

@mxmehl
Copy link
Author

mxmehl commented Jul 25, 2019

Closed by #7484 as it seems. Thanks @mrsdizzie !

@mxmehl mxmehl closed this as completed Jul 25, 2019
@lunny lunny modified the milestones: 1.x.x, 1.10.0 Jul 25, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/enhancement An improvement of existing functionality
Projects
None yet
Development

No branches or pull requests

5 participants