Am I the only one who just received this email from this group? Which came with my password in the email in plain text?
Begin forwarded message:
24 thoughts on - Passwords In Plain Text
I got it as well.
Mee too
Il Ven 15 Giu 2018, 18:45 Larry Martell ha scritto:
This is a standard feature of GNU Mailman. You can disable the monthly password reminder in your user preferences (which is the same place you can change your password, if you are concerned that it was sniffed during the SMTP exchange).
The Mailman signup page warns you that the password will be emailed:
“You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext.”
–keith
Ah I see. That said, this email wasn’t a password reminder. It was a
“your membership has been disabled” email.
I also received the “has been disabled” notification. It looks like users with gmail addresses are affected.
CentOS admins are looking into this issue (I believe).
Akemi
Sounds like either CentOS-owner was cleaning up the subscription list or GMail was down for a while and bouncing everyone’s mail.
I believe this is a DMARC issue. Yahoo, among other places, has set their dmarc records to p=reject:
So, if your mail hosting provider enforces dmarc,(gmail does) and you get mail from a list that doesn’t rewrite the headers, and people from places like yahoo post to the list, you’ll likely get some form of warning about being being kicked off the mailing list every now and then. The frequency depends on how often people from p=reject places post, and what the settings are for bounce handling of the mailing list in question.
I believe that the current version of mailman can be configured to do the necessary header rewrites. Some lists I’m on only do the rewrites for headers of posts coming from p=reject sites (much less annoying than having them all rewritten).
I was thinking the same except I do not have enough knowledge in this area. In gmail’s header I often see DMARK “Fail”
Akemi
WRT mailing the password in clear text .. how else would it mail it?
Mailman does not store any kind of encryption keys for email, and frankly, most people don’t know how to use encrypted email. This list probably has a (much) higher percentage of people who would know how to use encrypted mail (ie, Linux users .. who are more computer literate than the average person). But, I don’t think mailman has sending administrative mails to users encrypted as an option.
WRT this issue .. several hundred gmail accounts (and few other accounts) were disabled at a specific time today. We don’t yet know exactly why this happened and before we mass reenable the accounts, we need to make sure it is not going to happen again.
Since so many of the mails are gmail.com accounts, this has to be something that gmail did today at 1530 GMT (when all the accounts were disabled) and the mails were sent).
We will try to figure out exactly what happened and get everything back to normal as soon as we can.
For this communication, not at all. The password was totally unnecessary. If I’d requested to have it sent, however, I now understand this system will email plain text passwords rather than a reset link etc. All good.
And good luck sorting out what happened today!
This is indeed what happened. An email from yahoo.com.uk caused gmail to reject all the mails sent by that user because of the yahoo DMARC
settings.
We have now set the mailing list to rewrite headers. That also has set the From: of the email to the Mailing list and not the Original Author. The author is moved to the CC: block and you can still easily see who sent it and my email client (thunderbird) still does things the same way
(reply to list sends to the list, reply sends to the original author).
This should prevent the yahoo/gmail (or other dmarc) issues from happening again.
For others running mailings lists on CentOS with this issue, Red Hat has back ported the ‘dmarc_moderation_action’ into the current version of mailman that is used in RHEL and CentOS. You can follow the instructions here for Mailman 2 (for version 2.1.18) even though the version in CentOS is mailman-2.1.15-26.el7_4.1
we will be watching the list for the next few days to see if this change is working as expected. If it id not working for other email clients please let us know.
Great job by Brian Stinson to figure all this out :)
Thanks, Johnny Hughes
Am 16.06.2018 um 12:25 schrieb Johnny Hughes via CentOS :
It seems that it moved to Reply-To: instead to CC: ?!
Thank you – one less list I’ll get kicked off of regularly.
One note, I am seeing the author in the Reply-To: in the message headers, not in the visible Cc: as you indicate:
From: Johnny Hughes via CentOS
Reply-To: Johnny Hughes ,
CentOS mailing list
so to see the address of the sender I have to either poke through the headers or initiate a reply. I don’t think that this is email client specific.
RIGHT ! .. I am showing that in Thunderbird for my emails (instead of CC
on the lists :D). So I thought it was CC.
So in thunderbird, you should see reply to (at least I do) when viewing the mail. For other email clients, not sure what is seen.
I’m petty sure I messed up attributions, so am deleting them.
Say it isn’t so: *An* e-mail, just *one* from yahoo.com.uk caused every gmail user to have his account disabled.
I’d heard of the DMARC thing with mailing lists before, but had not known it enabled single e-mails of mass destruction.
I’m truly amazed that rewwriting headers is not the default.
I run dmarc on my mail server but only in report mode, it doesn’t reject.
I did it as a test (for years) and am fully convinced that dmarc is worthless for real world protection.
Numerous mail lists out there are configured in such a way that dmarc gets triggered and that just isn’t going to change.
It’s a neat idea but it’s not backwards compatible with the way SMTP
already works.
I can not recommend its use. I do recommend mail server software update if possible to be compatible but I just can not recommend mail servers enforce dmarc.
DKIM is a good thing, but dmarc breaks things too badly.
Even DKIM though is of limited usefulness – it seems the spammer blacklists don’t really care. Even with proper DKIM signature on a domain with correct reverse DNS set up for years, they will still add you to the spam blacklist if any other host on your subnet is identified as a spammer.
So even the blacklists don’t really utilize this anti-spam anti-spoof technology, which makes it kind of worthless.
Using DKIM as one of several factors in spamassassin though is possibly helpful, though most spammers these days have a validating DKIM sig.
Methinks the rewriting was done badly. I’m guessing that this will go to the entire list, but I am not sure. I should be sure. This is what alpine shows me:
Let me put it this way – in the several years of running dmarc is report only mode, over 99% of reported violations are false positives from mail lists.
That high of a false positive rate tells me it is broken technology.
Yes, that’s because initially (in emergency when the issue was discovered last friday), the mailman “from_is_list” was changed from
“no” to “munge_from”, which solved the initial issue when all people were subscribed again.
Now I’ve put it back to “no”, as there are other settings that were backported to the .el7 mailman version (so from upstream 2.1.18 to mailman-2.1.15-26.el7_4.1.x86_64) and from today, here are the settings that were adapted :
So that means that for people without any DMARC policy set to either p=quarantine or p=reject , nothing will be changed in the headers, so as before And for for impacted originator domains with such DMARC policy, the
“from” will be adapted, so still let the mail being processed and delivered, but without a risk of being rejected/bounced by mail servers implementing such DMARC checks
Let’s see how that goes during the day
I agree with you .. unfortunately, gmail does not. They have enabled it for gmail users .. so if someone from yahoo xends a mail from a yahoo address, it gets rejected by gmail accounts. The list setting wrt dmarc doesn’t matter .. it is totally gmail enabling it.
What our settings do is NOT send the From (as the original sender), if the sender is on a domain where dmarc is enabled, so that gmail does not reject it.
If it is rejected by gmail .. it causes (eventually) .. not he sender’s, but the recipient’s account on gmail to be disabled by the mailing list as non-existent.
What the change that Brian and I tried to make, and Fabian finally fixed
:D (thanks Fabian), is to fix that only from doamins that enable dmarc
(ie, yahoo.* ) so that domains who turn on dmarc as enforcing (ie gmail)
do not cause rejects of those emails.
Fully agree.
I’m surprised no one arrived at conclusion: don’t use gmail then.
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
[OT]
My (non-gmail) mail hosting provider also enforces the DMARC settings that others put in place, so this isn’t (just) a gmail issue. Most people in the field find the p=reject setting that yahoo is using to be less than optimal, and come to the conclusion that the best course of action it to avoid sending mail (specifically to mailing lists)
from such providers. All places like my provider and gmail are doing is enforcing the standard. That others have selected poorly considered settings is the fault of the site making those selections, not the site doing the enforcing of the standard.
[the DMARC notifications are, in my view, a very serious privacy leak, so it should be avoided, but that’s a whole separate off-topic discussion.]
24 thoughts on - Passwords In Plain Text
I got it as well.
Mee too
Il Ven 15 Giu 2018, 18:45 Larry Martell ha scritto:
This is a standard feature of GNU Mailman. You can disable the monthly password reminder in your user preferences (which is the same place you can change your password, if you are concerned that it was sniffed during the SMTP exchange).
The Mailman signup page warns you that the password will be emailed:
“You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext.”
–keith
Ah I see. That said, this email wasn’t a password reminder. It was a
“your membership has been disabled” email.
I also received the “has been disabled” notification. It looks like users with gmail addresses are affected.
CentOS admins are looking into this issue (I believe).
Akemi
Sounds like either CentOS-owner was cleaning up the subscription list or GMail was down for a while and bouncing everyone’s mail.
I believe this is a DMARC issue. Yahoo, among other places, has set their dmarc records to p=reject:
dig +short txt _dmarc.yahoo.com
“v=DMARC1; p=reject; pct0; rua=mailto:dmarc_y_rua@yahoo.com;”
So, if your mail hosting provider enforces dmarc,(gmail does) and you get mail from a list that doesn’t rewrite the headers, and people from places like yahoo post to the list, you’ll likely get some form of warning about being being kicked off the mailing list every now and then. The frequency depends on how often people from p=reject places post, and what the settings are for bounce handling of the mailing list in question.
I believe that the current version of mailman can be configured to do the necessary header rewrites. Some lists I’m on only do the rewrites for headers of posts coming from p=reject sites (much less annoying than having them all rewritten).
I was thinking the same except I do not have enough knowledge in this area. In gmail’s header I often see DMARK “Fail”
Akemi
WRT mailing the password in clear text .. how else would it mail it?
Mailman does not store any kind of encryption keys for email, and frankly, most people don’t know how to use encrypted email. This list probably has a (much) higher percentage of people who would know how to use encrypted mail (ie, Linux users .. who are more computer literate than the average person). But, I don’t think mailman has sending administrative mails to users encrypted as an option.
WRT this issue .. several hundred gmail accounts (and few other accounts) were disabled at a specific time today. We don’t yet know exactly why this happened and before we mass reenable the accounts, we need to make sure it is not going to happen again.
Since so many of the mails are gmail.com accounts, this has to be something that gmail did today at 1530 GMT (when all the accounts were disabled) and the mails were sent).
We will try to figure out exactly what happened and get everything back to normal as soon as we can.
Thanks, Johnny Hughes
see here:
https://investorplace.com/2016/09/gmail-down-outage-googl-goog-stock/
d
Wasn’t this almost two years ago?
–keith
For this communication, not at all. The password was totally unnecessary. If I’d requested to have it sent, however, I now understand this system will email plain text passwords rather than a reset link etc. All good.
And good luck sorting out what happened today!
This is indeed what happened. An email from yahoo.com.uk caused gmail to reject all the mails sent by that user because of the yahoo DMARC
settings.
We have now set the mailing list to rewrite headers. That also has set the From: of the email to the Mailing list and not the Original Author. The author is moved to the CC: block and you can still easily see who sent it and my email client (thunderbird) still does things the same way
(reply to list sends to the list, reply sends to the original author).
This should prevent the yahoo/gmail (or other dmarc) issues from happening again.
For others running mailings lists on CentOS with this issue, Red Hat has back ported the ‘dmarc_moderation_action’ into the current version of mailman that is used in RHEL and CentOS. You can follow the instructions here for Mailman 2 (for version 2.1.18) even though the version in CentOS is mailman-2.1.15-26.el7_4.1
we will be watching the list for the next few days to see if this change is working as expected. If it id not working for other email clients please let us know.
Great job by Brian Stinson to figure all this out :)
Thanks, Johnny Hughes
Am 16.06.2018 um 12:25 schrieb Johnny Hughes via CentOS:
It seems that it moved to Reply-To: instead to CC: ?!
Thank you – one less list I’ll get kicked off of regularly.
One note, I am seeing the author in the Reply-To: in the message headers, not in the visible Cc: as you indicate:
From: Johnny Hughes via CentOS,
Reply-To: Johnny Hughes
CentOS mailing list
so to see the address of the sender I have to either poke through the headers or initiate a reply. I don’t think that this is email client specific.
RIGHT ! .. I am showing that in Thunderbird for my emails (instead of CC
on the lists :D). So I thought it was CC.
So in thunderbird, you should see reply to (at least I do) when viewing the mail. For other email clients, not sure what is seen.
I’m petty sure I messed up attributions, so am deleting them.
Say it isn’t so: *An* e-mail, just *one* from yahoo.com.uk caused every gmail user to have his account disabled.
I’d heard of the DMARC thing with mailing lists before, but had not known it enabled single e-mails of mass destruction.
I’m truly amazed that rewwriting headers is not the default.
I run dmarc on my mail server but only in report mode, it doesn’t reject.
I did it as a test (for years) and am fully convinced that dmarc is worthless for real world protection.
Numerous mail lists out there are configured in such a way that dmarc gets triggered and that just isn’t going to change.
It’s a neat idea but it’s not backwards compatible with the way SMTP
already works.
I can not recommend its use. I do recommend mail server software update if possible to be compatible but I just can not recommend mail servers enforce dmarc.
DKIM is a good thing, but dmarc breaks things too badly.
Even DKIM though is of limited usefulness – it seems the spammer blacklists don’t really care. Even with proper DKIM signature on a domain with correct reverse DNS set up for years, they will still add you to the spam blacklist if any other host on your subnet is identified as a spammer.
So even the blacklists don’t really utilize this anti-spam anti-spoof technology, which makes it kind of worthless.
Using DKIM as one of several factors in spamassassin though is possibly helpful, though most spammers these days have a validating DKIM sig.
Methinks the rewriting was done badly. I’m guessing that this will go to the entire list, but I am not sure. I should be sure. This is what alpine shows me:
Let me put it this way – in the several years of running dmarc is report only mode, over 99% of reported violations are false positives from mail lists.
That high of a false positive rate tells me it is broken technology.
Yes, that’s because initially (in emergency when the issue was discovered last friday), the mailman “from_is_list” was changed from
“no” to “munge_from”, which solved the initial issue when all people were subscribed again.
Now I’ve put it back to “no”, as there are other settings that were backported to the .el7 mailman version (so from upstream 2.1.18 to mailman-2.1.15-26.el7_4.1.x86_64) and from today, here are the settings that were adapted :
dmarc_moderation_action “munge from”
dmarc_quarantine_moderation_action : “yes”
So that means that for people without any DMARC policy set to either p=quarantine or p=reject , nothing will be changed in the headers, so as before And for for impacted originator domains with such DMARC policy, the
“from” will be adapted, so still let the mail being processed and delivered, but without a risk of being rejected/bounced by mail servers implementing such DMARC checks
Let’s see how that goes during the day
I agree with you .. unfortunately, gmail does not. They have enabled it for gmail users .. so if someone from yahoo xends a mail from a yahoo address, it gets rejected by gmail accounts. The list setting wrt dmarc doesn’t matter .. it is totally gmail enabling it.
What our settings do is NOT send the From (as the original sender), if the sender is on a domain where dmarc is enabled, so that gmail does not reject it.
If it is rejected by gmail .. it causes (eventually) .. not he sender’s, but the recipient’s account on gmail to be disabled by the mailing list as non-existent.
What the change that Brian and I tried to make, and Fabian finally fixed
:D (thanks Fabian), is to fix that only from doamins that enable dmarc
(ie, yahoo.* ) so that domains who turn on dmarc as enforcing (ie gmail)
do not cause rejects of those emails.
Fully agree.
I’m surprised no one arrived at conclusion: don’t use gmail then.
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
[OT]
My (non-gmail) mail hosting provider also enforces the DMARC settings that others put in place, so this isn’t (just) a gmail issue. Most people in the field find the p=reject setting that yahoo is using to be less than optimal, and come to the conclusion that the best course of action it to avoid sending mail (specifically to mailing lists)
from such providers. All places like my provider and gmail are doing is enforcing the standard. That others have selected poorly considered settings is the fault of the site making those selections, not the site doing the enforcing of the standard.
[the DMARC notifications are, in my view, a very serious privacy leak, so it should be avoided, but that’s a whole separate off-topic discussion.]
– Richard