Quick show of hands: Who's had a "looks like spam" bounce from php.net
mail servers in the past... lets say the past month.
Or how about the fact that new users tend to have a very hard time
even subscribing to this list?
This isn't directed at any one person because AFAICT, the maintainer
of those systems is "nobody".
Is it time to pick someone to actually maintain that pile of mierde?
Maybe replace the pieces that haven't worked since the 90s?
Fed up with something this basic not working,
-Sara
Quick show of hands: Who's had a "looks like spam" bounce from
php.net mail servers in the past... lets say the past month.
Not last month, but in the past. Quite often actually.
This isn't directed at any one person because AFAICT, the maintainer
of those systems is "nobody".
When I mentioned years ago that there was a problem with the mail
server, people on this list became very agressive.
I even stopped writing to this list for this exact reason. People on
this list tend to react with hostility, when they hear something they
don't like or don't agree with.
Good luck.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
To throw something else on the heap of things that need fixing in the mail
servers:
I occasionally get emails from the mailing list bot warning I'll be
auto-unsubscribed because messages it is sending to me are are bouncing.
(It sends me back the bounce notification it received, so I can see that
the cause is failed DMARC signing requirements on messages from a certain
domain). I attempted to forward the bounced email text to
internals-owner@lists[.]php[.]net (which was listed in the email as the
owner of the bot) along with a link to Google's support page on why it
failed. I was unable to make contact because the forwarded message
inevitably contained URLs and IPs both in my text and in the forwarded
bounce mail, and so I ran into multiple "looks like spam" warnings.
If anyone wants to debug this I can forward the emails I've got (though
obviously I can't send them via this mailing list because of domains
contained in the text ?♂️)
On 25 October 2017 at 17:05, Helmut K. C. Tessarek tessarek@evermeet.cx
wrote:
Quick show of hands: Who's had a "looks like spam" bounce from
php.net mail servers in the past... lets say the past month.Not last month, but in the past. Quite often actually.
This isn't directed at any one person because AFAICT, the maintainer
of those systems is "nobody".When I mentioned years ago that there was a problem with the mail
server, people on this list became very agressive.I even stopped writing to this list for this exact reason. People on
this list tend to react with hostility, when they hear something they
don't like or don't agree with.Good luck.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D/*
Thou shalt not follow theNULLpointer for chaos and madness
await thee at its end.
*/
Am 25.10.2017 um 21:38 schrieb Aidan Woods:
To throw something else on the heap of things that need fixing in the mail
servers:
I occasionally get emails from the mailing list bot warning I'll be
auto-unsubscribed because messages it is sending to me are are bouncing.
(It sends me back the bounce notification it received, so I can see that
the cause is failed DMARC signing requirements on messages from a certain
domain)
the wording "bounce" is wrong as you don't send active mails, you reject
messages
anyways, don't reject mailing-list messages
mailing-lists are typically not a real spam problem and should be
whitelisted which is easy in case of SPF on the envelope-domain
spamd: result: . -100 -
CUST_DNSWL_2_SENDERSC_L,CUST_DNSWL_7_ORG_L,CUST_SHORTCIRCUIT1,SHORTCIRCUIT,USER_IN_SPF_WHITELIST
the wording "bounce" is wrong as you don't send active mails, you reject
messages
FYI, while incorrect, the wording comes from ezmlm, not Aidan:
Messages to you from the internals mailing list seem to
have been bouncing. I've attached a copy of the first bounce
message I received.
I occasionally get emails from the mailing list bot warning I'll be
auto-unsubscribed because messages it is sending to me are are bouncing.
(It sends me back the bounce notification it received, so I can see that
the cause is failed DMARC signing requirements on messages from a certain
domain). I attempted to forward the bounced email text to
internals-owner@lists[.]php[.]net (which was listed in the email as the
owner of the bot) along with a link to Google's support page on why it
failed. I was unable to make contact because the forwarded message
inevitably contained URLs and IPs both in my text and in the forwarded
bounce mail, and so I ran into multiple "looks like spam" warnings.
Yep, got these too. I have a sieve rule now which discards these
messages. (They became quite irritating after a while.)
Sending a mail to internals-owner did not work either and when I wrote
to the list, I got a lot of replies and berating messages that I should
send this email to the mailing list owner. What a joke.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
anyways, don't reject mailing-list messages
I don't reject the messages, Google rejects the messages because of failed
DMARC requirements. See support[.]google[.]com/mail/answer/2451690
The error occurs when the php mailing list attempts to forward messages
from a domain which has a (likey strict) DMARC policy, and sends emails as
if it was the sender from the domain holding that policy.
In any case, despite failed delivery due to the policy being an issue – it
would be great if I wouldn't be unsubscribed from the mailing list because
of an error that has nothing to do with me ?♂️
On 25 October 2017 at 21:22, Helmut K. C. Tessarek tessarek@evermeet.cx
wrote:
I occasionally get emails from the mailing list bot warning I'll be
auto-unsubscribed because messages it is sending to me are are bouncing.
(It sends me back the bounce notification it received, so I can see that
the cause is failed DMARC signing requirements on messages from a certain
domain). I attempted to forward the bounced email text to
internals-owner@lists[.]php[.]net (which was listed in the email as the
owner of the bot) along with a link to Google's support page on why it
failed. I was unable to make contact because the forwarded message
inevitably contained URLs and IPs both in my text and in the forwarded
bounce mail, and so I ran into multiple "looks like spam" warnings.Yep, got these too. I have a sieve rule now which discards these
messages. (They became quite irritating after a while.)Sending a mail to internals-owner did not work either and when I wrote
to the list, I got a lot of replies and berating messages that I should
send this email to the mailing list owner. What a joke.--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D/*
Thou shalt not follow theNULLpointer for chaos and madness
await thee at its end.
*/
anyways, don't reject mailing-list messages
I don't reject the messages, Google rejects the messages because of failed
DMARC requirements. See support[.]google[.]com/mail/answer/2451690The error occurs when the php mailing list attempts to forward messages
from a domain which has a (likey strict) DMARC policy, and sends emails as
if it was the sender from the domain holding that policy.In any case, despite failed delivery due to the policy being an issue – it
would be great if I wouldn't be unsubscribed from the mailing list because
of an error that has nothing to do with me ?♂️
I’m using GSuite for email, and I’ve never received a warning from the php.net mail system that mail was bouncing anytime in the past two years, nor have I been automatically unsubscribed.
That said, email is a lot harder than it looks.
Tom
Hi, internals!
Just quick idea: what about moving from old-school mailing list with
unclear subscription logic and ugly interface to the RFC project on GitHub?
Maybe https://github.com/php/rfc or similar.
There are cases when language developers actively use GitHub for
maintaining RFC-s, label them and review directly in github issues. For
example, https://github.com/rust-lang/rfcs
Organizing internals in this way could give a chance for community to grow,
because everyone knows how to raise an issue on GitHub and how to
contribute to the documentation/RFC.
GitHub also provides flexible way to subscribe to repo/issues/summons.
Maybe it's a good time to move internals to the public open-source system?
Best regards, Alexander
2017-10-26 1:28 GMT+03:00 Tom Samplonius tom@samplonius.org:
anyways, don't reject mailing-list messages
I don't reject the messages, Google rejects the messages because of
failed
DMARC requirements. See support[.]google[.]com/mail/answer/2451690The error occurs when the php mailing list attempts to forward messages
from a domain which has a (likey strict) DMARC policy, and sends emails
as
if it was the sender from the domain holding that policy.In any case, despite failed delivery due to the policy being an issue –
it
would be great if I wouldn't be unsubscribed from the mailing list
because
of an error that has nothing to do with me ?♂️I’m using GSuite for email, and I’ve never received a warning from the
php.net mail system that mail was bouncing anytime in the past two years,
nor have I been automatically unsubscribed.That said, email is a lot harder than it looks.
Tom
2017-10-25 17:30 GMT+03:00 Sara Golemon pollita@php.net:
Quick show of hands: Who's had a "looks like spam" bounce from php.net
mail servers in the past... lets say the past month.
Or how about the fact that new users tend to have a very hard time
even subscribing to this list?
This isn't directed at any one person because AFAICT, the maintainer
of those systems is "nobody".
Is it time to pick someone to actually maintain that pile of mierde?
Maybe replace the pieces that haven't worked since the 90s?Fed up with something this basic not working,
-Sara
Organizing internals in this way could give a chance for community to grow,
because everyone knows how to raise an issue on GitHub and how to
contribute to the documentation/RFC.GitHub also provides flexible way to subscribe to repo/issues/summons.
Maybe it's a good time to move internals to the public open-source system?
Mailing lists in general are fine, the problem at hand really is the
php.net mail infrastructure, so I'd suggest sticking to solving that
problem.
If you want to abandon email as an official discussion medium for this
project, please write up a RFC - https://wiki.php.net/rfc
Greetings,
Florian
Am 26.10.2017 um 13:31 schrieb Florian Anderiasch:
Mailing lists in general are fine, the problem at hand really is the
php.net mail infrastructure, so I'd suggest sticking to solving that
problem.
+1
Biweekly reminder that PHP mail servers suck.
Quick show of hands: Who's had a "looks like spam" bounce from php.net
mail servers in the past... lets say the past month.
Or how about the fact that new users tend to have a very hard time
even subscribing to this list?
This isn't directed at any one person because AFAICT, the maintainer
of those systems is "nobody".
Is it time to pick someone to actually maintain that pile of mierde?
Maybe replace the pieces that haven't worked since the 90s?Fed up with something this basic not working,
-Sara
Just chiming in that I have constantly had issues (since you asked for
hands), get emails denied (let's see if this one goes through), and
semi-constant threads of being auto-removed because of bounces that have
nothing to do with me (see above gmail discussion).
Yeah, it sucks. And it's been brought up in the past. And invariably it
all falls back to "Oh, only one person really knew how to maintain that
random mail server and they aren't active anymore, and now no-one really
does, so it just keeps running and no-one wants to take the effort to try
to update/fix/move it"
Eli
PS. Not it
Biweekly reminder that PHP mail servers suck.
Quick show of hands: Who's had a "looks like spam" bounce from php.net
mail servers in the past... lets say the past month.
Or how about the fact that new users tend to have a very hard time
even subscribing to this list?
This isn't directed at any one person because AFAICT, the maintainer
of those systems is "nobody".
Is it time to pick someone to actually maintain that pile of mierde?
Maybe replace the pieces that haven't worked since the 90s?Fed up with something this basic not working,
-Sara
Hey all.
Am 07.11.17 um 14:48 schrieb Eli White:
Just chiming in that I have constantly had issues (since you asked for
hands), get emails denied (let's see if this one goes through), and
semi-constant threads of being auto-removed because of bounces that have
nothing to do with me (see above gmail discussion).Yeah, it sucks. And it's been brought up in the past. And invariably it
all falls back to "Oh, only one person really knew how to maintain that
random mail server and they aren't active anymore, and now no-one really
does, so it just keeps running and no-one wants to take the effort to try
to update/fix/move it"
Just a reminder: There where offers from people to help out (me
included) but the response was <sarcasm>so overwhelming that not one of
them knew which answer to read first</sarcasm> …
When people offer help and the only reply they get is no reply at all
that is not really a good thing to happen. So should PHP-internals want
other people than the current usual suspects (that only a limited number
of people by now know of) to help managing the infrastructure it would
be great when they'd at least signal a "thanks, offer noted, we might
come back to you". Even better with actually getting back…
But as it is currently the chances are that we will have to live with a
messy list-server and over time probably move somewhere else for
discussions as the old system becomes more and more unreliable…
Just my (frustrated) 0.02€
Cheers
Andreas
Eli
PS. Not it
Biweekly reminder that PHP mail servers suck.
Quick show of hands: Who's had a "looks like spam" bounce from php.net
mail servers in the past... lets say the past month.
Or how about the fact that new users tend to have a very hard time
even subscribing to this list?
This isn't directed at any one person because AFAICT, the maintainer
of those systems is "nobody".
Is it time to pick someone to actually maintain that pile of mierde?
Maybe replace the pieces that haven't worked since the 90s?Fed up with something this basic not working,
-Sara--
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
Might be worth noting that fixing the mailing lists does not amount to
taking on the php.net mail servers. The two are separate - just in case
someone should be up for one, but not both tasks.
Just chiming in that I have constantly had issues (since you asked for
hands), get emails denied (let's see if this one goes through), and
semi-constant threads of being auto-removed because of bounces that have
nothing to do with me (see above gmail discussion).Yeah, it sucks. And it's been brought up in the past. And invariably it
all falls back to "Oh, only one person really knew how to maintain that
random mail server and they aren't active anymore, and now no-one really
does, so it just keeps running and no-one wants to take the effort to try
to update/fix/move it"Eli
PS. Not it
Biweekly reminder that PHP mail servers suck.
Quick show of hands: Who's had a "looks like spam" bounce from php.net
mail servers in the past... lets say the past month.
Or how about the fact that new users tend to have a very hard time
even subscribing to this list?
This isn't directed at any one person because AFAICT, the maintainer
of those systems is "nobody".
Is it time to pick someone to actually maintain that pile of mierde?
Maybe replace the pieces that haven't worked since the 90s?Fed up with something this basic not working,
-Sara--
--
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
Might be worth noting that fixing the mailing lists does not amount to
taking on the php.net mail servers. The two are separate - just in case
someone should be up for one, but not both tasks.
In this case I believe that they are one and the same Peter. As the
issues with the mailing list(s), are actually issues with the mail server
itself. And Andreas is correct. Multiple times in the past people have
stepped up and offered to help out. But they've either not been given any
information how to do so (silence). Or in a couple cases where I know
someone was brought into discussion, they were shipped off with a 'talk to
person X', and person X ended up being "don't need help, I've got it".
Really seems we have an issue here of "failure of democratic rule". No-one
is empowered to tell someone that they can take it on. No-one even knows
who/how to give access to someone to take it on. And in the rare case that
someone does have the ability to give someone access, it's never granted.
We need a way for infrastructure stuff like like to have a solid point
person, who can give others power to handle things. Sounds like we have
some people willing to help out. (Andreas? Sara?) — People just need to
give them access and let things happen.
Eli
Am 07.11.17 um 16:40 schrieb Eli White:
Might be worth noting that fixing the mailing lists does not amount to
taking on the php.net mail servers. The two are separate - just in case
someone should be up for one, but not both tasks.In this case I believe that they are one and the same Peter. As the
issues with the mailing list(s), are actually issues with the mail server
itself. And Andreas is correct. Multiple times in the past people have
stepped up and offered to help out. But they've either not been given any
information how to do so (silence). Or in a couple cases where I know
someone was brought into discussion, they were shipped off with a 'talk to
person X', and person X ended up being "don't need help, I've got it".Really seems we have an issue here of "failure of democratic rule". No-one
is empowered to tell someone that they can take it on. No-one even knows
who/how to give access to someone to take it on. And in the rare case that
someone does have the ability to give someone access, it's never granted.We need a way for infrastructure stuff like like to have a solid point
person, who can give others power to handle things. Sounds like we have
some people willing to help out. (Andreas? Sara?) — People just need to
give them access and let things happen.
I'm (still) in!
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
Am 07.11.17 um 16:40 schrieb Eli White:
On Tue, Nov 7, 2017 at 9:07 AM, Peter Lind peter.e.lind@gmail.com
wrote:Might be worth noting that fixing the mailing lists does not
amount to
taking on the php.net mail servers. The two are separate - just
in case
someone should be up for one, but not both tasks.In this case I believe that they are one and the same Peter. As
the
issues with the mailing list(s), are actually issues with the mail
server
itself. And Andreas is correct. Multiple times in the past
people have
stepped up and offered to help out. But they've either not been
given any
information how to do so (silence). Or in a couple cases where I
know
someone was brought into discussion, they were shipped off with a
'talk to
person X', and person X ended up being "don't need help, I've got
it".Really seems we have an issue here of "failure of democratic
rule". No-one
is empowered to tell someone that they can take it on. No-one even
knows
who/how to give access to someone to take it on. And in the rare
case that
someone does have the ability to give someone access, it's never
granted.We need a way for infrastructure stuff like like to have a solid
point
person, who can give others power to handle things. Sounds like
we have
some people willing to help out. (Andreas? Sara?) — People just
need to
give them access and let things happen.I'm (still) in!
I'd be willing to help out as well. I've offered to help with server
work in the past, and have plenty of internals users that can vouch for
me.
Cheers
Andreas
-Chris
I'm not sure if the people who have access to the machines follow this
mailing list as well, so I would suggest reaching out directly to the
people listed as having access to the mailing lists machine (you can find
that list here: https://wiki.php.net/systems/pb1).
Also, there seems to be a systems@ mailing list as well (mentioned here:
https://externals.io/message/97214) which may yield some actual response
from the people involved.
Regards,
Pedro
I'm not sure if the people who have access to the machines follow this
mailing list as well, so I would suggest reaching out directly to the
people listed as having access to the mailing lists machine (you can find
that list here: https://wiki.php.net/systems/pb1).Also, there seems to be a systems@ mailing list as well (mentioned here:
https://externals.io/message/97214) which may yield some actual response
from the people involved.
Just saw this thread today. Yes, Pedro is right, infrastructure discussion
belongs on systems@ not internals.
So please send your volunteer requests there, but not just a generic offer
to help. Please include a concrete description of what you plan on doing.
As in which software or configuration changes. If it is just replace ezmlm
with Mailman, then you are going to have to make a really really strong
case for why you think a sideways migration like that will make any
difference. It is also important to understand the difference between the
list server and the mail server responsibilities.
-Rasmus
I'm not sure if the people who have access to the machines follow this
mailing list as well, so I would suggest reaching out directly to the
people listed as having access to the mailing lists machine (you can find
that list here: https://wiki.php.net/systems/pb1).Also, there seems to be a systems@ mailing list as well (mentioned here:
https://externals.io/message/97214) which may yield some actual response
from the people involved.Just saw this thread today. Yes, Pedro is right, infrastructure discussion
belongs on systems@ not internals.So please send your volunteer requests there, but not just a generic offer
to help. Please include a concrete description of what you plan on doing.
As in which software or configuration changes. If it is just replace ezmlm
with Mailman, then you are going to have to make a really really strong
case for why you think a sideways migration like that will make any
difference. It is also important to understand the difference between the
list server and the mail server responsibilities.
Without any generally available information about the existing email
infrastructure, it's hard to make targeted comments about how to fix
what is obviously broken with this system which literally nobody with
the ability to fix cares about. That means a either a conversation
(which should be a shared experience (therefore internals@) or an
essentially open request for "I'd like to help, but I'll need the
ability to poke around to figure out wtf is going on".
-Sara
Am 08.11.2017 um 12:09 schrieb Sara Golemon:
So please send your volunteer requests there, but not just a generic offer
to help. Please include a concrete description of what you plan on doing.
As in which software or configuration changes. If it is just replace ezmlm
with Mailman, then you are going to have to make a really really strong
case for why you think a sideways migration like that will make any
difference. It is also important to understand the difference between the
list server and the mail server responsibilities.
Without any generally available information about the existing email
infrastructure, it's hard to make targeted comments about how to fix
what is obviously broken with this system which literally nobody with
the ability to fix cares about. That means a either a conversation
(which should be a shared experience (therefore internals@) or an
essentially open request for "I'd like to help, but I'll need the
ability to poke around to figure out wtf is going on".
The problem seems to be the mailing list software, not the mail server.
Mail servers just transfer bytes from A to B.
The PHP mailing list software is not configured DMARC compliant. DMARC
means, either SPF or DKIM has to be valid. The PHP mailing list changes
the Subject (it adds [PHP-xxxx]), that's why the DKIM signature breaks.
SPF breaks, because Gmail and others don't include the IP address of the
PHP mailing list mailserver in their SPF records. So SPF also fails.
Easiest fix should be:
- Don't touch the email, especially don't change the Subject. Then the
DKIM signature stays valid, and DMARC is happy.
Maybe the better way:
- Change the From:-Header to an email address that php.net owns, and put
the original email address into the displayname. Like:
Michael (mkliewe@gmx.de via PHP-DEV Mailing List)
members-internals@lists.php.net - Remove existing (now broken) DKIM-Signatures, and add php.net own DKIM
signature (alternative: change to X-Original-DKIM-Signature) - Set the original From: email address into Reply-To: if you want
- Because now it's "your" email, you can change the Subject + content as
you like.
Obviously the mailing list software has to support this procedure.
In MailMan for example you can configure this with some settings:
https://wiki.list.org/DEV/DMARC
For ezmlm there seems to be something in 7.2.0:
https://untroubled.org/ezmlm/archive/7.2.0/CHANGES
"- Added optional rewritefrom feature to ezmlm-send, automatically
enabled when the sender has a "reject" DMARC policy."
Hope this helps to see, that it has to be fixed in the mailing list
software, not the mailserver.
Michael
Am 08.11.2017 um 12:59 schrieb Michael Kliewe:
The PHP mailing list software is not configured DMARC compliant. DMARC
means, either SPF or DKIM has to be valid. The PHP mailing list changes
the Subject (it adds [PHP-xxxx]), that's why the DKIM signature breaks.
SPF breaks, because Gmail and others don't include the IP address of the
PHP mailing list mailserver in their SPF records. So SPF also fails.
nonsense - a mailing list does not forward with the original envelope
Return-Path: internals-return-101098-lists=rhsoft.net@lists.php.net
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=76.75.200.58;
helo=lists.php.net;
Am 08.11.2017 um 13:27 schrieb lists@rhsoft.net:
Am 08.11.2017 um 12:59 schrieb Michael Kliewe:
The PHP mailing list software is not configured DMARC compliant. DMARC
means, either SPF or DKIM has to be valid. The PHP mailing list changes
the Subject (it adds [PHP-xxxx]), that's why the DKIM signature breaks.
SPF breaks, because Gmail and others don't include the IP address of the
PHP mailing list mailserver in their SPF records. So SPF also fails.nonsense - a mailing list does not forward with the original envelope
Return-Path: internals-return-101098-lists=rhsoft.net@lists.php.net
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=76.75.200.58;
helo=lists.php.net;
nonsense. Read about DMARC alignment
I was talking about the From: header. I just wanted to explain a bit,
not in every detail (DMARC alignment for example).
No need to be rude.
Michael
Am 08.11.2017 um 13:36 schrieb Michael Kliewe:
Am 08.11.2017 um 13:27 schrieb lists@rhsoft.net:
Am 08.11.2017 um 12:59 schrieb Michael Kliewe:
The PHP mailing list software is not configured DMARC compliant. DMARC
means, either SPF or DKIM has to be valid. The PHP mailing list changes
the Subject (it adds [PHP-xxxx]), that's why the DKIM signature breaks.
SPF breaks, because Gmail and others don't include the IP address of the
PHP mailing list mailserver in their SPF records. So SPF also fails.nonsense - a mailing list does not forward with the original envelope
Return-Path: internals-return-101098-lists=rhsoft.net@lists.php.net
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=76.75.200.58nonsense. Read about DMARC alignment
I was talking about the From: header. I just wanted to explain a bit,
not in every detail (DMARC alignment for example).No need to be rude
the from header has no business with SPF - period
DMARC is a different story
Am 08.11.2017 um 13:40 schrieb lists@rhsoft.net:
Am 08.11.2017 um 13:36 schrieb Michael Kliewe:
Am 08.11.2017 um 13:27 schrieb lists@rhsoft.net:
Am 08.11.2017 um 12:59 schrieb Michael Kliewe:
The PHP mailing list software is not configured DMARC compliant. DMARC
means, either SPF or DKIM has to be valid. The PHP mailing list
changes
the Subject (it adds [PHP-xxxx]), that's why the DKIM signature
breaks.
SPF breaks, because Gmail and others don't include the IP address
of the
PHP mailing list mailserver in their SPF records. So SPF also fails.nonsense - a mailing list does not forward with the original envelope
Return-Path: internals-return-101098-lists=rhsoft.net@lists.php.net
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=76.75.200.58nonsense. Read about DMARC alignment
I was talking about the From: header. I just wanted to explain a bit,
not in every detail (DMARC alignment for example).No need to be rude
the from header has no business with SPF - period
DMARC is a different story
Maybe you should try to say it better, instead of just saying it's wrong.
From DMARCs view, the "SPF part" has to be a successful SPF check (which
checks the envelope from), AND the From: header has to be aligned to the
envelope from. That's where From: header and SPF come together, and need
to be aligned.
Yes, you were right, it does not fail because the basic SPF check fails,
but because the alignment fails, and then the "SPF-part of DMARC" fails...
Anyway, DMARC fails because SPF(including alignment) and DKIM both fail.
Am 08.11.2017 um 12:09 schrieb Sara Golemon:
So please send your volunteer requests there, but not just a generic offer
to help. Please include a concrete description of what you plan on doing.
As in which software or configuration changes. If it is just replace ezmlm
with Mailman, then you are going to have to make a really really strong
case for why you think a sideways migration like that will make any
difference. It is also important to understand the difference between the
list server and the mail server responsibilities.
Without any generally available information about the existing email
infrastructure, it's hard to make targeted comments about how to fix
what is obviously broken with this system which literally nobody with
the ability to fix cares about. That means a either a conversation
(which should be a shared experience (therefore internals@) or an
essentially open request for "I'd like to help, but I'll need the
ability to poke around to figure out wtf is going on".
The problem seems to be the mailing list software, not the mail server.
Mail servers just transfer bytes from A to B.The PHP mailing list software is not configured DMARC compliant. DMARC
means, either SPF or DKIM has to be valid. The PHP mailing list changes
the Subject (it adds [PHP-xxxx]), that's why the DKIM signature breaks.
SPF breaks, because Gmail and others don't include the IP address of the
PHP mailing list mailserver in their SPF records. So SPF also fails.Easiest fix should be:
- Don't touch the email, especially don't change the Subject. Then the
DKIM signature stays valid, and DMARC is happy.Maybe the better way:
- Change the From:-Header to an email address that php.net owns, and put
the original email address into the displayname. Like:
Michael (mkliewe@gmx.de via PHP-DEV Mailing List)
members-internals@lists.php.net- Remove existing (now broken) DKIM-Signatures, and add php.net own DKIM
signature (alternative: change to X-Original-DKIM-Signature)- Set the original From: email address into Reply-To: if you want
- Because now it's "your" email, you can change the Subject + content as
you like.Obviously the mailing list software has to support this procedure.
In MailMan for example you can configure this with some settings:
https://wiki.list.org/DEV/DMARC
For ezmlm there seems to be something in 7.2.0:
https://untroubled.org/ezmlm/archive/7.2.0/CHANGES
"- Added optional rewritefrom feature to ezmlm-send, automatically
enabled when the sender has a "reject" DMARC policy."Hope this helps to see, that it has to be fixed in the mailing list
software, not the mailserver.
This would seem to describe one problem and potential solution set,
and I appreciate the detailed response; However it's certainly not the
entire scope of everything that's wrong with @php.net email. Notably,
signing up for mailing lists should not be impacted by this
misconfiguration, yet new would-be contributed are regularly stymied
by our sign up process. Additionally, I use at least one distribution
alias which isn't part of the mailing list software and I get "looks
like spam" rejections from the MTA a few times per month.
Without any generally available information about the existing email
infrastructure, it's hard to make targeted comments about how to fix
what is obviously broken with this system which literally nobody with
the ability to fix cares about. That means a either a conversation
(which should be a shared experience (therefore internals@) or an
essentially open request for "I'd like to help, but I'll need the
ability to poke around to figure out wtf is going on".
Our smtp servers are actually quite well maintained by Sascha and company.
Which is a somewhat new thing, so if you are saying this has been going on
for years, the mail servers changed completely in there somewhere. And they
are quick to respond to specific problems if you send a useful description
of the issue to systems@
For example, last week a specific @php.net address apparently pissed off
the Internet and our smtp servers were being hammered with thousands of
messages per minute for this one person. Sascha was on the ball and had the
attack filtered quickly. Nobody here even noticed, I am sure.
We could definitely need a volunteer who knows ezmlm-idx and perhaps
modernize the config there, but on the smtp servers front things are under
control. I am sure Sascha and his team would love to see concrete examples
(as in with full headers) of any messages rejected at the smtp level.
-Rasmus
I am sure Sascha and his team would love to see concrete examples
(as in with full headers) of any messages rejected at the smtp level.
Next time I get one Rasmus I'll be happy to forward it on. This is
definitely new news that someone is on top of it, and that's great. About
a year ago (I'm guessing, would have to look through the list archives)
Myself, Ben Ramsey, and a few others were trying to work on getting things
fixed, and I was sharing a ton of bounces I was getting where the SMTP
server was rejecting emails I was sending incorrectly. (An issue of
blocking me because of PBL but it was the Transient PBL that shouldn't lead
to a block). Anyway, at the time it was mostly pushed off. And those who
offered to step in, weren't given any direction to do so.
Glad to hear that there is a team working on it now.
Eli
Our smtp servers are actually quite well maintained by Sascha and company.
This is a response from the mail server, with no mailing list software involved.
This is a regular response covering years.
This is response which has been reported to no effect.
Action: failed
Status: 5.7.1
Remote-MTA: dns; php-smtp2.php.net. (2a02:cb41::8, the server for the
domain php.net.)
Diagnostic-Code: smtp; 550 5.7.1 Looks like spam to me.
Last-Attempt-Date: Tue, 07 Nov 2017 04:49:54 -0800 (PST)
Yay that Sacha dealt with a slew of spam, but that's irrelevant to the
false-positives problem. If a sender using a php.net address can't
send an email containing a php.net URL through php.net servers without
looking like spam, then the configuration is broken.
-Sara
So please report that directly to systems@ (that's what it is there for)
and cc sascha@ specifically since he maintains php-smtp2. And php-smtp2 has
been around less than a year, so if you haven't reported it since the
changeover they probably never saw a report.
-Rasmus
Our smtp servers are actually quite well maintained by Sascha and
company.This is a response from the mail server, with no mailing list software
involved.
This is a regular response covering years.
This is response which has been reported to no effect.Action: failed
Status: 5.7.1
Remote-MTA: dns; php-smtp2.php.net. (2a02:cb41::8, the server for the
domain php.net.)
Diagnostic-Code: smtp; 550 5.7.1 Looks like spam to me.
Last-Attempt-Date: Tue, 07 Nov 2017 04:49:54 -0800 (PST)Yay that Sacha dealt with a slew of spam, but that's irrelevant to the
false-positives problem. If a sender using a php.net address can't
send an email containing a php.net URL through php.net servers without
looking like spam, then the configuration is broken.-Sara
So please report that directly to systems@ (that's what it is there for) and
cc sascha@ specifically since he maintains php-smtp2. And php-smtp2 has been
around less than a year, so if you haven't reported it since the changeover
they probably never saw a report.
Yes, I'm aware of the systems@ distribution list. As you well know
I've emailed it many times about various concerns, MOST of which are
promptly responded to. This one has never been dealt with, hence the
public shaming. The email server got replaced recently? Great,
doesn't mean it fixed anything.
If being an asshole publicly gets me the same response as being polite
privately, then I might as well be public about it.
-Sara
It isn't super-helpful to publicly shame our active volunteers.
So please report that directly to systems@ (that's what it is there
for) and
cc sascha@ specifically since he maintains php-smtp2. And php-smtp2 has
been
around less than a year, so if you haven't reported it since the
changeover
they probably never saw a report.Yes, I'm aware of the systems@ distribution list. As you well know
I've emailed it many times about various concerns, MOST of which are
promptly responded to. This one has never been dealt with, hence the
public shaming. The email server got replaced recently? Great,
doesn't mean it fixed anything.If being an asshole publicly gets me the same response as being polite
privately, then I might as well be public about it.-Sara
It isn't super-helpful to publicly shame our active volunteers.
There are many not-super-helpful things here, for example:
Ignoring an inability to subscribe to the mailing list for YEARS isn't
super helpful.
Preventing project discussion from happening on the project mailing
list isn't super helpful.
Pretending that nothing is wrong isn't super helpful.
Allowing the ranks of systems@ to shrink, but never grow isn't super-helpful.
Focusing on "the mail server and the mailing list are two different
things" rather than addressing or even acknowledging real issues isn't
super-helpful.
systems@ having literally no idea how to add authorized senders to
moderated lists isn't super-helpful.
-Sara
Might be worth noting that fixing the mailing lists does not amount to
taking on the php.net mail servers. The two are separate - just in case
someone should be up for one, but not both tasks.
In this case I believe that they are one and the same Peter. As the
issues with the mailing list(s), are actually issues with the mail server
itself.
You might be right, but as far as I can tell, the lists server handles
receiving and sending for lists.php.net without the use of PHP.net. The
only issue outside of lists.php.net would be DNS, but that's handled
externally - the rest is handled on the lists server, by some derelict
mailing list software. That's also what previous discussions on the topic
bring up.