Skip to content
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

Add a List-Id and List-Unsubscribe on emails sent to x.net groups #22

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Ekleog
Copy link
Member

@Ekleog Ekleog commented Dec 12, 2016

I just received such an email, and there is no appropriate header, making hard to filter on these.

@fishilico
Copy link
Member

This approach hides a more important problem: when a group administrator sends an email through polytechnique.net, the information of the mailing list it selected (and why people receive the email) is lost. This is because the ML are currently expanded in get_all_redirects, in https://github.com/Polytechnique-org/platal/blob/xorg/1.1.22/modules/xnetgrp/mail.inc.php#L24

It is better to fix Mailman configuration to include List-Id and List-Unsubscribe and to make the website sends mails to Mailman instead of expanding the lists.

@Ekleog
Copy link
Member Author

Ekleog commented Dec 24, 2016

Indeed, I had completely forgotten that groups can have multiple MLs.

So, for mailman, it looks like it should include the List-Id header by default? Unless [ML].include_rfc2369_headers is set to False somewhere, that is: https://pythonhosted.org/mailman/src/mailman/handlers/docs/rfc-2369.html

@eltrai
Copy link
Member

eltrai commented Jan 27, 2017

After discussion, I now believe that a mixed approach would be better.

First, current and new ML needs to be corrected to include List-* headers (this is the sense of PR #25)
Then, we are given a choice between three options:

  1. Make it so platal doesn't expand ML and relies on mailman. This is cleaner in term of sending, but will prevent any per-user customization (Dear, FirstName, LastName). Also such a message would have to be moderated unless we take steps in mailman to setup a bypass (doable).
  2. Continue to expand ML and mimic the List-* header that would have been included if it went through mailman. Note that List-post in particular should not be included (no reply to list is intended for a newsletter). This leaves php in charge of mailing (with the timing issues) but allows per-user customization. It will also require a severe shuffling of the current code (that forget which user is part of which ML).
  3. Go on with the current proposal (custom List-Id for the newsletter).

Personally, I feel 2 is the better option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants