[PHP-DEV] PHP's 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 2017-10-25 10:30, Sara Golemon 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 the NULL pointer for chaos and madness
await thee at its end.
*/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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
[email protected][.]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

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

>
> 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.

On 2017-10-25 15:38, Aidan Woods 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
> [email protected][.]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.
*/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> 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 Oct 25, 2017, at 2:17 PM, Aidan Woods <[email protected]> wrote:
>
>> 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

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 <[email protected]>:

>
> > On Oct 25, 2017, at 2:17 PM, Aidan Woods <[email protected]> wrote:
> >
> >> 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 26.10.2017 09:23, Alexander Lisachenko wrote:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Biweekly reminder that PHP mail servers suck.

On Wed, Oct 25, 2017 at 10:30 AM, Sara Golemon <[email protected]> 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.
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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


On Tue, Nov 7, 2017 at 8:38 AM, Sara Golemon <[email protected]> wrote:

> Biweekly reminder that PHP mail servers suck.
>
> On Wed, Oct 25, 2017 at 10:30 AM, Sara Golemon <[email protected]> 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.
> > 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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
>
>
> On Tue, Nov 7, 2017 at 8:38 AM, Sara Golemon <[email protected]> wrote:
>
>> Biweekly reminder that PHP mail servers suck.
>>
>> On Wed, Oct 25, 2017 at 10:30 AM, Sara Golemon <[email protected]> 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.
>>> 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
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>


--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:[email protected] 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.

On 7 November 2017 at 14:48, Eli White <[email protected]> wrote:

> 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
>
>
> On Tue, Nov 7, 2017 at 8:38 AM, Sara Golemon <[email protected]> wrote:
>
> > Biweekly reminder that PHP mail servers suck.
> >
> > On Wed, Oct 25, 2017 at 10:30 AM, Sara Golemon <[email protected]> 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.
> > > 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
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>



--
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

On Tue, Nov 7, 2017 at 9:07 AM, Peter Lind <[email protected]> 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.

Eli

Am 07.11.17 um 16:40 schrieb Eli White:
> On Tue, Nov 7, 2017 at 9:07 AM, Peter Lind <[email protected]> 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!

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:[email protected] N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+

On Tue, 2017-11-07 at 16:54 +0100, Andreas Heigl wrote:
> Am 07.11.17 um 16:40 schrieb Eli White:
> > On Tue, Nov 7, 2017 at 9:07 AM, Peter Lind <[email protected]>
> > 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 [email protected] mailing list as well (mentioned here:
https://externals.io/message/97214) which may yield some actual response
from the people involved.

Regards,
Pedro

On 7 Nov 2017 16:40, "Eli White" <[email protected]> wrote:

On Tue, Nov 7, 2017 at 9:07 AM, Peter Lind <[email protected]> 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.


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.

On Tue, Nov 7, 2017 at 5:44 PM, Pedro Magalhães <[email protected]> wrote:

> 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 [email protected] 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 [email protected] 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

On Wed, Nov 8, 2017 at 2:51 AM, Rasmus Lerdorf <[email protected]> wrote:
> On Tue, Nov 7, 2017 at 5:44 PM, Pedro Magalhães <[email protected]> wrote:
>
>> 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 [email protected] 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 [email protected] 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 [email protected]) 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Am 08.11.2017 um 12:09 schrieb Sara Golemon:
> On Wed, Nov 8, 2017 at 2:51 AM, Rasmus Lerdorf <[email protected]> wrote:
>> 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 [email protected]) 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 ([email protected] via PHP-DEV Mailing List)
<[email protected]>
- 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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: [email protected]
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=76.75.200.58;
helo=lists.php.net;

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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: [email protected]
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Wed, Nov 8, 2017 at 6:59 AM, Michael Kliewe <[email protected]> wrote:
> Am 08.11.2017 um 12:09 schrieb Sara Golemon:
>> On Wed, Nov 8, 2017 at 2:51 AM, Rasmus Lerdorf <[email protected]> wrote:
>>> 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 [email protected]) 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 ([email protected] via PHP-DEV Mailing List)
> <[email protected]>
> - 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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: [email protected]
>> Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=76.75.200.58
>>
> 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

the from header has no business with SPF - period
DMARC is a different story

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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: [email protected]
>>> Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=76.75.200.58
>>>
>> 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
>
> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> 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 [email protected]) 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 [email protected]

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

On Wed, Nov 8, 2017 at 8:03 AM, Rasmus Lerdorf <[email protected]> wrote:

> 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