Hm, mailing lists are actually "just" distribution groups with storage
backing. No fancy needed actually.
Of course, mailing list servers should not ever try to impersonate others
by sending with the original senders mailing address. That would raise spf
failures and dmark warnings (on domains con
There are a number of mailing lists that I am a member of that use
groups.io. I haven't experienced any problems receiving emails from
there.
FWIW Yocto has their mailing lists through groups.io, so it has been
used by other open-source communities:
https://lists.yoctoproject.org/g/yocto
-Robert
Mailing lists operate by modifying emails and this invalidates emails'
checksum & signature – this is what I tried to explain in detail in my
first email. There are "workarounds" (see Mailman DMARC mitigations link I
shared), but no one-size-fits-all solution. See the INFRA tickets I shared
for suc
This is one item I would like us, Apache, spend our money on.
Gary
On Tue, Oct 15, 2024, 12:33 PM Matt Sicker wrote:
> Yeah this sounds like what Volkan discovered in his research. The mailing
> list software is fucking up the metadata in such a way as to make it
> invalid in various spam check
Yeah this sounds like what Volkan discovered in his research. The mailing list
software is fucking up the metadata in such a way as to make it invalid in
various spam checks (some of which silently drop malformed emails). It doesn’t
help that said software is ancient and no longer developed.
>
I would guess, if mail doesn't work it probably relates to spf, dkim or
dmark.
Your description matches exactly this: Some service providers gradually
increase the rate of rejected mails that come from servers/domains refusing
to implement spf and dkim or even fail spf/dkim checks. This can be see
Volkan has taken to pinging me in Slack every time he sends a message to this
list because at least 25% of the time I wasn’t getting his emails. No one knows
why. I checked with my mail provider and have looked everywhere I have access
to.
Lately I have been getting all of his emails. Again, I
What concerns me is that email appears to be unreliable where it shouldn't.
Either it works always or it doesn't at all. I experience it to be 100%
reliable.
Short downtimes are OK and to be expected while systems are patched. But
then email are delivered later. The technology is much like a postm
That’s because a lot of other things are also using Slack. On the other hand, I
had to disable notifications from Slack due to people misusing it to DM me
instead of sending emails to the Secretary properly (unrelated to Log4j).
> On Oct 14, 2024, at 15:53, Ralph Goers wrote:
>
> I can’t say I
I can’t say I agree with that. It didn’t take me very long to get used to using
Slack.
Ralph
> On Oct 14, 2024, at 1:47 PM, Matt Sicker wrote:
>
> There’s a very, very small chance I’ll ever remember to visit a website to
> find out about what are essentially emails that could have been sent
There’s a very, very small chance I’ll ever remember to visit a website to find
out about what are essentially emails that could have been sent to me. I have a
regular habit of reading email nearly every day, but developing new habits is
unlikely to stick.
> On Oct 14, 2024, at 14:50, Ralph Goe
python...sigh.
发件人: Gary Gregory
发送时间: 星期二, 十月 15, 2024 3:59:10 上午
收件人: Apache Logging Developers List
主题: Re: Successor to mailing lists
I'll admit that I rely on PonyMail. It seems we (Apache) should have a
professional (paid for is ok) set up for this,
I'll admit that I rely on PonyMail. It seems we (Apache) should have a
professional (paid for is ok) set up for this, not a custom solution.
Gary
On Mon, Oct 14, 2024, 3:51 PM Ralph Goers
wrote:
> Maybe we just need to start contributing to PonyMail to improve the UI to
> eliminate actually nee
Maybe we just need to start contributing to PonyMail to improve the UI to
eliminate actually needing the email delivered to our accounts.
I am only 1/4 serious about this. There has to be a better solution.
Ralph
> On Oct 14, 2024, at 10:25 AM, Matt Sicker wrote:
>
> I didn’t get the original
I didn’t get the original email in this thread once again, so I think I’d
support trying somewhere else to host discussions. Besides archiving those
messages into a mailing list, it would be great if the solution provided
allowed for email interactivity (e.g., you can reply to the notification o
On Fri, Oct 11, 2024 at 2:08 PM Christian Grobmeier
wrote:
>
>
> On Fri, Oct 11, 2024, at 19:35, Gary Gregory wrote:
> > I'm not crazy about having to bounce around sections of various repos in
> > addition to monitoring emails, which has to be done anyway. It's
> _another_
> > thing to lose trac
On Fri, Oct 11, 2024, at 19:35, Gary Gregory wrote:
> I'm not crazy about having to bounce around sections of various repos in
> addition to monitoring emails, which has to be done anyway. It's _another_
> thing to lose track of :-( Having a repo just to use the discussion feature
> feels like a
I'm not crazy about having to bounce around sections of various repos in
addition to monitoring emails, which has to be done anyway. It's _another_
thing to lose track of :-( Having a repo just to use the discussion feature
feels like a hack.
I wish I could find the thread about new reddit-like FO
Hi Volkan,
I would prefer option 1.3, because most of the users will look for discussions
in the most relevant Github repo (for them).
I'm not a fan of Discourse (another app to install and no integration with
Github).
Let's try and find out whether it works for us.
We need to decide, whether
That is something we can decide together:
1. Have project-specific discussion repositories (i.e., Log4j users will
use `logging-log4j2`, LogNet users will use `logging-log4net`, and so on)
2. Have a shared discussion repository (e.g., we can create
`logging-discuss` repository and crea
Right, like having shared concepts... or shared architectural principles.
Gary
On Thu, Oct 10, 2024 at 5:36 PM Robert Middleton
wrote:
> The one problem I see with Github is that as far as I am aware
> discussions are on a per-repository basis, so unless we have a bare
> repository with everybo
The one problem I see with Github is that as far as I am aware
discussions are on a per-repository basis, so unless we have a bare
repository with everybody subscribed to it there's no way that I'm
aware of to share information. For example while most of this mailing
list is log4j specific, we als
GitHub can be configured to send email notifications. We can route these
to, say, `notificati...@logging.apache.org` email address to have our local
records.
On Thu, Oct 10, 2024 at 2:01 PM Gary Gregory wrote:
> I thought this was recently discussed on @members, but now I can't find the
> thread
and some of our guys cannot reach github due to network/law reasons.
Gary Gregory 于2024年10月10日周四 20:00写道：
> I thought this was recently discussed on @members, but now I can't find the
> thread! I'm not even sure if it was on @members, which exemplifies the
> scaling problem discussed on the list
I thought this was recently discussed on @members, but now I can't find the
thread! I'm not even sure if it was on @members, which exemplifies the
scaling problem discussed on the list, among other issues: When you look at
PonyMail's UI, there are about 60 internal mailing lists under the '
apache.
I cannot express an opinion without knowing what the replacement is and having
experience with it. Mailing lists have one great feature - they are easy to
search. For that reason anything we choose should be just as easy or better. We
must also stick to a single medium for formal communication f
Hi
I am generally open to such experiments. I would start with the easiest parts,
such as users@, and see where it goes.
I would advise against mirroring it to users@ behind the scenes, as it may
cause privacy problems (we need user consensus to mirror it). When a user uses
GitHub, they know
*Abstract:* Modern email system security measures make it practically
impossible for mailing lists to work – many subscribers don't get all
emails. This not only hinders communication, but blocks an inclusive
one. *Shall
we, as Logging Services, experiment with alternatives?*
*Motivation #1: maili
28 matches
Mail list logo
