>>
>> Okay, this might be off-topic for mailop (once I resurrect some mailing
>> lists, those will be the place, but that's hopefully later this week). The
>> person with the abillity to make DNS changes is somewhat oversubscribed at
>> the moment.
>>
>> ...but with the work I'm doing, right now, RUA reports in OpenDMARC are sent
>> via a perl script, but RUF reports are sent directly from the C milter by
>> popen() ing a pipe to sendmail. It's sounding more and more like I need to
>> break RUF= reporting also into an off-board script, so it can inherit from
>> all of this. And do VERP so that a future tool can back off sends the same
>> way many listservs do. And perhaps customize the body text more easily.
>>
>> Also, http and https urls are valid url-methods for RUA/RUF, and the milter
>> doesn't do them. The perl script now does, in my branch, and they don't
>> suffer the bounce issue, although they don't seem to be in wide use.
>
> Does this mean that OpenDMARC will be seeing a new release in the
> near future?
Whoops, sorry, thread growth continues, but others may find this interesting,
so I'll go on a bit.
That is the goal, yes. I have the ability to push one out officially, on the
offical repo, but there a "turn-your-key-sir" step there with the maintainer,
msk.
There's also a DMARCbis RFC about to drop, which includes a new tree-walking
requirement, and some new fields in the DMARC TXT record (which deprecate the
use of the PublicSuffixLists) and we'd like to get that in there as well.
(https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ section 4.10) and
it makes sense to have that happen first before final release, so it's
reflected in our docs and README's with its real RFC numbers, even if it's
implemented without that RFC number in an alpha or a beta).
It's not a lot of work to make those happen, but it is new code versus the
crash fixes, patch triage, and reporting improvements I've been doing.
> https://www.github.com/trusteddomainproject/OpenDMARC
>
> I hope so, because it's a good project, and I even tried to
> contribute to it a while ago with a PostgreSQL schema (that a few
> people tried and responded positively):
>
> https://github.com/trusteddomainproject/OpenDMARC/pull/251
I'd be happy to have a postgres schema/scripts, but the issue there is a lot of
the DB calls used by the reporting scripts are very different in postgres land,
so it either would need those basically forked off to -pg variants or have a
lot of ifdefines (but, pretty please, let's wait until I figure out what those
scripts do) so I don't immediately break your stuff right after. (See literal
previous thread in this discussion).
See https://github.com/trusteddomainproject/OpenDMARC/issues/246 for more
details, especially the comments at the bottom about the db function
differences.
I've also added a dmarc-run script that basically serves the job of the three
previous reporting cron jobs and gives you a single place to put knobs like db
info, and perhaps in that script you could point at if you want the -pg or -my
variant (which would be the default so we don't break people's existing
crontabs).
> There haven't been any updates for a few years now, and the list of
> Pull Requests doesn't seem to be leading to any merges, so I've held
> back at this point with concern that the project may have been
> abandoned.
I get it, and as I posted on (either this or postfix-users a while ago),
there's been a few complicated issues in Real Life that we've been vague about
(short version: several family-related health issues on my end that suck a
bunch of attention), but also things on the part of other maintainers.
I'm also in touch with the author/maintainer of another related project, who
cannot contribute to their code because of legal reasons (can't say more than
that), but I'm working to unstick their code as well.
At some point, I might write up a medium article about the various reasons
these things happen, but that's out of scope for this post.
There's the problem that sometimes you fix a few things, and people jump on and
say "what about MY thing" loudly.
There's also the scary problem that sometimes, someone jumps in to help a
load-bearing project where burnout is a thing, contributes good code for
years...and then slips an sshd trojan into a random blob of test code. So
there's also a need for vetting.
And when you can't raise a second person to review, easily, there's a lot of
impostor syndrome and second guessing.
As it happens, I got annoyed about this because someone decided to open ten
different issues because of things like "our website doesn't support HTTPS".
That and a major (positive) health change in my own life. (Also out of scope
for this).
The state of the project with many pull requests in TDP/OpenDMARC, plus a bunch
of old patches on SourceForge (with some really good ideas, with merit, but
which no longer apply cleanly), plus github doing some stupid things with
patches that it displays inline that are *not* pull requests, plus pull
requests against old versions, and then the idiotic github behavior of not
actually just DISPLAYING a four line text/plain foo.patch.txt but instead
forcing it to download...does not make this easier.
===
Anyway, about the code:
There's a lot of pull requests from my own repo (thegushi) -- especially
recently, and I have the requisite permissions to merge them, but I really
would love a second pair of eyes before doing so, and also to spin up some AWS
vm's to at least run tests on the Linux variants we test on before doing so.
I'm on FreeBSD, mainly. One of my more "interesting" goals is to push my mail
through opendkim/opendmarc milters on several different platforms with
different AuthServID's and then author a simple "spot any differences" milter
at the end of the chain to look for regressions.
All the RUA reports I'm sending should now have all the fields and be fully
RFC-compliant -- if anyone on this list works for a consumer of those things
like dmarcian or Valimail, etc and would like samples, please reach out. I
want to get this right.
I'm currently running an integration test against my own build that's a roll up
of most of my issue-specific fixes (look for the needs-testing tag in the main
repo), on a hosting server that runs about 100 friends-and-family domains. If
it proves stable enough, I may also run it at the dayjob (which would need
permission from my boss). If you're interested in trying it, it's
https://github.com/thegushi/OpenDMARC/tree/integration/fixes
To try to maintain good Git hygiene, I'm doing the work per-issue on my own
repo so one can see clean diffs when looking at the issues, then merging those
issues into the integration/fixes branch, but it does have the side effect of
making the main repo look quieter.
It's one of my goals to get better build fingerprinting in so opendmarc -V
actually gives you the configure args to rebuild it, which makes it easier if
you're using a precompiled package where that's hidden from you, but obviously
that doesn't help if you're running an older version.
There are also a number of compiler warnings I'd love to work on, but Exim
links against libopendmarc, instead of using a milter and those might be
breaking changes for them unless they're ready for it (might require a library
version bump).
The next step there would be to push it into a 1.5.0-ALPHA branch and post that
here and other places for greater community involvement.
>> I'm also thinking just a manually maintained list of "dead report receivers"
>> is useful.
>
> If you do, please feel free to contact me privately because I'd be
> happy to add any to it that you don't already have, but which bounce
> for me as well.
Well, since all the reporting tools will use the DB if I cut them over, the
"ignore" list would probably live there as a separate table, versus a static
file (which would be required if the C-code was the thing still sending the
RUFs). Yeah, you might need to run a SQL command versus tweaking a textfile to
add someone to the naughty list, but it would also make dynamic maintenance
(via VERP, etc) easier.
>> I'll also contact the measurement.network people and perhaps see if they
>> need help putting the stalemark stuff into an actual RBL, or if they'd have
>> a problem with our docs pointing at them.
>
> FYI: I may be interested in helping with this too.
Short version: Yes, I'm interested in help, but let's find a way to communicate
that doesn't burn up all the good mailop people's time. Contact me off-list
and I'll connect with you over signal or something.
Cheers,
-Dan
(who is bad at "Short Version")
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
