Hello all!
Currently Fedora mailing lists use "From" field from original messages and if sender's domain use DMARC=reject policy, mailing lists subscribers cannot receive any messages from such users because their MX servers follow DMARC procedure and drop them.
Previously I opened ticket in Fedora Infra[1].
Someone need to fix this because more and more mailing servers starts enforcing DMARC=reject.
[1]: https://pagure.io/fedora-infrastructure/issue/7737
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org)
* Vitaly Zaitsev:
Currently Fedora mailing lists use "From" field from original messages and if sender's domain use DMARC=reject policy, mailing lists subscribers cannot receive any messages from such users because their MX servers follow DMARC procedure and drop them.
Previously I opened ticket in Fedora Infra[1].
Someone need to fix this because more and more mailing servers starts enforcing DMARC=reject.
Can we, as recipients, please opt out if know that our mail receiving policy is fully compatible with mailing lists?
Thanks, Florian
On 4/30/19 4:46 AM, Vitaly Zaitsev wrote:
Hello all!
Currently Fedora mailing lists use "From" field from original messages and if sender's domain use DMARC=reject policy, mailing lists subscribers cannot receive any messages from such users because their MX servers follow DMARC procedure and drop them.
Which explains why DMARC is horrible. ;)
Previously I opened ticket in Fedora Infra[1].
Someone need to fix this because more and more mailing servers starts enforcing DMARC=reject.
Which means more and more things break...
I guess I will enable the From field mitigation for this list, but I will not like it. ;)
kevin
Kevin Fenzi writes:
On 4/30/19 4:46 AM, Vitaly Zaitsev wrote:
Hello all!
Currently Fedora mailing lists use "From" field from original messages and if sender's domain use DMARC=reject policy, mailing lists subscribers cannot receive any messages from such users because their MX servers follow DMARC procedure and drop them.
Which explains why DMARC is horrible. ;)
No, it explains why p=reject domains that post to mailing lists are horrible. DMARC is a good thing when used properly.
Previously I opened ticket in Fedora Infra[1].
Someone need to fix this because more and more mailing servers starts enforcing DMARC=reject.
Which means more and more things break...
I guess I will enable the From field mitigation for this list, but I will not like it. ;)
It's possible to do this only for domains that advertise p=reject. They deserve what they get.
If there are any issues that seem like they can be addressed in upstream GNU Mailman (unfortunately, we don't carry a stick big enough to convince blockheaded mail domains not to publish p=reject), let me know and I'll push it with the Mailman devs. No promises, of course.
Steve GNU Mailman
On 5/1/19 12:06 PM, Björn Persson wrote:
Stephen J. Turnbull wrote:
Kevin Fenzi writes:
I guess I will enable the From field mitigation for this list, but I will not like it. ;)
It's possible to do this only for domains that advertise p=reject.
Yes please, don't break things more than what's necessary.
Yes, that is what I did. From mangling only applies to those domains that set a DMARC policy of reject or quarantine. I did not enable this globally.
kevin
* Stephen J. Turnbull:
It's possible to do this only for domains that advertise p=reject. They deserve what they get.
If there are any issues that seem like they can be addressed in upstream GNU Mailman (unfortunately, we don't carry a stick big enough to convince blockheaded mail domains not to publish p=reject), let me know and I'll push it with the Mailman devs. No promises, of course.
Gmail *recipients* (which includes most redhat.com subscribers these days) need this rewriting as well. Discarding mail is always a policy decision carried out by the recipient, so it needs to be configurable for mailing list subscribers. The mailing list server cannot detect this recipient behavior automatically.
The DMARC policy set by the sender does not really matter here. People tell you differently, but they are misinformed because the discard policy is implemented by the recipient, not the sender.
Thanks, Florian
On 02/05/2019 09:21, Florian Weimer wrote:
- Stephen J. Turnbull:
It's possible to do this only for domains that advertise p=reject. They deserve what they get.
If there are any issues that seem like they can be addressed in upstream GNU Mailman (unfortunately, we don't carry a stick big enough to convince blockheaded mail domains not to publish p=reject), let me know and I'll push it with the Mailman devs. No promises, of course.
Gmail *recipients* (which includes most redhat.com subscribers these days) need this rewriting as well. Discarding mail is always a policy decision carried out by the recipient, so it needs to be configurable for mailing list subscribers. The mailing list server cannot detect this recipient behavior automatically.
No, but if the mailing list server rewrites when the sender has a reject policy then the email gmail receives will no longer violate the policy so they won't put it in the spam folder.
The DMARC policy set by the sender does not really matter here. People tell you differently, but they are misinformed because the discard policy is implemented by the recipient, not the sender.
Yes, but based on what the sender requests.
Tom
* Tom Hughes:
On 02/05/2019 09:21, Florian Weimer wrote:
- Stephen J. Turnbull:
It's possible to do this only for domains that advertise p=reject. They deserve what they get.
If there are any issues that seem like they can be addressed in upstream GNU Mailman (unfortunately, we don't carry a stick big enough to convince blockheaded mail domains not to publish p=reject), let me know and I'll push it with the Mailman devs. No promises, of course.
Gmail *recipients* (which includes most redhat.com subscribers these days) need this rewriting as well. Discarding mail is always a policy decision carried out by the recipient, so it needs to be configurable for mailing list subscribers. The mailing list server cannot detect this recipient behavior automatically.
No, but if the mailing list server rewrites when the sender has a reject policy then the email gmail receives will no longer violate the policy so they won't put it in the spam folder.
Based on some reports, I don't think this is how the Gmail implementation works. It will discard mailing list mail for senders with a DMARC policy that does not set p=reject, too.
Thanks, Florian
Florian Weimer writes:
Based on some reports, I don't think this is how the Gmail implementation works. It will discard mailing list mail for senders with a DMARC policy that does not set p=reject, too.
Based on conversations with GMail developers, that has nothing to do with DMARC, though. A proper mailing list *also* signs its messages, and it develops a reputation much faster than any individual poster. (It's also more dangerous than individual posters, so that may or may not balance out exactly.) As far as GMail is concerned, therefore, a post by such a user has a valid signature, but the treatment of the post depends only on the reputation of the mailing list and the content of the post, rather than on the reputations of the poster and the list, and the content. Note that this is the same distinction that occurs when the list munges From.
Bottom line: I don't think a per-subscriber option is likely to help subscribers who are GMail users (in general, if you don't own your own MX), and for reasons I've given elsewhere, I think providing a per-subscriber option is likely to be a PITA for list admins (== my primary constituency as a GNU Mailman developer).
Steve
Hello, Kevin Fenzi.
Wed, 1 May 2019 08:43:23 -0700 you wrote:
I guess I will enable the From field mitigation for this list, but I will not like it.
Now it should work fine. Thanks.
I think it should be an option in mailman's settings. Each user can enable or disable mitigations for his email address.
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org)
Vitaly Zaitsev via devel writes:
I think it should be an option in mailman's settings. Each user can enable or disable mitigations for his email address.
Patches welcome at GNU Mailman.
Potential time waste warning: The list owner must have the choice whether to delegate the choice to subscribers. As a list owner, I wouldn't allow that choice by subscribers, because I'd end up getting the crap when people who didn't understand what was going on disabled the "ugly" From munging and started losing mail and getting delivery disabled or even unsubscribed from lists. As a Mailman developer, I will strongly oppose turning on user choice by default because my constituents are list owners, not subscribers. But that implies it would be rarely available.
On the other hand, I would support giving users the option to choose their mitigation (From munging vs. wrapping), and turn that on by default when mitigation is enabled. Probably only relevant to Gnus users, though, as nobody else can conveniently read the wrapped messages. ;-)
Steve
Hello, Stephen J. Turnbull.
Sun, 5 May 2019 05:58:48 +0900 you wrote:
As a Mailman developer, I will strongly oppose turning on user choice by default because my constituents are list owners, not subscribers. But that implies it would be rarely available.
That's why it's time to deprecate all mailing lists and switch to modern Web 2.0 platforms.
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org)
On May 4, 2019 11:04:51 PM GMT+02:00, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
Hello, Stephen J. Turnbull.
Sun, 5 May 2019 05:58:48 +0900 you wrote:
As a Mailman developer, I will strongly oppose turning on user choice by default because my constituents are list owners, not subscribers. But that implies it would be rarely available.
That's why it's time to deprecate all mailing lists and switch to modern Web 2.0 platforms.
Exactly what platform did you have in mind?
While mailing lists aren't sexy they work very well and shuffle data like few other services.
Br Q
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Hello, qrsBRWN.
Sun, 05 May 2019 10:57:06 +0200 you wrote:
Exactly what platform did you have in mind?
Discourse[1] for example. GTK developers already testing it[2] as mailing lists replacement.
1: https://github.com/discourse/discourse 2: https://blog.gtk.org/2019/03/05/testing-discourse-for-gtk/
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org)
On Sun, 5 May 2019 14:19:59 +0200 Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
Hello, qrsBRWN.
Sun, 05 May 2019 10:57:06 +0200 you wrote:
Exactly what platform did you have in mind?
Discourse[1] for example. GTK developers already testing it[2] as mailing lists replacement.
1: https://github.com/discourse/discourse 2: https://blog.gtk.org/2019/03/05/testing-discourse-for-gtk/
To each their own, of course, but there was a long discussion of discourse here a while ago. I tried it out, but it was like a bad version of a mailing list. It sent me a mail informing me that there were messages to read. Then I had to go there and read the messages on the web, using their interface.
So much better than just getting the message directly into my chosen mail client! (/sarcasm) It probably works well for those who are addicted to the web, and check their phone every few minutes; it fits with their work style, plus they get affirmation. But I don't fit that template, so I wasn't enamored.
If forced to, I could probably use it, but I prefer the push model to the pull model. That is, it isn't an improvement for me, it doesn't buy me anything I want.
On Sunday, May 5, 2019 3:43:02 PM EDT stan via devel wrote:
On Sun, 5 May 2019 14:19:59 +0200 Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
Hello, qrsBRWN.
Sun, 05 May 2019 10:57:06 +0200 you wrote:
Exactly what platform did you have in mind?
Discourse[1] for example. GTK developers already testing it[2] as mailing lists replacement.
1: https://github.com/discourse/discourse 2: https://blog.gtk.org/2019/03/05/testing-discourse-for-gtk/
[snip]
If forced to, I could probably use it, but I prefer the push model to the pull model. That is, it isn't an improvement for me, it doesn't buy me anything I want.
+1
On May 5, 2019 9:43:02 PM GMT+02:00, stan via devel devel@lists.fedoraproject.org wrote:
On Sun, 5 May 2019 14:19:59 +0200 Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
Hello, qrsBRWN.
Sun, 05 May 2019 10:57:06 +0200 you wrote:
Exactly what platform did you have in mind?
Discourse[1] for example. GTK developers already testing it[2] as mailing lists replacement.
1: https://github.com/discourse/discourse 2: https://blog.gtk.org/2019/03/05/testing-discourse-for-gtk/
To each their own, of course, but there was a long discussion of discourse here a while ago. I tried it out, but it was like a bad version of a mailing list. It sent me a mail informing me that there were messages to read. Then I had to go there and read the messages on the web, using their interface.
I have used Discourse and yes it does behave pretty much like a webforum from 90s.
So much better than just getting the message directly into my chosen mail client! (/sarcasm) It probably works well for those who are addicted to the web, and check their phone every few minutes; it fits with their work style, plus they get affirmation. But I don't fit that template, so I wasn't enamored.
If forced to, I could probably use it, but I prefer the push model to the pull model. That is, it isn't an improvement for me, it doesn't buy me anything I want.
Exactly this. While swanky it really does nothing new but takes away accessibility since there will be a gazillion email notifications which in and of themselves are useless. With a mailing list I can just reply directly instead of having to switch to a different interface.
This just adds a step and forces me to use a particular client.
I realized now that this mail sounds really negative. To add nuance: great suggestion and I'm all for changing things if the new things solves the problem better than the old things. Discourse however, doesn't seem to do that.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Sun, May 05, 2019 at 12:43:02PM -0700, stan via devel wrote:
To each their own, of course, but there was a long discussion of discourse here a while ago. I tried it out, but it was like a bad version of a mailing list. It sent me a mail informing me that there were messages to read. Then I had to go there and read the messages on the web, using their interface.
That's definitely the primary intended mode of interaction, but there is also a "mailing list mode" which does more of what you want. (One email per post, and you can reply directly.)
Matthew Miller writes:
On Sun, May 05, 2019 at 12:43:02PM -0700, stan via devel wrote:
To each their own, of course, but there was a long discussion of discourse here a while ago. I tried it out, but it was like a bad version of a mailing list. It sent me a mail informing me that there were messages to read. Then I had to go there and read the messages on the web, using their interface.
That's definitely the primary intended mode of interaction,
To be fair, that's *one* intended mode of interaction, when Discourse is used as an adjunct to a blog platform. As a substitute for "devel" or "users", I would expect that it would sit there in a window (or windows) of your browser pretty much always visible, or on the next desktop, and there'd be a "bomb crater" emoji instead of the switch for turning notifications on.
I could see using it in a "users" style forum, where I'd use it like Twitter: wander in, see if there was anything interesting, if there were a post or two with insufficient answers I'd provide what help I could, and then come back next week and do the same. I wouldn't want to use it in a "devel" forum, but that's likely *mostly* because I have a complex set of customizations for dealing with my devel forums in my mail client, and I'm pretty sure they won't be replicated in any web forum. I would probably eventually come up with alternatives and workarounds, but for many months I would be in A Very Bad Bad Mood, and Extremely Unpleasant to Be Around. :-)
This should not be considered advocacy one way or the other vis-a-vis Fedora channels -- I'm here more or less by accident, but if GNU Mailman can provide better support to the Fedora community I'd like to push that forward.
but there is also a "mailing list mode" which does more of what you want. (One email per post, and you can reply directly.)
Which ain't so great. Not for the person who likes mailing lists, and not for the people who like discourse as a platform. It's partly social, of course, but there's also the technological difference between synchronous and asynchronous messaging. Platforms designed for synchronous messaging tend to have longer "conversations", whereas ansynchronous messaging tends to result in branchy thread trees.
Much as I love mailing lists, I admit that there are valid arguments and personal preferences for web fora. This is going to be one of those situations where it kinda has to be tyranny of some kind, maybe the tyranny of inertia, maybe tyranny of the majority. But some people (fvo "some" including "many") will be dissatisfied.
Steve
On 5/4/19 11:04 PM, Vitaly Zaitsev via devel wrote:
That's why it's time to deprecate all mailing lists and switch to modern Web 2.0 platforms.
I swear I've intended this as a joke, before reading replies and realizing it was supposed to be serious.
Regards.
-
Björn Persson -
Florian Weimer -
Garry T. Williams -
Kevin Fenzi -
Matthew Miller -
qrsBRWN -
Roberto Ragusa -
stan -
Stephen J. Turnbull -
Tom Hughes -
Vitaly Zaitsev