From mcevoy.pat at gmail.com  Tue Nov  7 10:52:33 2023
From: mcevoy.pat at gmail.com (Pat McEvoy)
Date: Tue, 7 Nov 2023 10:52:33 -0500
Subject: [talk] FreeBSD 14 release party? Nov 8th
In-Reply-To: <2D155699-6C73-4C09-8713-BB9E2279CFBA@gmail.com>
References: <2D155699-6C73-4C09-8713-BB9E2279CFBA@gmail.com>
Message-ID: <C54B294D-86DF-46F5-9BF1-7BC728F05AEC@gmail.com>

We are on for tomorrow Nov 8th at the Five Mile. Our usual 6:45. Bringing EuroBSDcon swag. 

Patrick McEvoy


> On Oct 26, 2023, at 16:36, Pat McEvoy <mcevoy.pat at gmail.com> wrote:
> 
> ?
>> On Oct 25, 2023, at 19:36, Charlie Li <vishwin at freebsd.org> wrote:
>> 
>> ?FreeBSD 14.0-RELEASE is projected to drop sometime next week or the week after, which coincides with the usual meeting cadence. Maybe have something along those lines as part of a social or whatnot? New FreeBSD Journal issue should be out too.
>> 
>> -- 
>> Charlie Li
>> 
> 
> Sounds like a plan. I will bring some swag I picked up at EuroBSDcon. Will write up something and ask nicely to have it up on the website shortly. Be well folks.



From mcevoy.pat at gmail.com  Tue Nov  7 15:08:53 2023
From: mcevoy.pat at gmail.com (Pat McEvoy)
Date: Tue, 7 Nov 2023 15:08:53 -0500
Subject: [talk] FreeBSD 14 release party? Nov 8th
In-Reply-To: <C54B294D-86DF-46F5-9BF1-7BC728F05AEC@gmail.com>
References: <C54B294D-86DF-46F5-9BF1-7BC728F05AEC@gmail.com>
Message-ID: <B8E2A6A6-D12D-4FB6-B9B3-44ECD335BFDB@gmail.com>

Website updated:

Next NYC*BUG: Tomorrow!

FreeBSD 14 discussion, future meeting planning,  EuroBSDcon swag. 

More info:

https://www.nycbug.org/index?action=view&id=10692



Patrick McEvoy


> On Nov 7, 2023, at 10:52, Pat McEvoy <mcevoy.pat at gmail.com> wrote:
> 
> ?We are on for tomorrow Nov 8th at the Five Mile. Our usual 6:45. Bringing EuroBSDcon swag. 
> 
> Patrick McEvoy
> 
> 
>> On Oct 26, 2023, at 16:36, Pat McEvoy <mcevoy.pat at gmail.com> wrote:
>> 
>> ?
>>>> On Oct 25, 2023, at 19:36, Charlie Li <vishwin at freebsd.org> wrote:
>>> 
>>> ?FreeBSD 14.0-RELEASE is projected to drop sometime next week or the week after, which coincides with the usual meeting cadence. Maybe have something along those lines as part of a social or whatnot? New FreeBSD Journal issue should be out too.
>>> 
>>> -- 
>>> Charlie Li
>>> 
>> 
>> Sounds like a plan. I will bring some swag I picked up at EuroBSDcon. Will write up something and ask nicely to have it up on the website shortly. Be well folks.



From george at ceetonetechnology.com  Thu Nov  9 10:12:53 2023
From: george at ceetonetechnology.com (George Rosamond)
Date: Thu, 9 Nov 2023 10:12:53 -0500
Subject: [talk] dealing with DMARC emails
Message-ID: <a45c669e-04e0-44d1-ab25-c2033485bdac@ceetonetechnology.com>

In this current era of the email cabal (goog,microsoft,etc), how are
email admins dealing with DMARC emails.

We host our own mail, but the question applies to everyone getting DMARC
emails even if you're stuck in the email cabal mud.

For $job, I usually just use Python dmarcreporting
(https://pypi.org/project/DMARCReporting/) and deal from there, since
it's a shell-based tool and I don't get XML-inspired headaches. But
things have gotten a bit messy with more noisy outgoing sales emails,
and I need to move beyond the manual.

And please recognize that there are more broken/misconfigured SPF and
DMARC records out there than anyone can imagine. I wish I could post a
DMARC email from this AM with emails sourced from a very well-known
tech-heavy company...

The proliferation of 3rd parties, people relying or ignoring
mass-mailing application instructions and the basic reliance on the
email cabal for email hosting are the likely roots of the problem.

At $job we collect and parse out SPF and DMARC (when default) on a huge
number of domains, and it's remarkable how RFC-ignorant the world is.
Hard to believe that this internet thing works at all.

I keep thinking of building something that does the following:

* dealing with automatically grabbing the gzip/zip'd XML attachment,
distinguishing between the 'rua' (aggregate) and 'ruf' (failure) DMARC
emails as they arrive.

* displaying them on some static web page with internal company-wide access

* providing diagnosis in simple English so most people can figure out
the issue if there's any "fails"

* maybe even pull in the output of SPF especially if relevant to
remediation ("Please add $mass_spammer to you SPF")

I'm more than happy to keep stored in the filesystem, as opposed to in a
database at this point.

How are you dealing? What other applications are worthwhile to explore?

g

PS: we need to get back to using talk@ for these routine day-to-day
questions. talk@ was once an arena for these questions, but I think many
have dropped this habit since many are concerned with asking "dumb
questions" and some prospective employer saying "what a stupid question".



From spork at bway.net  Thu Nov  9 11:53:08 2023
From: spork at bway.net (Charles Sprickman)
Date: Thu, 9 Nov 2023 11:53:08 -0500
Subject: [talk] dealing with DMARC emails
In-Reply-To: <a45c669e-04e0-44d1-ab25-c2033485bdac@ceetonetechnology.com>
References: <a45c669e-04e0-44d1-ab25-c2033485bdac@ceetonetechnology.com>
Message-ID: <C10FDC76-8D9F-4C46-A33D-DBDBE306158C@bway.net>



> On Nov 9, 2023, at 10:12?AM, George Rosamond <george at ceetonetechnology.com> wrote:
> 
> In this current era of the email cabal (goog,microsoft,etc), how are
> email admins dealing with DMARC emails.

Quick reply here, but after digging through a bunch of paid (hosted) and open source report parsers, I settled on this pairing:

https://github.com/userjack6880/Open-DMARC-Analyzer
https://github.com/userjack6880/Open-Report-Parser

Works well, developer was easy to work with on a few PostgreSQL issues...

Charles

> 
> We host our own mail, but the question applies to everyone getting DMARC
> emails even if you're stuck in the email cabal mud.
> 
> For $job, I usually just use Python dmarcreporting
> (https://pypi.org/project/DMARCReporting/) and deal from there, since
> it's a shell-based tool and I don't get XML-inspired headaches. But
> things have gotten a bit messy with more noisy outgoing sales emails,
> and I need to move beyond the manual.
> 
> And please recognize that there are more broken/misconfigured SPF and
> DMARC records out there than anyone can imagine. I wish I could post a
> DMARC email from this AM with emails sourced from a very well-known
> tech-heavy company...
> 
> The proliferation of 3rd parties, people relying or ignoring
> mass-mailing application instructions and the basic reliance on the
> email cabal for email hosting are the likely roots of the problem.
> 
> At $job we collect and parse out SPF and DMARC (when default) on a huge
> number of domains, and it's remarkable how RFC-ignorant the world is.
> Hard to believe that this internet thing works at all.
> 
> I keep thinking of building something that does the following:
> 
> * dealing with automatically grabbing the gzip/zip'd XML attachment,
> distinguishing between the 'rua' (aggregate) and 'ruf' (failure) DMARC
> emails as they arrive.
> 
> * displaying them on some static web page with internal company-wide access
> 
> * providing diagnosis in simple English so most people can figure out
> the issue if there's any "fails"
> 
> * maybe even pull in the output of SPF especially if relevant to
> remediation ("Please add $mass_spammer to you SPF")
> 
> I'm more than happy to keep stored in the filesystem, as opposed to in a
> database at this point.
> 
> How are you dealing? What other applications are worthwhile to explore?
> 
> g
> 
> PS: we need to get back to using talk@ for these routine day-to-day
> questions. talk@ was once an arena for these questions, but I think many
> have dropped this habit since many are concerned with asking "dumb
> questions" and some prospective employer saying "what a stupid question".
> 
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> https://lists.nycbug.org:8443/mailman/listinfo/talk